- 1
https://hackaday.com/2015/10/22/an-improvement-to-floating-point-numbers/-
Куча / Говнокод #26527
+1
Оказывается, тут уже пытались решить плававющую проблему с помощью плавающей длины составных частей плавающей проблемы: не влезает - увеличь мантиссу. Впрочем, то, что значения типа 1/3 всё равно не получится записать, никого не смутило.
Запостил:
Fike,
25 Марта 2020
Follow us!
Один мудрый человек, однажды заметил:
«Патаму что это плавающий питух, который априори говно. И чем вы быстрее это поймёте, тем будет лучше.»
В ЯВУ, если мы действительно хотим высокоуровневый нужно завезти понятия групп, кольца и поля.
Полугруппа (а точнее моноид) может выражать любые бинарные операции, от сложения (конкатенации) строк до всякой экзотики.
В кольце целых чисел будут определены операции сложения, вычитания и умножения.
int32_t — типичное кольцо. Деление не должно давать целый тип, поскольку для целых оно является необратимой операцией.
Кольцом могут быть комплексные целые (т.н. гауссовы числа).
При выполнении деления мы переходим из кольца целых в наиболее тривиальное поле рациональных чисел.
Соответственно значения типа 1/3 будут выражаться структурой двух intов.
Которую до сих пор не переварили промышленные языки.
Иммутабельность, лямбды и паттер-матчинг худо-бедно освоили.
А моноиды, теорию категорий и всякие суммарные типы вроде tagged union пока нет.
Я к тому что для некоторых типов (строки) деление нужно сделать невозможным в принципе.
Для некоторых (инты) оно должно по дефолту возвращать рациональные дроби.
Соответсвенно все типы выписать в 4 категории: перегружено сложение (моноид), перегружено сложение+вычитание, перегружено сложение+вычитание+умножение (кольцо), перегружены +-*/ (поле).
Что реально существует - измерения. И у измерений существует погрешность. При кобенации вычислений бе-бе-бенарным оператором погрешность преобразуется. Для вычисления кобенаций ошибок можно взять хотя бы гауссову питушню как модель. Однако, можно напердолить отдельных типов для диапазонов, полуотрезков и произвольных распределений ошибки.
Сразу поубавится пердолинга в реальных задачах, которые описывают реальный мир. То же деление на ноль во многих случаях заменится на деление на мелкого питуха.
>Ко-ко-ко, математузи. Чисел не существует, математическая питушня не нужна.
Годно )))
А также ноль может вылезти и в числителе. Это тоже не всегда приятно.
Ещё квадрат длины измеренного или посчитанного из измерений вектора может стать отрицательным, какой багор )))
Если погрешность измерения оценена адекватно, такие ситуации можно сгладить.
ЩИТО?
>А как поделить два Rational?
Перемножить крест/накрест. 4й класс.
Азаза багор математуха.
Так сходу реальный пример не скажу. Но, допустим, есть уравнение a-b=v^2, a=10 +- 0.1, b=11 +- 1. Если не учитывать погрешности измерения, v^2=-1.
> Перемножить крест/накрест. 4й класс.
А как будет вести себя измеренный ноль в знаменателе?
Он может просто храниться в структуре как любое другое число.
Простейший случай:
Дроби в принципе не требуют от юзера никаких делений для выполнения над ними 4х арифметических действий и сравнений.
>Есть квадратное уравнение
> Если не учитывать погрешности измерения, v^2=-1.
Ну то есть мы начинаем брать корни и хотим вылезти в комплексную плоскость?
Уровень линукса "не смогли реализовать - значит не нужно".
Были два измерения: 0.5 +- 0.1 и 0 +- 0.1. Как видим, второе с вероятностью 1 не ноль.
Кастуя их к анскильному Рационалю, получили две дроби, 1/2 и 0/1. Надо поделить первую на вторую. Что делать?
> Ну то есть мы начинаем брать корни и хотим вылезти в комплексную плоскость?
Кто мы? Это питушок процессор, которому не сообщили про погрешности, хочет вылезти в комплексную плоскость. А у нас длина вектора не может быть меньше нуля, вылезать в комплексную плоскость не нужно.
Зачем? Зачем?
Помните, как измеряли скорость света лампой? Можно было сказать, что время было ноль, а можно - ноль с точностью до времени реакции человека. И в результате скорость будет не тупой бесконечностью, а питушнёй с нижней (скорость для задержки, равной времени отклика человека) и верхней (бесконечность - когда человек точно среагировал) оценками.
вам это не нужно
мы знаем лучше
Если хочешь считать что у тебя не 0, а бесконечно малое число, можно просто не обращать на него внимание и считать с ним, тогда у ратионаля будет 0 в знойменателе он буде считаться бесконечностью.
Кстати, я не понял, ты топишь против дробей, но за (что?)?
Не нужная в абсолютном большинстве реальных задач питушня. Она нужна только учёным, которые работают непосредственно с измерениями. И у них точно есть специализированные матанные либы для такой математики.
Реальный пример: если ты поделишь в такой математике приведённые тобой
>>> 0.5 +- 0.1 и 0 +- 0.1
, то внезапно получишь объединение двух лучей бесконечной длины: (-∞; -4] ∪ [4; +∞). Где такой результат может пригодиться, помимо специализированных матанных пакетов и либ для физиков с БАКа — вопрос очень крепкий.
Да и там, скорее всего, переформулируют эксперимент чтобы не получать эту рандомную херню...
Вычитание одинаковых чисел и деление на число в окрестности нуля не особо поощряется вроде т.к. вся полезная инфа теряется на фоне шума измерений.
И потом уже дисперсии, мат. ожидания, итд.
Крутишь телефон в дополненной реальности - у тебя гироскоп и акселерометр выдают измерения.
Сигналы со спутников и определение координат - измерения.
Зожатие картинки с телефона - зожатие измерений (можно выкинуть шум, если знать точность измерений для данного уровня ISO).
Сырые координаты мыши - измерения.
Измерение количество данных за блок времени и блока времени (для оценки скорости соединения с интернетами) - измерения.
> специализированные матанные либы для такой математики
Действительно?
Мне кажется, сортов погрешностей слишком до задницы и их распределений слишком до задницы, чтобы напилить для этого спецлибу. Или же быстрей посчитать отдельно значение, а отдельно несколько сортов погрешностей, чем использовать тип с погрешностями.
Тип с погрешностями как раз более удобен для ненаучной питушни, которая не требует сверхцарского пирфоманса.
Скоро и вы все станете удобрением для берез.
-1 с диапазонами будет чем-то [-1.01; 0.01], что можно привести к [0; 0.01].
(-∞; -4] ∪ [4; +∞) без диапазонов будет просто ∞.
То есть такие типы с погрешностью работают только со сложением, вычитанием и умножением.
> -1 с диапазонами будет чем-то [-1.01; 0.01], что можно привести к [0; 0.01].
Ничего не понял. «-1 +- 0.01» — это [-1.01; -0.99], как ты его сведёшь к [0; 0.01]?
Ну и всё ещё остаётся проблема интерпретации: как UI должен нарисовать отрезок с длиной [-1.01; -0.99]? Тепловой картой?
Почему??? С делением так же работают.
Ну я же написал всё.
Я писал, что -1 и -4 - это вообще из разных опер.
Вы взяли число -1, полученное разностью и протестировали на нём вореант без учёта погрешностей.
Потом взяли бесконечность, полученную делением и протестироали на нём вореант с учётом погрешностей.
Не надо так. Надо тестировать методы в одинаковых условиях.
-1 это [-1.01; 0.01]
∞ это (-∞; -4] ∪ [4; +∞)
-1 это не (-∞; -4] ∪ [4; +∞)
> «-1 +- 0.01» — это [-1.01; -0.99], как ты его сведёшь к [0; 0.01]?
Нет. Отрицательной длины в пределах погрешности быть не может.
В этом случае должно быть floating point exception. Такой случай эквивалентен получению signalling nan в вычислениях.
Получение [-1.01; -0.99] сигнализирует о том, что погрешность фактически оказалась больше, результат - недостоверное говно и все вычисления стоит выкинуть.
Длина отрезка при вычислениях с погрешностями должна захватывать неотрицательную питушню.
Свести к [0; 0.01] можно какой-нибудь питушнёй вроде накладывания фактов.
Эдакий математический assert
[-1.01; 0.01] + (>=0) = [0; 0.01]
[-1.01; -0.99] + (>=0) = FPE
В какой нотации? «-1 с погрешностью +- 0.01» — это «[-1.01; -0.99]».
> ∞ это (-∞; -4] ∪ [4; +∞)
Что?!
> Нет. Отрицательной длины в пределах погрешности быть не может.
С тем же успехом можно заявить, что отрицательных чисел в плавающем питухе быть не может.
> Получение [-1.01; -0.99] сигнализирует о том, что погрешность фактически оказалась больше, результат - недостоверное говно и все вычисления стоит выкинуть.
Получение -1 сигнализирует о том, что погрешность фактически оказалась больше, результат - недостоверное говно и все вычисления стоит выкинуть.
> [-1.01; 0.01] + (>=0) = [0; 0.01]
Ну и что мне мешает сделать то же самое с обычными плавающими питухами, без этой математической питушни?
Ну посмотрите, о чём говорилось выше.
Мы делили на питушню около нуля, вышла оценка (-∞; -4] ∪ [4; +∞). Если бы не учли, была бы бесконечность.
>> Нет. Отрицательной длины в пределах погрешности быть не может.
> С тем же успехом можно заявить, что отрицательных чисел в плавающем питухе быть не может.
Почему? Покажите мне отрезок с отрицательной длиной.
Питух-абстрации вроде направленной площади и направленного объёма, разумеется, не считаем. Речь шла об обычном отрезке, для которого длина - sqrt((x1-x0)^2+(y1-y0)^2), для которого питушня под корнем - проблема.
Для направленного отрезка с отрицательной длиной никаких проблем нет - его в контексте обсуждения можно не рассматривать.
> Получение -1 сигнализирует о том
Именно! Поэтому я за тип с погрешностями. Пока анскильные типы выдают -1, которое выбрасывается, тип с погрешностью выдаёт [-1.01; 0.01], которое можно интерпретировать.
> Ну и что мне мешает сделать то же самое с обычными плавающими питухами, без этой математической питушни?
Отсутствие бесконечного времени?
А что, кто-то так часто делает?
Или, может быть, кто-то постоянно пишет длинную арифметику вместо того, чтобы страдать от переполнений?
Нет, не делают. Либо ловят переполнения, либо используют питон, где всё это встроено, и думать не надо.
Так же с плавтузом: либо писать самому пердолинг с контролем нулей для целых на каждом шагу, либо написать формулу целиком, посчитать на плавтухах, а затем проверить один раз, нан это, инфинити или нормальное число. Второй вариант дешевле и надёжней.
Ну ладно, а в чём разница? Что первое, что второе — неюзабельная питушня.
>>> То же деление на ноль во многих случаях заменится на деление на мелкого питуха.
Я и показал, что нет, не заменится. Если в пределах погрешности есть ноль — мы в любом случае получим какое-то говно бесконечной длины.
> для которого питушня под корнем - проблема.
Выражение «(x1-x0)^2+(y1-y0)^2» всегда неотрицательно. В обычных плавающих питухах — оно либо неотрицательно, либо +inf, либо nan. Никакой проблемы нет.
> Пока анскильные типы выдают -1, которое выбрасывается, тип с погрешностью выдаёт [-1.01; 0.01], которое можно интерпретировать.
Я с точно таким же успехом могу округлить -1 до ближайшего неотрицательного. Никакой разницы не будет.
> Отсутствие бесконечного времени?
Сделал это за конечное время, проверь.
> Так же с плавтузом: либо писать самому пердолинг с контролем нулей для целых на каждом шагу, либо написать формулу целиком, посчитать на плавтухах, а затем проверить один раз, нан это, инфинити или нормальное число. Второй вариант дешевле и надёжней.
Повторюсь, жирным: если в отрезок с погрешностью входит ноль, в результате деления на этот отрезок мы получим абсолютно бессмысленный результат. Это ничем не отличается от деления на нулевого плавающего питуха. Тип с погрешностью никак не спасает от деления на ноль.
> Ну ладно, а в чём разница? Что первое, что второе — неюзабельная питушня.
Вы таки троллите? Вы сами отрисовали отрезок длиной -1 классическим методом, а числам с погрешностью отдали что так, что так неюзабельную питушню (-∞; -4] ∪ [4; +∞).
> Выражение «(x1-x0)^2+(y1-y0)^2» всегда неотрицательно.
Это да, но, например, (x1-x0)^2 и (y1-y0)^2 могут быть косвенно измерены. И тогда проблема есть.
Я написал (x1-x0)^2+(y1-y0)^2, чтобы показать, что это обычный отрезок.
> Я с точно таким же успехом могу округлить -1 до ближайшего неотрицательного. Никакой разницы не будет.
Разницы в поведении не будет, разница будет в идеологии и реализации.
Я могу сконкатенировать много строк вида "Content-Type: pitux" и "HTTP GET /" и отправить на сервер, а могу воспользоваться библиотекой и решить вопрос в одну строку.
> Сделал это за конечное время, проверь.
А теперь надо добавить это вручную во все программы.
> Тип с погрешностью никак не спасает от деления на ноль.
Спасёт. У нас останется дополнительная информация, которую можно впоследствии использовать.
(-∞; -4] ∪ [4; +∞) получается, если использовать обычный тупой интервал с равновероятными значениями.
А можно показать, что вероятность нуля - ноль. Скажем, выяснить, что с вероятностью 95% будет не бесконечность, а семёрка, заменить на (-7; -4] ∪ [4; 7).
P.S. А главное - эту вероятнушню будет разгребать сам процессор! Использовать такие числа сможет даже анскиллушок, главное - не похерить погрешности, которые придут с датчиков.
> А теперь надо добавить это вручную во все программы.
Добавил. Теперь тебе нужно добавить во все программы, что [-1; +0.01] должно округляться до 0.01. Или оно само магическим образом сконвертируется, когда алгоритму понадобится точное явное значение числа?
> Спасёт. У нас останется дополнительная информация, которую можно впоследствии использовать.
И кому нужна эта информация? Как я буду поворачивать камеру в VR-шлеме на (-∞; -4] ∪ [4; +∞) градусов?
> если использовать обычный тупой интервал с равновероятными значениями.
> А можно показать, что вероятность нуля - ноль.
А это совершенно неважно. Если в интервале есть окрестность нуля, хотя бы и проколотая, в результате всё равно получится бесконечная питушная.
> Скажем, выяснить, что с вероятностью 95% будет не бесконечность, а семёрка
Выяснить как? По каким законам?
> А главное - эту вероятнушню будет разгребать сам процессор!
Процессор — не волшебник в голубом вертолёте, он никак не сможет понять, что у тебя за погрешности и с какого прибора они пришли. Он даже в теории не может знать, какое у тебя там распределение вероятностей, какие характеристики гауссианы или вообще бета-распределения. То есть тебе в любом случае надо будет всю эту математическую питушню забивать и обрабатывать ручками.
И да, и нет.
1. Приведение к фиксированному числу можно сделать автоматическим, как я уже где-то писал. Рисовалка пикселей и отрезков принимает диапазоны, как-то сама с ними пердолится.
2. Приведение [-1; +0.01] к [0; +0.01] - добавление фактов, должно решаться для каждого конкретного случая отдельно. Например, если [-1; +0.01] - температура за окном, то приводить к неотрицательному питуху нет смысла. Максимум, что можно сделать - оператор добавления фактов, который я упоминал. Его придётся использовать. Но всё равно код будет без ручного пердолинга
drawLine(..., [-1; +0.01] + (>0), ...)
> Как я буду поворачивать камеру в VR-шлеме на (-∞; -4] ∪ [4; +∞) градусов?
Либо не поворачивать, либо лучше оценивать ситуацию.
Я ведь показывал пример с 19, 20, 21, 19, ...? Либо у нас есть просто измерения с неизвестным шумом, которые можно только усреднить, либо у нас измерения с известной погрешностью, на которые можно кинуть математическую модель.
Скажем, известно, какие могут быть ускорения у человеческой шеи, характер движений исходя из строения мышц. Если натянуть информацию с погрешностями на мат. модель, можно построить аппроксимационную кривую, которая будет лежать в пределах погрешности (фактически - даже ближе к реальным данным, чем пределы погрешности).
Для чисел без погрешности мы не знаем, куда на сколько отступать, интерполяция просто будет пытаться как-то притянуть кривую к измерениям без учёта их качества.
Соответственно, камеру повернуть можно будет на более адекватное значение.
Чем это будет отличаться от существующей ситуации, когда рисовалка пикселей принимает плавающего питуха и сама с ним пердолится?
> drawLine(..., [-1; +0.01] + (>0), ...)
Хорошо, тогда что нам мешает использовать абсолютно такой же механизм для обычных плавающих питухов?
x = -1; drawLine(..., x + (>0), ...);
> Либо не поворачивать, либо лучше оценивать ситуацию.
И с обычным плавающим питухом мне придётся либо не поворачивать, либо лучше оценивать ситуацию.
> Я ведь показывал пример с 19, 20, 21, 19, ...? Либо у нас есть просто измерения с неизвестным шумом, которые можно только усреднить, либо у нас измерения с известной погрешностью, на которые можно кинуть математическую модель.
Так ведь нам всё равно придётся это делать явно. Мы всё равно будем писать питушню в духе «if (currentValue.accuracy < |lastValue - currentValue|) { currentValue = lastValue; }». Так зачем усложнять, вводя специальные типы, когда то же самое можно сделать гораздо проще?
> Для чисел без погрешности
Так ведь есть погрешность! Там, где она нужна, её можно получить одним простым вызовом и работать с ней как с отдельной сущностью (которой она и является).
И главное — типы с погрешностью всё равно никак не помогут анскилябрам, которые с ними не умеют работать. Им всё равно нужно будет самим строить интерполяционные кривые с учётом погрешностей, а это нифига не тривиальная задача, хоть с отдельными типами, хоть без.
Если уж мы хотим помочь анскилябрам — гораздо эффективнее будет просто написать либу, в которую можно будет скормить показания, а она, основываясь на информации о системных сенсорах, отдаст анскилябре хорошие, годные значения.
Ей больше информации.
Например, пиксель ширины 0.5.
Измерено число 3.2 с асиметричной погрешностью + 0.25 - 0.05
Нарисовать его можно в 2.5, 3.0, 3.5.
Без учёта погрешности - 3.2 ближе к 3.0, отклонение от диапазона 0.15.
С учётом погрешности - 3.2 ближе к 3.5, отклонение от диапазона 0.05. Нарисовалось точнее.
И если будет какое-то хитрое распределение, оно будет инкапсулировано в числе, рисовалке не надо будет самой решать одну и ту же задачу для Гаусса, диапазона, прочих вореантов.
> И с обычным плавающим питухом мне придётся
Значит, погрешной питух - не хуже подходит для решения тех же задач!
> придётся это делать явно
Нужен синтаксис для накладывания моделей. "+ (<0)" - явно, но сахарно!
> зачем усложнять
Чтобы получить простой выразительный код. В питоне тоже усложнили, но зато работа с длинными числами добавляет ноль синтаксиальной психозы. А в жс нужно добавлять постфиксы к числам.
> никак не помогут анскилябрам
> просто написать либу
Скорее всего да.
Тут уже нужен эксперимент. Написать либу и сахарок, посмотреть опыт использования - поможет ли знатокам, поможет ли анскиллябрам, поможет ли ххх. Оставить или выкинуть, в какую форму преобразовать.
Обычные плавтухи всё ещё сравнивают на равенство и забывают про наны, но зато плавпитухи много где помогли нормальным программистам.
Совсем не факт. Если это какая-то гауссопитушня (как оно чаще всего и бывает), то точнее будет нарисовать именно в 3.0.
> И если будет какое-то хитрое распределение, оно будет инкапсулировано в числе, рисовалке не надо будет самой решать одну и ту же задачу для Гаусса, диапазона, прочих вореантов.
Так ведь уже всё придумано до нас: с датчиков нам приходят плавающие питухи, в которых уже инкапсулирована гауссопитушня.
> Значит, погрешной питух - не хуже подходит для решения тех же задач!
Но и не лучше. А поскольку он тормозит и более сложен — обычный плавающий питух на тех же задачах его превосходит.
> Нужен синтаксис для накладывания моделей. "+ (<0)" - явно, но сахарно!
И всё равно любой синтаксис для накладывания моделей можно изоморфно перевести на плавающего питуха.
> Чтобы получить простой выразительный код.
А мы его не получим. Задача работы с погрешностями слишком сложна, чтобы её можно было прозрачно инкапсулировать в обычные числа.
> В питоне тоже усложнили, но зато работа с длинными числами добавляет ноль синтаксиальной психозы.
Усложнили внутреннюю реализацию, не внешний интерфейс. Система типов для чисел с погрешностью — это усложнение именно внешнего интерфейса.
Ну это если преобразовано в конкретное значение "пиши вот в тот пиксель". А если это ещё измерение, которое можно обработать, нужно отдельно получать погрешность.
> изоморфно перевести
Непонятное матерное слово. Математикам бы всё изоморфно перевести. Любую программу изоморфно перевести на брейнфак или в лямбдушню.
> Задача работы с погрешностями слишком сложна, чтобы её можно было прозрачно инкапсулировать в обычные числа.
А вот это нужно проверить. Может, получится найти нотацию поудачней.
Помните, как раньше комплекснушню и корни записывали? Какие-то буквы непонятные. А потом придумали современную нотацию и учат эту питушню в школе.
Возможно, текущая нотация [в ЯПах или математике] неоптимальна, а мы не осознаём её говнистости потому, что не видели ничего лучше.
Нет. Только в математике.
Какова вероятность, что два тела вдавили одно в другое, оставив расстояние ноль, что их сила притяжения стала бесконечной?
> По каким законам?
По законам физики. Расстояние между джвумя питухами не может быть нулевым. На каком-то этапе их атомы будут отталкиваться. Соответственно, мы накинем на интервал вероятность расстояния 0, 0.01А, 0.1А, 1А, 10А и т.д.
> Процессор — не волшебник
> математическую питушню забивать и обрабатывать ручками
Да, но можно сделать удобные инструменты для этого.
[-1; 0.01] * stats::curve11 + physics::law20
Длинную арифметику можно ручками писать, а можно питон использовать.
А без математики ты вообще ничего не посчитаешь.
Если ты вырежешь из отрезка только ноль, то всё равно сможешь выбрать такую точку, принадлежащую отрезку, чтобы результат деления на неё был сколь угодно большим (но ограниченный снизу). Это, собственно, и есть смысл «бесконечности» в матане.
> Какова вероятность, что два тела вдавили одно в другое, оставив расстояние ноль, что их сила притяжения стала бесконечной?
А это никак не относится к отрезку с выколотым нулём («вероятность нуля — ноль»). Нам всё равно придётся ставить какие-то питушарские эмпирические ограничения («тела не могут находиться ближе чем в X метрах друг от друга») и строить жосские матанные модели, вроде бета-распределения.
> Да, но можно сделать удобные инструменты для этого.
Только типы с погрешностью к этим инструментам не относятся. Просто потому, что если они будут простыми — на уровне хранения простых интервалов — то их нельзя будет использовать для решения реальных задач. Если они будут достаточно сложными для решения реальных задач — использовать их смогут только бородатые дяди, курившие матан последние лет двадцать.
> На каком-то этапе их атомы будут отталкиваться. Соответственно, мы накинем на интервал вероятность расстояния 0, 0.01А, 0.1А, 1А, 10А и т.д.
Именно об этом и я говорю: если мы будем впихивать в базовую систему типов законы квантовой механики — мы получим просто-таки хтоническое чудовище.
Тут два варианта.
1. бесконечность настоящая - вроде бесконечно удалённой точки, и тогда всем на неё пофиг, проблем нет, можно ноль не выкалывать.
2. бесконечность из-за погрешности измерения. Тогда будет минимальное ненулевое значение вроде 1/7, при котором бесконечность можно заменить на семёрку.
Есть вариант, когда есть несколько формул, в зависимости от значения их надо выбирать и они вместе не состыкованы. Тогда неясно, какую выбрать, если у нас намерен диапазон. И это будет проблемой. Хотя, физические формулы не должны создавать каких-то скачков, всегда есть плавный переход.
> если будут простыми — нельзя будет для реальных задач
> Если будут сложными — смогут только бородатые дяди
Надо сделать простыми с вариантами расширения.
Синтаксис f(x) = 2*x, f(g) = g(2) простой? А ведь только на нём можно напердолить жутких абстракций вроде Y и Z кобенаторов или посложнее, которые поймут только бородатые дяди.
Эй, эй, ты должен ругать абстрактных математузов, а не примкнуть к ним! Не бывает в реальном мире бесконечности, бывает только очень большое значение.
> Тогда будет минимальное ненулевое значение вроде 1/7, при котором бесконечность можно заменить на семёрку.
То есть в результате мы должны каким-то образом заменить результат измерения «[-1; 2]» на нечто вроде «[-1; -1/7] ∪ [+1/7; 2]»? И, главное, сделать это обобщённо?
> Хотя, физические формулы не должны создавать каких-то скачков, всегда есть плавный переход.
Вся квантушня дискретна. Но это так, отстранённое замечание.
> Надо сделать простыми с вариантами расширения.
Тогда все анскилябры будут пользоваться простыми умолчаниями, получая результаты ещё более неточные, чем с простыми плавающими питухами.
Физики запилили себе свою бесконечность с пустотой и вселенской тоской.
> сделать это обобщённо?
Достаточно ли обобщён "+"? А ведь с помощью него складывают и числа, и векторы, и матрицы, и прочую питушню, имеющую разные законы. Так же и тут будет какой-то уровень обобщение.
А на каком-то этапе - да, придётся вручную указать "тут прибавь неотрицательность".
> анскилябры будут пользоваться простыми умолчаниями
Опять же, нужно проверить на практике, где будет польза, где вред и в каких масштабах. Будет ли у этого порог вхождения как у 2+'2' в жс или как у (+) 2 2 в хаскеле.
Где-то на жс.ру читал, что замыкания не надо поначалу использовать, т.к. сложные. Может и тут скажут "сначала пишите без погрешностей".
Там тебя буду подстерегать Я.
Помню, как я переходил с понятного цикла на map/reduce, и теперь для меня map/reduce так же естественны, в некоторых ситуациях сразу приходят в голову как решение.
Питушня. Черпанём идею из природы. Из такой питушни состоит чуть менее, чем полностью наш мир.
Квантовый питух α|1>+β|0> при измерении переходит или в |1>, или в |0> в зависимости от случайного выбора и питушистости волновой функции.
Соответсвенно, для отображения необходимо выбрать самое адекватное решение.
Отрезок с длиной [-1.01; -0.99] вызывает FPE.
Отрезок с длиной [0; 0.01] может быть, например, максимально адекватным образом подогнан к пикселям. Подумайте, без погрешности число всё равно бы округлили до пикселей. А с погрешностью мы имеем больше возможностей понять, рисовать ли лишний пиксель, или нет.
Либо же можно вовсе рисовать [0; 0.01] как заблюренную питушню. Вот, скажем, отрезок длины [0.99; 1.01] может быть отрисован как питух длиной 0.99 и заблюренные питухи по краям длиной 0.01. Когда измерение неточные, объект на экране расплывётся как электрон по орбитали.
Реальный пример: программа для автоподстройки яркости экрана на свету. Работает она очень просто: когда освещённость телефона достигает, например, 1000 люкс или больше — яркость экрана меняется на, например, 20% от максимума. Теперь предположим, что люксметр телефона возвратил программисту «950 +- 100». Что программист должен с этим значением делать? Ничего. Он никак не сможет использовать эту информацию для решения проблемы пользователя. Ему в любом случае придётся проигнорировать «+- 100» и писать старые, скучные, неточные «if (lux >= 1000 { setBrightness(20); }».
> Крутишь телефон в дополненной реальности - у тебя гироскоп и акселерометр выдают измерения.
Зачем они их выдают? Чтобы учёный написал в своей статье, что поворот составляет x +- y, а ускорение — z +- w? Нет. Они их выдают для того, чтобы повернуть камеру на строго определённое число градусов. Повернуть её на «20 +- 1 градус» нельзя никак.
> Сигналы со спутников и определение координат - измерения.
Пожалуй, один из редких реальный пример того, где значение с погрешностью действительно нужно пользователю. Правда, зачем городить для этого аж целые новые типы, а не обойтись простым и понятным значением погрешности в отдельной переменной — непонятно.
> Зожатие картинки с телефона - зожатие измерений
И опять же, которые ничего нового пользователю не несут. Пользователю надо, чтобы по координатам (x, y) был отрисован пиксель с точно заданным значением RGB (HSV, CMYK, …). Как при помощи погрешностей измерений можно убрать шум — я не совсем понял, как и то, зачем для этого нужен отдельный тип с погрешностью.
А вот и нет. Во-первых, в зависимости от погрешности, можно решить, актуально ли измерение. Если там будет 950 +- 500, это одно. Если 950 +- 50 - другое. Вероятно, в первом случае стоит усреднить за большее время.
Или, если датчик сам читает, скажем, раз в 10мс, усредняет за 100мс и добавляет корень из дисперсии, то на дискотеке из-за фликеринга вырастет дисперсия. В этом случае программист косвенно поймёт, что происходит какая-то питушня и не будет моргать почём зря.
Программа анскильного питушка, который не учёл погрешность, будет моргать экраном как не в себя при любом повешении питушистости измерения.
> Они их выдают для того, чтобы повернуть камеру на строго определённое число градусов. Повернуть её на «20 +- 1 градус» нельзя никак.
Какой анскилл )))
Если измерения датчиков имеют погрешность (а это так и есть), эта питушня начнёт выдавать значения 20, 21, 19, 21, 20, 20, 21, 19. Анскильный питушок будет вертеть камеру на 20, 21, 19, 21, 20, 20, 21, 19. Смотрящего на экран будет подташнивать. Даже не знаю, что будет, если этот телефон подвяжут к линзочкам для ВР для бедных.
Пользуясь погрешностью, можно смотреть на динамику и двигать камеру на меньшие значения или вовсе не двигать, зная, что телефон повернули в пределах погрешности.
> строго определённое число градусов
Заблуждение зомбированного математиушка. Нет строгой определённости, если ты не знаешь, на сколько надо двигать.
Игнорирование погрешностей - один из больших анскиллов, который приводит к
* недостаточному выжиманию потенциала из датчиков
* созданию неюзабельного фликерящего говна
* созданию неюзабельного врущего говна, которое показывает шум и называет его сигналом
Сенсоры с динамической погрешностью? Ни разу таких не видел. Может, в какой-нибудь профессиональной области такое и есть, но в смартфоны обычно вставляют всякое китайское говно, которое в лучшем случае процентную погрешность имеет.
Ну и в любом случае, программисту придётся явно обрабатывать погрешность, писать что-то вроде «if (result.accuracy >= 500) { print('ya tebya ebal gad tvoi sensor tupoi'); }». Отдельный тип для такого совершенно не нужен.
Ах да, с учётом того, что погрешность встроенных в телефон сенсоров обычно не меняется на протяжении всего времени эксплуатации, проверять её в каждом измерении попросту избыточно.
> Программа анскильного питушка, который не учёл погрешность
Правильно: погрешность нужно учитывать. Как анскильному питушку в этом поможет отдельный тип с погрешностью? Никак.
> Пользуясь погрешностью, можно смотреть на динамику и двигать камеру на меньшие значения или вовсе не двигать, зная, что телефон повернули в пределах погрешности.
Правильно! В пределах погрешности, которую достаточно получить один раз при запуске приложения.
> Заблуждение зомбированного математиушка. Нет строгой определённости, если ты не знаешь, на сколько надо двигать.
Ты путаешь тёплое с мягким. Виртуальную камеру нельзя повернуть «примерно вот на столько». Ты в любом случае должен дать на вход алгоритму поворота какое-то точное число.
> Игнорирование погрешностей - один из больших анскиллов, который приводит к
И в решении всех этих проблем введение специального типа «число с погрешностью» не помогает ровным счётом никак.
Светопитушня как раз такая. Если с усилителем - тем более.
Банальная камера в шмартфоне - такой датчик. Микрофон - тоже.
Я вообще говорил про рассматривание набора измерений. Это может делать не сам датчик, но драйвер. На входе измерение с точностью до процента от полной шкалы, на выходе - то же, только усреднённое и с добавленной дисперсией.
> придётся явно обрабатывать погрешность
Здесь нужны свои операторы, да. Например, тринарное меньше, принимающее, скажем, пороговую погрешность. И бул на трит.
> погрешность встроенных в телефон сенсоров обычно не меняется
Не меняется только её неизменная часть :)
Но в телефонах есть же виртуальные датчики, которые показывают откалиброванные значения. И там погрешность уже нетривиально меняется.
> Как анскильному питушку в этом поможет отдельный тип с погрешностью?
> введение специального типа «число с погрешностью» не помогает ровным счётом никак.
Внутренняя математика может работать в фоне и помогать анскилушку.
Например, будет работать сравнение плавучих питухов. Потому, что в реальности они разнятся от накопления погрешности, а погрешность будет автоматически храниться и пересчитываться при оперециях.
Нет, не надо.
- Способность человека различить пиксели вполне потерпит разницу в одном-двух младших битов R/G/B. Тем более, если пользователь - мужик.
- Не у всех профессиональные мониторы. Банальная подсветка может быть градиентной и к краям сводить R/G/B единиц на 5-10 вниз.
- На экране может быть пыль или блики
Если даже вдруг надо, в чём я сомневаюсь, то физика никого об этом не спрашивают. Фотоны не слетаются на камеру, а просто хаотично долбятся в пиксели матрицы. В итоге всё определяется статистическим питухом и на изображении появляется шум.
Отображать пикселюшню можно только в пределах погрешности. Точнее - нет никакого смысла.
> Как при помощи погрешностей измерений можно убрать шум
Смотрим, что погрешность не меньше 16, и отсекаем 4 бита как ненужные.
> зачем для этого нужен отдельный тип с погрешностью
Для универсальности зожатия. Архиватор уже знает, ему передают непогрешимую бинартушню с программой или шумное говно с микрокамеры телефона.
И опять — они нужны только для того, чтобы отрисовать курсор в строго определённом месте.
> Измерение количество данных
Количество данных может быть измерено точно, погрешность будет только во времени. Но да — это пример, аналогичный GPS, здесь погрешность пользователю нужна (хотя по сравнению с погрешностью от нестабильности канала она всё равно будет настолько мизерная, что ей запросто можно пренебречь). А отдельный тип — не нужен.
> Или же быстрей посчитать отдельно значение, а отдельно несколько сортов погрешностей, чем использовать тип с погрешностями.
Да, я это и имел в виду. Ну и интервальную арифметику: «Wolfram Alpha», например, успешно понимает синтаксис вида «interval [0.9, 1.1] + interval [0.05, 0.15]».
> Тип с погрешностями как раз более удобен для ненаучной питушни, которая не требует сверхцарского пирфоманса.
Как я выше показал, ненаучной питушне он попросту не нужен, поскольку пользователю совершенно не интересно, с какой погрешностью отображается курсор на его мониторе. А в тех редких случаях, когда погрешность всё таки интересна (то есть когда пользователя интересует непосредственно результат измерения) — гораздо удобнее оперировать ею отдельно, а не выдирать из результата.
Ха! Нет строго определённого места.
Хотя, кому я говорю. Зомбированным математикам не понять питушни физического мира.
Нет точного места, где надо отрисовать курсор. Его просто нет. Есть только область, в которой курсор может быть с какой-то вероятностью по неточным данным мыши.
И если бы анскильные погромисты не верили координатам с мышей, можно бы было гораздо легче пользоваться говномышами за 50 рублей. Указатель бы так не скакал, можно было бы как-то реализовать более адекватное поведение.
> пользователю совершенно не интересно, с какой погрешностью отображается курсор на его мониторе.
Погрешность не всегда нужно показывать пользователю. Однако, питушню с низким SNR и игнорирование большой погрешности пользователь сразу чует, плюётся и обзывает говном.
Хороший пример - тачскрины. Там можно долго пытаться намеренно сделать какой-нибудь жест или клик в нужное место, но если чуть-чуть случайно коснуться, этот жест сделается сам в ненужное время в ненужном месте.
И ты опять путаёшь реальный мир с цифровыми абстракциями. У меня на экране есть ровно 1920*1080 мест, в которых курсор может быть отрисован. И вот хоть какие типы с погрешностью используй — в каком-то другом месте моего монитора курсор быть не может.
> Указатель бы так не скакал, можно было бы как-то реализовать более адекватное поведение.
С неадекватным поведением курсора из-за говносенсоров программисты борются с самого момента изобретения мыши (Винда, например, имеет специальный режим «повышенной точности указателя мыши», который работает весьма неплохо). Отдельный тип с погрешностью им в этом никак не поможет.
И вообще, у меня такое впечатление, будто я сказал тебе, что учитывать погрешность вообще не нужно. Нет, это не так: нужно. А вот городить для этого отдельные типы — нет.
Хуита, попробуй подключить к своем видеоглазку какой-нибудь ватком.
А программушки часто пытаются притащить сырое число и сделать из него математического идола (вроде мифического конкретного поворота на 20 градусов)
> Нет, это не так: нужно. А вот городить для этого отдельные типы — нет.
Ну аналогично, проверять ошибки нужно, а вот городить отдельное Maybe - нет.
Maybe не является необходимым, но просто сокращает пердолинг.
В типе с погрешностями можно инкапсулировать некоторые математические питушни для примирения физического мира и математической природы плавающего питуха.
Как минимум, ради того, чтобы не городить пердольную питушню на сравнение плавтухов, лучше запереть погрешности в тип и инструкции процессора.
А клик мышкой будет проходить по некоторой области, захватывая все контролы из неё? Что-то мне это совсем не нравится. В текущей парадигме я даже самую хуёвую мышь могу кое-как подвести к нужной кнопочке и нажать её.
> но просто сокращает пердолинг.
Типы с погрешностью могут сократить пердолинг разве что бородатым физикам на БАКах (впрочем, вряд ли, учитывая, сколько этих самых видов погрешностей бывает). Обычным людям вполне достаточно джвух значений — результата и погрешности. Потому что в любом случае программисту нужно будет отдельно обрабатывать погрешность, а отдельно — результат.
> Как минимум, ради того, чтобы не городить пердольную питушню на сравнение плавтухов, лучше запереть погрешности в тип и инструкции процессора.
Ну, в принципе можно запилить новые инструкции, вон, как AES-NI запилили. Только зачем это нужно? Если в программе вычисление погрешностей — боттлнек, то с программой явно что-то не так.
Ладно мышь. Мышь - устройство для передвижения, там можно смотреть траектории и петушить их какими-нибудь алгоритмами.
У мыши фаззёвая только дельта, а не само пятно указателя.
С тачскрином как раз тот случай, когда пользователь задаёт пятно, которое измеряется за один раз.
И тут надо смотреть, что из контролов покрыло это пятно. Если только один, то можно нажимать. Если больше одного, то точности не хватает.
> впрочем, вряд ли, учитывая, сколько этих самых видов погрешностей бывает
Думаю, подойдут унаследованные типы с кастомной погрешностью. То же самое, что и наследование от исключений.
Правда, применить это смогут только когда построят ОАК (о - огромный) и БАК станет мелким экспериментом, результаты которого можно будет посчитать на паре обычных пек.
Сейчас же можно вместо погрешностей либо пустить вычислительную мощность на эффективные алгоритмы, либо сделать обработку бОльшего количества данных. Либо конкуренты построят АКЧП (чп - чуть поменьше), где за счёт вычислительных ресурсов, пущенных в более правильное русло, сольют БАК с типами с погрешностью.
> в любом случае программисту нужно будет отдельно обрабатывать погрешность, а отдельно — результат.
Это если математика не разработана настолько, чтобы спрятать работу с погрешностью.
Я верю, что можно нафигачить либо спецопераций, либо в функции добавить этот пердолинг.
Например, один раз спрятать в отрисовку пикселя алгоритм вычисления exact значения из типа с погрешностью, и дальше программист об этом может даже и не вспомнить.
Ну может быть, где-то будет настройка уровня "рисовать размыто" или "рисовать чётко".
> в программе вычисление погрешностей — боттлнек
Я-то хочу сразу это впердолить в числа. Чтобы даже 0.1 + 0.2 = 0.300000001 уже было, скажем, 0.3 +- 1e-8, а 0.1 + 0.2 + 0.1 + 0.2 было 0.6 +- 2e-8 и т.п. Чтобы все операции с плавтухом тормозили из-за погрешностей.
Не, это слишком жёстко. У меня на смартфоне, например, практически все контролы гораздо меньше пальца — и ничего, вполне успешно попадаю, ОС довольно точно определяет, куда я хочу нажать. А с таким подходом смартфонами вообще нельзя будет без стилуса пользоваться.
> Например, один раз спрятать в отрисовку пикселя алгоритм вычисления exact значения из типа с погрешностью, и дальше программист об этом может даже и не вспомнить.
Так ведь это в точности то, как оно есть сейчас! Только вычисление exact точного явного значения происходит на этапе обработки данных с сенсоров.
> Я-то хочу сразу это впердолить в числа.
Это плохо. Во-первых — без возможности рагулировать эпсилон это будет неюзабельной питушней. Во-вторых — а в чём, собственно, хранить погрешность? И как нивелировать погрешность погрешности?
Может быть. Однако, меня выбешивает, когда специально что-то сделать нельзя, а случайно оно получается само. Хоть бери и начинай хаотично перебирать пальцами по телефону в кармане, чтобы написать важное письмо.
> в точности то, как оно есть сейчас!
> на этапе обработки данных с сенсоров
Ну это тогда выходит более монолитная система. Для переиспользования кода удобно всякую питушню по-бюрократски передавать от функции к функции.
> а в чём, собственно, хранить погрешность?
Тут надо смотреть и исследовать. Обычных-то чисел по внутреннему устройству - минимум три основных сорта на язык - знаковые, беззнаковые, плавающие. В случае с погрешностями нужны будут точно нужны
* диапазоны
* гауссова питушня с дисперсией (если записывать как диапазон, расплывётся на всю действительную ось, но для большинства значений вероятность появлениия крайне мала)
* их комбинация
* кастомные варианты
> И как нивелировать погрешность погрешности?
Интересный вопрос. Я бы его оставил математикам и отложил до тех пор, когда будет реализована первая версия полноценной библиотеки, где почти не будет надобности переходить в обычные числа руками.
Обычно точность погрешности не настолько важна, как точность значения. Можно либо обойтись математикой (главное - чтобы погрешность погрешности не была слишком велика, а сама погрешность - занижена), либо добавить погрешность погрешности или потом ещё погрешность погрешности погрешности. Вложенность не будет бесконечной, поскольку на каком-то этапе окажется, что точности уже достаточно.
Не знаю, я слишком редко с таким сталкиваюсь. Возможно, это потому что у меня лопата на шесть дюймов.
> кастомные варианты
Вот в них и вся проблема. Этих кастомных вореантов столько, что впихнуть их в одну-единственную систему практически невозможно. В результате мы либо получим слишком простую систему, которая на реальных задачах ничем от плавающего питуха отличаться не будет, либо слишком сложную, которую среднестатистическая анскилябра попросту не осилит.
> погрешность погрешности или потом ещё погрешность погрешности погрешности
Боюсь, реализовать либу, которая сможет корректно обрабатывать погрешность погрешности погрешности, будет весьма проблематично. Не говоря уже об её использовании.
Ну всё, пора пробовать. Тут уже действительно надо смотреть несколько реализаций идеи, внедрение и опыт использования.
> Боюсь, реализовать либу, которая сможет корректно обрабатывать погрешность погрешности погрешности, будет весьма проблематично.
А мне кажется, это будет просто что-то полиморфное, которое достаточно написать для обычной погрешности, а потом просто сказать, что она ведёт себя как всё число или сложнее.
Пользователь даже не догадается, что там внутри погрешность погре...(ну понятно) считается, если будет удобный набор конструкторов.
Ну как, нафигачил спецоперацию?
Кстати, с НГ, 1024--.
welp, мы мнимой части здесь вообще не касались
> И число Пи тоже не записать.
Вообще записать, просто числа будут наглухо ебанутые. Для таких случаев проще большой инт + scale, да.
И если sqrt(2) возведем в квадрат, получим точно 2 а не какое-то близкое к 2 говно
Поздравляю! В сотый раз изобретён ленивый функциональный язык с бесконечными списками.
Одно другому не мешает кстати.
https://www.youtube.com/watch?v=5TkIe60y2GI
Дело обстоит ещё гаже.
Записать не получится даже одно известное всем число.
Поскольку оно содержит бесконечное число рандомных знаков.
У любого компьютера кончится память. А у Вселенной время.
Потому любая запись любого числа, будет записью в первую очередь рациональной, то есть конечной дробью.
Больше ответ людям утверждающим что:
>Rational это говно
Число π точно вообще невозможно никак записать, если уж на то пошло.
Ну а так-то есть же рациональные приближения. Например, 86953 / 27678 ≈ 3,1415926. Да и вообще, можно ведь втупую так: 3,1415926 = 31415926 / 10000000.
И вообще, все эти дроби для заедушных питухов, у царей π = 3.
Именно поэтому я за демоническую типизацию. В Object можно вообще что угодно записать.
Всегда можно записать такую дробь, которая будет достаточно приближена к заданному иррациональному числу.
С любой заданной точностью. Всегда.
3.14159265 = 314159265 / 100000000
З.Ы. В общем-то это вполне нормальный алгоритм если проверка быстрая, особенно если от десятичной системы перейти к битам.
Кому и "3,14" достаточно
Да. Притом он уже 20 лет как сплошь и рядом векторный. SSE и остальные.
То есть плав. питухи не летают поодиночке. Они обычно выступают трио и квартетом.
Не зря же всякие vec3/vec4 vector3/vector4 в известных фреймворках.
Их нужно обрабатывать строго пачками. Особенно в GPU.