Pull to refresh

Comments 34

NaN не используется для вывода бесконечности, для этого есть своё значение.

Вероятнее всего там было что-то вроде такого:

loop {
    direction = update_direction(direction);

    if direction < 0.0 {
         turn_left();
    } else {
         turn_right();
    }
}

Если значение direction равно NaN, сколько его не обновляй, машина всегда будет крутить в право.

Ну, в контексте гонок DNF — это один из возможных FUBAR'ов (или SNAFU, в зависимости от причины самого DNF).

Там вроде еще был шикарный комментарий в стиле «единственный случай в истории, когда Java не тормозила» :)

У них должен был быть signalling NaN, а был quite.

UFO just landed and posted this here

Ух, nan'ы — это очень сложный тип данных. Сложнее только указатели. Там же не только nan'ы, но и ещё пачка мерзости. Разнознаковые нули, ненормализованные мантиссы. Это не говоря уже про PartialOrd (вместо Ord), и ошибки округления, которые типа-фича.

По идее должен быть дублирующий процес который следит за «адекватностью» даже если технически атрибуты правильные — в данном случае он бы не позволил тронуться при заблокированом рулевом имхо
Что по вашему означает «заблокированное управление»?
Оно не было заблокировано ни одним штатным способом, оно просто не могло изменить значение потому что операции с NaN приводят к NaN.
Ваш комментарий равносилен «они должны были сделать дублирующий процесс, которые проверял бы значения на NaN». Потому что никакая другая проверка по сути здесь не помогла бы.
«что-то произошло, и это, по-видимому, привело к тому, что сигнал рулевого управления перешел на NaN, а затем рулевое управление заблокировалось на максимальном уходе вправо»
Я о том что неважно NaN или NULL, и не дублирующая проверка, а проверка «логичности» тоесть в данном случае если автомобиль стоит на старте — то значение положения колес должно быть «прямо» и не позволять начать двигаться пока это не измениться, равносильно не начинать движение если открыта дверь, багажник и т.д.
Скорее, должен быть процесс, который следит, что результат движения совпадает с намерением. А то, вообще говоря, кроме багов ещё существуют и непредсказуемые внешние условия — например животное попало под колесо или ещё что-нибудь такое. Даже если бы и не было проблем с рулём, то всё равно нельзя автоматически верить, что если у тебя колёса направлены вперёд, то и едешь ты вперёд.
да, в том числе скажем не начинать двигаться если машина скажем находиться кверху колесами, тоесть для нас кожаных этих самых :) это понятная интуитивная логика же а вот машине нужно все обьяснять, ей же все равно в низ колесами или вверх колесами :) другое дело что такое казалось бы не возможно — но, это как хамер перевернуть (с)
Ну вот, а писали бы на NodeJS — получили бы undefined, а он привелся бы к нулю. Наверное
В JS тоже есть NaN :) И он бы не привелся к нулю. По поводу приведения типов есть хорошая игра: eqeq.js.org

Увидел NaN в заголовке, подумал, уж не на js ли робомобили кодить начали

Хоть до первого поворота бы доехало)
безопасность превыше производительности. наверное
Если где-то в вычислениях возникает NaN, то все зависящие от этой переменной данные дробных типов, в т.ч. телеметрия, тут же превращаются в NaN, разве не так?

Вопрос: баг на проде, кто виноват разработчик или тестер? :D

Или менеджер, который выстроил процесс? :)
Скорее надо искать, не кто виноват, а как избежать такого в будущем.

Главное к самолётам этих программистов не пускайте

Где-то в рубрике «гейзенбаги народов мира» читал про систему корректировки бомбометания, которая постоянно падала от одного конкретного пилота. Выяснилось, что он наводил самолёт с такой точностью, что это вызывало вещественное деление на ноль.

Звучит как-то слишком фантастически, чтобы быть правдой. Источника не сохранилось?

Читал давно и вроде в бумаге. Сейчас не смог найти.
В случае half precision или fixed point это более правдоподобно.
Было бы ещё более забавно, если бы оказалось, что в телеметрии была сделана проверка на NaN, но тупым и неправильным способом:

isValidValue = value !== NaN;

Что-то Хабр желтеет с такими заголовками:
Гоночный робомобиль врезался в стену из-за присвоения одной переменной NaN

В самой статье же указана причина в виде:
что-то произошло, и это, по-видимому, привело к тому, что сигнал рулевого управления перешел на NaN


Я бы понял, если б это было на каком-нибудь сайте, далеком от технологий, но здесь даже ежу понятно, что дело не в NaN.
Это как в том анекдоте, где причина смерти — не попадание пули в организм, а обширная кровопотеря.
Оборвался датчик поворота — датчик вернул NaN — обрыв датчика, как оказалось, никак не проверяется — можно продолжать ехать.
Roborace явно был фанатом Томми!
Написать новость, конечно, хорошо, но разобраться бы тоже неплохо) Справедливости ради: болид находился под управлением софта одной из команд. Суть гонки в «соревновании» команд в умении писать софт, который рулит технически иденитичными ТС. С учетом данного контекста вот это:
«Робомобиль Roborace, участник беспилотных автогонок в рамках этапов Формулы Е, врезался в бетонную стену во время прямой трансляции в Twitch»
должно звучать как:
«Робомобиль Roborace, участвуя в беспилотных автогонках в рамках этапов Формулы Е*, находясь под управлением ПО команды „The Acronis SIT Autonomous“ врезался в бетонную стену во время прямой трансляции в Twitch»

* Кроме того, ставлю под сомнение, что гонка проходит как этап Формулы Е. Дайте пруф, а в противном случае абзац должен принять следующий вид:
«Робомобиль Roborace, участвуя в беспилотных автогонках Season Beta, находясь под управлением ПО команды „The Acronis SIT Autonomous“ врезался в бетонную стену во время прямой трансляции в Twitch»
Sign up to leave a comment.

Other news