Почему производители робомобилей не должны нести никакой ответственности?
Примерно по той же причине, по которой врачи не несут ответственности за врачебные ошибки. Даже если из-за них умирает пациент.
Инженер и компания-производитель не ставили себе целью создать убийцу на колесах. А если ставили, то наказание они понесут, точно так же, как и врач, намеренно действующий во вред пациенту.
В Украине так же. Но какой процент водителей в плотном потоке реально соблюдает дистанцию, достаточную для избежания столкновения, когда впередиидущий автомобиль резко остановится?
Кто виноват — дело десятое. Сейчас обсуждается вопрос "что делать?" (робомобилю).
Ребенок тоже должен играть во дворе и не выбегать на трассу. Но он выбежал. И то, что он "сам виноват", мало что меняет.
Не можете обеспечить такой уровень безопасности, который позволит исключить тяжелые травмы и смерть кого-то из участников — не занимайтесь разработкой, или платите штрафы в каждом случае.
Отличная идея. Давайте тогда еще заставим платить штрафы производителей бумаги за каждый случай пореза их бумагой. Должны же обеспечить уровень безопасности. И производителей столбов заодно, если их столб, будучи сбитым при ДТП, пришиб пешехода. Не могут исключить травмы — пусть не занимаются разработкой. Так победим.
И не надо вот этих вот оправданий, что любая сложная система может выйти из строя.
Во-первых, нередко "моральный выбор" нужно делать даже когда все системы в норме (например, на трассу с плотным и быстрым потоком неожиданно выскакивает ребенок. И робомобилю с исправными системами нужно сделать выбор: ехать ничего не предпринимая и давить ребенка; тормозить, провоцируя ДТП и создавая опасность для пассажиров автомобиля позади; пытаться объехать ребенка, все так же провоцируя ДТП и создавая опасность для автомобилей своей и встречной полосы).
В-вторых, как вам там живется в вашей утопии, где системы не ломаются и материалы не подвержены коррозии? Реки у вас там молочные или медовые?
Я бы не ставил это в один ряд. Без навыков работы с контролем версий не выйдет эффективно взаимодействовать с командой и в проекте такой начинающий программист будет скорее мешать, чем помогать.
Касательно юнит тестов же, во-первых, есть множество проектов либо вообще без них, либо с заброшенными тестами, которые никто уже годами не поддерживает. Во-вторых — даже в проекте с тестами есть достаточно работы для начинающего, не затрагивающей тесты. В-третьих, тесты — это все таки не рокет сайенс. Если начинающий сумел освоить VIPER, MVVM, MVC, то уж как писать юнит тест он разберётся по ходу, если это потребуется.
Много. Но 90% из них по сути — хром с нескучными обоями и парой-тройкой плагинов.
Если из хромиума что-то выпилят, то очень велика вероятность того, что фича тут же исчезнет из всех "переезжать есть куда", которые живы и обновляются. А переходить на браузер, который не обновляется — так себе идея.
Если ошибка произошла на низком уровне (на уровне сервера, прокси, и т.д. Что-то в духе 404 или 504) — да, можно обойтись и статус кодом и на клиенте такой ответ отловить, не передавая сильно глубоко в обработку.
Если же ошибка произошла на уровне логики приложения, то в почти всех случаях помимо информации о самом факте ошибки клиенту нужно сообщить еще какие-то подробности о природе и причинах этой ошибки. И да, статус кода как правило недостаточно. Все равно будет какое-то тело ответа. И вот совершенно непонятно, что мы выигрываем, размазывая информацию об ошибке ровным слоем по телу и заголовку ответа, вместо того чтобы заключить её всю в одном месте (в теле ответа).
"Код становится уродливым", кмк, именно в таком случае. В лучшем случае приходится просто говорить клиентскому фреймворку, чтобы он игнорировал статус код ответа и передавал на уровень бизнес логики все ответы подряд. И там уже с ними работать точно так же, как и в случае статуса 200. С единственным отличием, что тип ошибки будет доставаться из статус кода, а не одного из полей джейсона.
В худшем случае это все дело придется обвешивать еще кучей костылей и уродливых хуков, потому что условный nginx, если не сможет достучаться до апстрима, вернет html страничку со статусом 504, а не джейсон. И код бизнес-логики к такому повороту скорее всего будет не готов.
А что не так с уровнем дискуссии? Принцип Лисков код из статьи никак не нарушает. Если он нарушает какой-то принцип какого-то (какой-то) Лисковски, то было бы неплохо пояснить, кто это такой (такая) и что это за принцип, а то я вот тоже ничего о таком персонаже не слышал.
Кроме непосредственно чтения вызовов с 10 параметрами есть еще проблемы, которые IDE не решит даже частично.
Например, есть конструктор C(int a, int b, int c, D d, E e)
Будь у нас именованные параметры и дефолтные значения — мы могли бы его вызывать, передавая только недефолтные параметры (собственно, получив поведение билдеров, только удобнее и без билдеров).
Без них же проблемы следующие:
Количество делегирующих конструкторов под все возможные наборы аргументов растет экспоненциально. В данном случае (всего 5 параметров. Очень немного) потребовалось бы 32 конструктора. Для 10 аргументов — уже 1024. "С точки зрения класса" это капец как громоздко. Без всяких "может" :). Да, не всегда нужна возможность задавать любое подмножество параметров, некоторые параметры обязательны и т.д., но тем не менее. Собственно, ни разу и не встречал, чтобы так делали. Если какие-то делегирующие конструкторы и есть, то максимум — убирающие по одному параметру с конца. А если нужно задать нестандартные первый и последний аргументы — будь добр напихать в месте вызова null-ов в середину списка.
Для некоторых наборов аргументов создать делегирующие конструкторы невозможно в принципе. Например, для примера выше не выйдет создать 3 конструктора, принимающих параметры, соответственно, (int a, int b), (int b, int c) и (int a, int c). Можно обойти фабричными методами, но по сути — такой же костыль, как и билдеры.
вместо простого, надёжного и предсказуемого flex-layout
Если я правильно понял, о чем вы, то все (или почти все), что умеет flex-layout — умеет один единственный UIStackView и предоставляет очень похожие способы управления этим всем. Точно так-же "просто, надежно и предсказуемо". Autolayout же в общем случае предоставляет намного больше гибкости и возможностей. И не сказал бы, что он сильно сложен в использовании или "непредсказуем".
Медленнее работает и дебажить иногда сложнее — это да. Но проблемы с производительностью, как правило, бывают только в сильно сложных UITableView/UICollectionView с автосайзингом ячеек и прочими радостями. А дебаг с визуальным инспектором сейчас в некоторых случаях даже проще, чем ползание по коду в поисках, кто же там фрейм портит.
Да, в вашем случае мы скорее крутим треугольник и внезапно обнаруживаем, чтот одна из его сторон — не отрезок, а дуга окружности. Да, такой "треугольник" позволит обойти какие-то ограничения "обычного" треугольника (например, сумму углов в 180 градусов). Но только этот "треугольник с дугой" — не треугольник. И к исходной задаче про трегольник (какая бы она ни была) имеет такое же отношение, как и зависающий оракул к исходной проблеме останова.
Зависание — это будет точно такой же ответ "не знаю", как и возврат -1. Немного более хитро сформулированный, да. Но сути это не меняет.
Любой алгоритм либо завершается за конечное время, либо не завершается. Третьего варианта нет. Оракул должен давать ответ, к какому из этих двух вариантов относится переданный ему алгоритм. Если он этот ответ не дает (не важно из-за чего: из-за возврата "третьего" значения, из-за зависания или из-за уничтожения вселенной), то этот оракул не работает. Во всяком случае в рамках исходной задачи. Для какой-то другой задачи, где для оракула ответ "не знаю" является допустимым — да, зависание прекрасный способ сообщить о незнании.
Не то, чтобы это что-то меняло, но все же немного позанудствую. Opaque — это НЕпрозрачный. Правильный ответ, конечно же, находится и по такому запросу, но вот сам запрос задаёт прямо противоположный вопрос. Запросы со словами opacity, alpha, transparent или semi-transparent вместо opaque работают не хуже.
Немного странная мотивация, если чесно) Покупка или непокупка вами одного единственного макбука для Эппла погоды не сделает абсолютно. Любое средней успешности приложение (в том числе и разработанное вами) принесет эпплу и банально больше денег, чем одна покупка макбука или мак-мини, и окажет большее (положительное) влияние на популярность платформы, чем принципиальная позиция одного никому неизвестного разработчика.
На Эппле ваше решение страдать с виртуалками и хакинтошами не скажется никак, а вот вы страдаете)
Хакинтош пока еще не ставил, собираюсь, очень надеюсь, что будет работать стабильно
Если железо совместимое — будет. После некоторого времени проведенного за чтением форумов и поиском кекстов — работает вполне стабильно. Но каждое обновление ОС — лотерея с призами "не загрузится", "загрузится, но отвалится половина железа" и джекпот: "загрузится так же, как и до обновления". В теории можно и не обновляться, конечно. Но Эппл — не Майкрософт и обратной совместимостью не сильно страдает. Очередная версия Xcode может отказаться работать на старой macOS, а App Store может отказаться принимать билды, собранные старым Xcode-ом.
В теории — да, ставится. На практике, во-первых, сборка требует тщательного подбора компонентов, совместимых с хакинтошем, что даже для десктопа может быть проблемой, а для ноутбуков так вообще практически не вариант найти железку, у которой под хакинтошем хоть что-то не отвалится. Во-вторых — даже "правильные" и совместимые компоненты не факт что останутся таковыми после очередного даже минорного апдейта ОС.
Единственная, имхо, адекватная причина ставить хакинтош (особенно на ноутбук) — это отсутствие денег на мак. Собственно, я, будучи еще бедным подрабатывающим студентом, как-то так и жил. Как только появились деньги — мне стало намного проще купить прошку за $2K, чем каждый день переживать, а загрузится ли вообще система и раз в несколько месяцев стабильно выпадать из работы из-за отвалившегося USB или WiFi и/или тратить все выходные на выяснение причин этого отваливания, патчинг кекстов, покупку вайфай свистков для использования вместо встроенного в ноут WiFi и поиск прочих обходных путей.
Вы лжёте. Это именно вы здесь написали, что любая фунуция реализует алгоритм.
У вас какая-то каша в голове, честное слово. Я написал
Любой код реализует какой-то алгоритм
Да, это так. Любой компилируемый код и любой псевдокод, каким бы бессмысленным он кому-то не казался, реализует какой-то алгоритм (каким бы бессмысленным он тоже не казался).
Где в этих словах конкретная реализация алгоритма оракула (функции halts)?
Вы предполагаете существование функции, а вывод делаете об алгоритме. Подмена понятия.
Какой смысл вы вкладываете в слово "функция"?
Любой алгоритм предполагает наличие набора (возможно пустого) входных, выходных данных и набора неких операций, определяющих поведение алгоритма (получение выходных данных из входных).
Для функции halts предполагается наличие ровно этих вещей и никаких других.
Да, функция не существует, вы это доказали, спасибо
Не я, а Тьюринг. Я лишь привел его доказательство. Не за что.
Алгоритм тоже не существует, но доказали это не вы
Да, не я. Тьюринг. А чем алгоритм halts отличается от функции halts — одному вам известно.
и совсем по-другому.
Да нет, точно так же, как и я. Только он еще строго формализовал понятие алгоритма, придумав для этого машину Тьюринга. Но на высоком уровне доказательство — ровно такое же доказательство от противного, как и у меня.
Какая конкретная реализация? Ее где-то видите только вы. Никто ее в этой ветке не рассматривал.
доказывается несуществование алгоритма совсем по-другому — непосредственно для алгоритма, без каких-либо попыток реализации в коде.
Да. Именно поэтому никто из приводящих классическое доказательство этой проблемы от противного и не рассматривал никакие конкретные реализации функции оракула в коде. Я даже больше скажу. Алгоритмы оракула тоже не рассматривались. Рассматривалась только возможность или невозможность существования такого алгоритма.
Какие-то детали реализации здесь рассматривали только люди, не согласные по каким-то причинам с доказательством Тьюринга. То вводили какие-то контексты (все равно не помогающие вернуть правильный ответ), то требовали чтобы основная функция была реализована с помощью двух независимых вспомогательных функций (что тоже ничем не помогало в решении поставленной проблемы), то еще что-то.
Но это не значит, что не существует алгоритм, который она вроде бы реализует.
В том то и дело, что значит. Потому что см. предыдущие 2 пункта.
эти ускоренные/упрощённые методы доказательства годятся только для запудривания мозгов пятиклассницам.
Вот как.
Если один из самых распространенных видов математического доказательства для вас "упрощенный метод для запудривания мозгов пятиклассницам", то не могли бы вы привести хотя бы один конкретный пример доказательства, которое, на ваш взгляд, не "упрощенное" и годится не только для пятиклассниц? В идеале, конечно, какое-то математическое доказательство, но вообще подойдет доказательство чего угодно. Вот просто любопытно, что вы приведете.
П.С.
Я тоже вас не минусовал. Минусовать (как и плюсовать, впрочем) никого мне карма не позволяет.
Ответ моей функции в таком случае будет неправильным. Как и неправильный ответ вашего оракула. А значит моя функция не работает в общем случае. Как и ваш оракул.
Вы молодец, что умеете работать со стеком вызовов. Но сейчас речь об одной конкретной программе. Не о математике. В этой одной конкретной программе есть только один вызов оракула. С одним контекстом. С одним стеком вызовов. Других вызовов оракула нет. И в этом единственном вызове оракул возвращает неправильное значение.
Примерно по той же причине, по которой врачи не несут ответственности за врачебные ошибки. Даже если из-за них умирает пациент.
Инженер и компания-производитель не ставили себе целью создать убийцу на колесах. А если ставили, то наказание они понесут, точно так же, как и врач, намеренно действующий во вред пациенту.
В Украине так же. Но какой процент водителей в плотном потоке реально соблюдает дистанцию, достаточную для избежания столкновения, когда впередиидущий автомобиль резко остановится?
Кто виноват — дело десятое. Сейчас обсуждается вопрос "что делать?" (робомобилю).
Ребенок тоже должен играть во дворе и не выбегать на трассу. Но он выбежал. И то, что он "сам виноват", мало что меняет.
Отличная идея. Давайте тогда еще заставим платить штрафы производителей бумаги за каждый случай пореза их бумагой. Должны же обеспечить уровень безопасности. И производителей столбов заодно, если их столб, будучи сбитым при ДТП, пришиб пешехода. Не могут исключить травмы — пусть не занимаются разработкой. Так победим.
Во-первых, нередко "моральный выбор" нужно делать даже когда все системы в норме (например, на трассу с плотным и быстрым потоком неожиданно выскакивает ребенок. И робомобилю с исправными системами нужно сделать выбор: ехать ничего не предпринимая и давить ребенка; тормозить, провоцируя ДТП и создавая опасность для пассажиров автомобиля позади; пытаться объехать ребенка, все так же провоцируя ДТП и создавая опасность для автомобилей своей и встречной полосы).
В-вторых, как вам там живется в вашей утопии, где системы не ломаются и материалы не подвержены коррозии? Реки у вас там молочные или медовые?
Я бы не ставил это в один ряд. Без навыков работы с контролем версий не выйдет эффективно взаимодействовать с командой и в проекте такой начинающий программист будет скорее мешать, чем помогать.
Касательно юнит тестов же, во-первых, есть множество проектов либо вообще без них, либо с заброшенными тестами, которые никто уже годами не поддерживает. Во-вторых — даже в проекте с тестами есть достаточно работы для начинающего, не затрагивающей тесты. В-третьих, тесты — это все таки не рокет сайенс. Если начинающий сумел освоить VIPER, MVVM, MVC, то уж как писать юнит тест он разберётся по ходу, если это потребуется.
Это обычная "ноутбучная" планка памяти. Сможете купить где угодно.
Много. Но 90% из них по сути — хром с нескучными обоями и парой-тройкой плагинов.
Если из хромиума что-то выпилят, то очень велика вероятность того, что фича тут же исчезнет из всех "переезжать есть куда", которые живы и обновляются. А переходить на браузер, который не обновляется — так себе идея.
И чем это знание поможет?
Если ошибка произошла на низком уровне (на уровне сервера, прокси, и т.д. Что-то в духе 404 или 504) — да, можно обойтись и статус кодом и на клиенте такой ответ отловить, не передавая сильно глубоко в обработку.
Если же ошибка произошла на уровне логики приложения, то в почти всех случаях помимо информации о самом факте ошибки клиенту нужно сообщить еще какие-то подробности о природе и причинах этой ошибки. И да, статус кода как правило недостаточно. Все равно будет какое-то тело ответа. И вот совершенно непонятно, что мы выигрываем, размазывая информацию об ошибке ровным слоем по телу и заголовку ответа, вместо того чтобы заключить её всю в одном месте (в теле ответа).
"Код становится уродливым", кмк, именно в таком случае. В лучшем случае приходится просто говорить клиентскому фреймворку, чтобы он игнорировал статус код ответа и передавал на уровень бизнес логики все ответы подряд. И там уже с ними работать точно так же, как и в случае статуса 200. С единственным отличием, что тип ошибки будет доставаться из статус кода, а не одного из полей джейсона.
В худшем случае это все дело придется обвешивать еще кучей костылей и уродливых хуков, потому что условный nginx, если не сможет достучаться до апстрима, вернет html страничку со статусом 504, а не джейсон. И код бизнес-логики к такому повороту скорее всего будет не готов.
А что не так с уровнем дискуссии? Принцип Лисков код из статьи никак не нарушает. Если он нарушает какой-то принцип какого-то (какой-то) Лисковски, то было бы неплохо пояснить, кто это такой (такая) и что это за принцип, а то я вот тоже ничего о таком персонаже не слышал.
Кроме непосредственно чтения вызовов с 10 параметрами есть еще проблемы, которые IDE не решит даже частично.
Например, есть конструктор
C(int a, int b, int c, D d, E e)Будь у нас именованные параметры и дефолтные значения — мы могли бы его вызывать, передавая только недефолтные параметры (собственно, получив поведение билдеров, только удобнее и без билдеров).
Без них же проблемы следующие:
Перезалейте, пожалуйста, картинки на habrastorage.org. Vk у части читателей может быть заблокированным.
Если я правильно понял, о чем вы, то все (или почти все), что умеет flex-layout — умеет один единственный UIStackView и предоставляет очень похожие способы управления этим всем. Точно так-же "просто, надежно и предсказуемо". Autolayout же в общем случае предоставляет намного больше гибкости и возможностей. И не сказал бы, что он сильно сложен в использовании или "непредсказуем".
Медленнее работает и дебажить иногда сложнее — это да. Но проблемы с производительностью, как правило, бывают только в сильно сложных UITableView/UICollectionView с автосайзингом ячеек и прочими радостями. А дебаг с визуальным инспектором сейчас в некоторых случаях даже проще, чем ползание по коду в поисках, кто же там фрейм портит.
Да, в вашем случае мы скорее крутим треугольник и внезапно обнаруживаем, чтот одна из его сторон — не отрезок, а дуга окружности. Да, такой "треугольник" позволит обойти какие-то ограничения "обычного" треугольника (например, сумму углов в 180 градусов). Но только этот "треугольник с дугой" — не треугольник. И к исходной задаче про трегольник (какая бы она ни была) имеет такое же отношение, как и зависающий оракул к исходной проблеме останова.
Зависание — это будет точно такой же ответ "не знаю", как и возврат -1. Немного более хитро сформулированный, да. Но сути это не меняет.
Любой алгоритм либо завершается за конечное время, либо не завершается. Третьего варианта нет. Оракул должен давать ответ, к какому из этих двух вариантов относится переданный ему алгоритм. Если он этот ответ не дает (не важно из-за чего: из-за возврата "третьего" значения, из-за зависания или из-за уничтожения вселенной), то этот оракул не работает. Во всяком случае в рамках исходной задачи. Для какой-то другой задачи, где для оракула ответ "не знаю" является допустимым — да, зависание прекрасный способ сообщить о незнании.
Не то, чтобы это что-то меняло, но все же немного позанудствую. Opaque — это НЕпрозрачный. Правильный ответ, конечно же, находится и по такому запросу, но вот сам запрос задаёт прямо противоположный вопрос. Запросы со словами opacity, alpha, transparent или semi-transparent вместо opaque работают не хуже.
Немного странная мотивация, если чесно) Покупка или непокупка вами одного единственного макбука для Эппла погоды не сделает абсолютно. Любое средней успешности приложение (в том числе и разработанное вами) принесет эпплу и банально больше денег, чем одна покупка макбука или мак-мини, и окажет большее (положительное) влияние на популярность платформы, чем принципиальная позиция одного никому неизвестного разработчика.
На Эппле ваше решение страдать с виртуалками и хакинтошами не скажется никак, а вот вы страдаете)
Если железо совместимое — будет. После некоторого времени проведенного за чтением форумов и поиском кекстов — работает вполне стабильно. Но каждое обновление ОС — лотерея с призами "не загрузится", "загрузится, но отвалится половина железа" и джекпот: "загрузится так же, как и до обновления". В теории можно и не обновляться, конечно. Но Эппл — не Майкрософт и обратной совместимостью не сильно страдает. Очередная версия Xcode может отказаться работать на старой macOS, а App Store может отказаться принимать билды, собранные старым Xcode-ом.
В теории — да, ставится. На практике, во-первых, сборка требует тщательного подбора компонентов, совместимых с хакинтошем, что даже для десктопа может быть проблемой, а для ноутбуков так вообще практически не вариант найти железку, у которой под хакинтошем хоть что-то не отвалится. Во-вторых — даже "правильные" и совместимые компоненты не факт что останутся таковыми после очередного даже минорного апдейта ОС.
Единственная, имхо, адекватная причина ставить хакинтош (особенно на ноутбук) — это отсутствие денег на мак. Собственно, я, будучи еще бедным подрабатывающим студентом, как-то так и жил. Как только появились деньги — мне стало намного проще купить прошку за $2K, чем каждый день переживать, а загрузится ли вообще система и раз в несколько месяцев стабильно выпадать из работы из-за отвалившегося USB или WiFi и/или тратить все выходные на выяснение причин этого отваливания, патчинг кекстов, покупку вайфай свистков для использования вместо встроенного в ноут WiFi и поиск прочих обходных путей.
У вас какая-то каша в голове, честное слово. Я написал
Да, это так. Любой компилируемый код и любой псевдокод, каким бы бессмысленным он кому-то не казался, реализует какой-то алгоритм (каким бы бессмысленным он тоже не казался).
Где в этих словах конкретная реализация алгоритма оракула (функции halts)?
Какой смысл вы вкладываете в слово "функция"?
Любой алгоритм предполагает наличие набора (возможно пустого) входных, выходных данных и набора неких операций, определяющих поведение алгоритма (получение выходных данных из входных).
Для функции halts предполагается наличие ровно этих вещей и никаких других.
Не я, а Тьюринг. Я лишь привел его доказательство. Не за что.
Да, не я. Тьюринг. А чем алгоритм halts отличается от функции halts — одному вам известно.
Да нет, точно так же, как и я. Только он еще строго формализовал понятие алгоритма, придумав для этого машину Тьюринга. Но на высоком уровне доказательство — ровно такое же доказательство от противного, как и у меня.
Какая конкретная реализация? Ее где-то видите только вы. Никто ее в этой ветке не рассматривал.
Да. Именно поэтому никто из приводящих классическое доказательство этой проблемы от противного и не рассматривал никакие конкретные реализации функции оракула в коде. Я даже больше скажу. Алгоритмы оракула тоже не рассматривались. Рассматривалась только возможность или невозможность существования такого алгоритма.
Какие-то детали реализации здесь рассматривали только люди, не согласные по каким-то причинам с доказательством Тьюринга. То вводили какие-то контексты (все равно не помогающие вернуть правильный ответ), то требовали чтобы основная функция была реализована с помощью двух независимых вспомогательных функций (что тоже ничем не помогало в решении поставленной проблемы), то еще что-то.
В том то и дело, что значит. Потому что см. предыдущие 2 пункта.
Вот как.
Если один из самых распространенных видов математического доказательства для вас "упрощенный метод для запудривания мозгов пятиклассницам", то не могли бы вы привести хотя бы один конкретный пример доказательства, которое, на ваш взгляд, не "упрощенное" и годится не только для пятиклассниц? В идеале, конечно, какое-то математическое доказательство, но вообще подойдет доказательство чего угодно. Вот просто любопытно, что вы приведете.
Я тоже вас не минусовал. Минусовать (как и плюсовать, впрочем) никого мне карма не позволяет.
Ответ моей функции в таком случае будет неправильным. Как и неправильный ответ вашего оракула. А значит моя функция не работает в общем случае. Как и ваш оракул.
Вы молодец, что умеете работать со стеком вызовов. Но сейчас речь об одной конкретной программе. Не о математике. В этой одной конкретной программе есть только один вызов оракула. С одним контекстом. С одним стеком вызовов. Других вызовов оракула нет. И в этом единственном вызове оракул возвращает неправильное значение.