Световая адаптация к яркости — это чисто механическое изменение площади зрачка, не имеющее никакого отношения к обработке сцены в мозге. Просто диафрагмирование.
С точки зрения микропроцессора, никаких вещественных чисел нет. Он оперирует целыми битами в регистрах, абсолютно детерминированно. Но когда вы начинаете интерпретировать эти биты, как приближение идеальных математических вещественных чисел, в результате этого приближения и появляются все те проблемы с точностью вычислений, которые обсуждаются.
Что касается человеческого «компьютера». Если вы запомните хотя бы матрицу 10*10 вещественных чисел, то уже можете считать, что у вас хорошая память. Никаких миллиардов чисел там и близко нет. Есть электрохимические потенциалы нейронов, имеющие, впрочем, очень высокую точность по сравнению с точностью результата. Достаточно их чуть-чуть поменять, например, гормонами — и результат работы мозга меняется радикально.
Собственно, компьютер производит именно миллиарды последовательных вычислений, результатом которых является состояние регистров процессора. Но так как это цепочка логических операций, а не вещественных (с точки зрения работы самого компьютера), то она выполняется без погрешности.
Видеоизображение состоит из целых чисел, точность которых может не уменьшаться при операциях с ними. То же самое с программной памятью компьютера, которая, к тому же, используется далеко не полностью каждую секунду, а очень выборочно. То же с нейронной сетью.
На самом деле речь идёт просто о том, что машинный результат операции не обязательно является ближайшим представимым приближением к идеальному результату. Но при этом если идеальный1 > идеальный2, то и машинный1 >= машинный2.
Давно известны строгие математические оценки на этот счёт, с которыми автор статьи не дал себе труда познакомиться, прежде чем заявлять о преимуществе float (или, тем более, half) для экономии памяти. Предположим, у нас есть 4 гигабайта памяти, то есть миллиард чисел типа single. Чтобы получить из анализа всех этих данных какой-то практический результат, мы должны произвести, как минимум, миллиард последовательных операций над ними (иначе либо мы используем не все данные, либо цепочка операций не сойдётся к одному результату). При погрешности полбита на операцию, мы получаем в результате потерю точности не менее полумиллиарда цены младшего разряда, или 9 десятичных цифр, что уже превосходит всю разрядную сетку float. Вот и весь лёнинг.
Это не относится к параллельным преобразованиям из матрицы в матрицу. Но матрица из миллиарда чисел не может непосредственно восприниматься человеком и потому не является конечным результатом.
17 цифр достаточно для большинства применений. В двойной точности работает большинство численных библиотек. С другой стороны, 64 бита – удобный размер для выравнивания в памяти.
Четырёхбайтовые вещественные числа – реликт времён, когда память была ограничена 64 килобайтами.
Смотрите по слову ОКПДТР. Интересно, что классификатор допускает такие должности, как «пятый помощник программиста», «участковый программист», «районный программист» и «горный программист» :)
Вопрос же не в том, сколько символов и в каком месте менять, а в том, как это заметить. Вы описываете внесение двух изменений: добавление проверки делимости на 7 и добавление вывода строки «Piss». Очевидно, обе эти вещи надо где-то прописать. В Вашем случае они будут находиться в одной строке, а в примере выше – в разных строках, но это ничего не меняет.
Если говорить о новых изменениях, представьте себе, например, что заказчик решил буквально чуть-чуть уточнить условия задачи и ввести список чисел, которые делятся на 3, но не относятся к категории Fizz, делятся на 5, но не относятся к категории Buzz и т.п., в результате чего условия by3 и by5 – это теперь запросы к базе данных исключений из правил, которые занимают по 10 минут.
Ваш код более читабельный, но код по ссылке менее хрупкий (fragile).
Ваш код (и другие приведённые здесь подобные ответы) порождает раздумья сопровождающего его программиста вот над какой проблемой: если мы в одном месте поменяли, например, by3 на какое-то другое условие, надо ли проводить такую же замену в другом месте? Эта дилемма возникает при кодировании совершенно на пустом месте, потому что постановка задачи её не предопределяет, и в коде по ссылке её просто нет.
Это не относится к параллельным преобразованиям из матрицы в матрицу. Но матрица из миллиарда чисел не может непосредственно восприниматься человеком и потому не является конечным результатом.
В научных расчётах half precision точно не имеет никакого применения.
Четырёхбайтовые вещественные числа – реликт времён, когда память была ограничена 64 килобайтами.
Если говорить о новых изменениях, представьте себе, например, что заказчик решил буквально чуть-чуть уточнить условия задачи и ввести список чисел, которые делятся на 3, но не относятся к категории Fizz, делятся на 5, но не относятся к категории Buzz и т.п., в результате чего условия by3 и by5 – это теперь запросы к базе данных исключений из правил, которые занимают по 10 минут.
Тут можно много чего напридумывать.
Ваш код (и другие приведённые здесь подобные ответы) порождает раздумья сопровождающего его программиста вот над какой проблемой: если мы в одном месте поменяли, например, by3 на какое-то другое условие, надо ли проводить такую же замену в другом месте? Эта дилемма возникает при кодировании совершенно на пустом месте, потому что постановка задачи её не предопределяет, и в коде по ссылке её просто нет.