Предположим, что и x, и y — очень маленькие числа, но я знаю, что истинное значение x / y разумно.
Как лучше всего вычислить x/y? В частности, вместо этого я делал np.exp(np.log(x) - np.log(y), но я не уверен, что это вообще что-то изменит?
В арифметике IEEE-754 в режиме округления до ближайшего результатом деления является представимое значение, ближайшее к точному математическому значению. Поскольку вы говорите, что математическое значение x/y разумно, оно находится в нормальном диапазоне представимых значений (не ниже его, в субнормальном диапазоне, где страдает точность, и не выше него, где результаты округляются до бесконечности). В нормальном диапазоне результаты элементарных операций будут точными в пределах нормальной точности формата.
Однако, поскольку x и y являются «очень маленькими числами», мы можем быть обеспокоены тем, что они субнормальны и имеют потерю точности уже в них, прежде чем будет выполнено деление. В базовом 64-битном двоичном формате IEEE-754 числа меньше 2-1022 (около 2,22507•10-308) являются субнормальными. Если x и y меньше этого, то они уже потеряли точность, и ни один метод не может получить из них правильное частное, кроме как по чистой случайности. Логарифмирование для вычисления частного не поможет.
Если машина, на которой вы работаете, не использует IEEE-754, вполне вероятно, что прямое вычисление x/y даст лучший результат, чем np.exp(np.log(x)-np.log(y)). Первая представляет собой единственную операцию, вычисляющую базовую функцию аппаратного обеспечения, которая, вероятно, была разумно спроектирована. Последний представляет собой несколько операций, вычисляющих сложные функции в программном обеспечении, которые трудно сделать точными, используя обычные аппаратные операции.
Существует изрядное беспокойство и недоверие к операциям с плавающей запятой. Недостаток знаний, кажется, приводит к тому, что люди боятся их. Но здесь следует понимать, что элементарные операции с плавающей запятой очень хорошо определены и точны в нормальных пределах. Реальные проблемы с вычислениями с плавающей запятой возникают из-за накопления ошибок округления в последовательностях операций, из-за присущей математике, которая усугубляет ошибки, и из-за неправильных ожиданий результатов. Это означает, что нет необходимости беспокоиться о точности одного деления. Скорее, следует помнить об общем использовании чисел с плавающей запятой. (На ваш вопрос можно было бы лучше ответить, если бы он представил больше контекста, освещающего, почему это разделение важно, как x и y были получены из предыдущих данных и какова общая цель.)
Нередким отклонением от IEEE-754 является обнуление ненормальных значений. Если у вас есть некоторые x и некоторые y, которые являются субнормальными, некоторые реализации могут сбросить их до нуля перед выполнением над ними операций. Однако это чаще встречается в коде SIMD, чем в обычном скалярном программировании. И, если бы это произошло, это в любом случае помешало бы вам оценить np.log(x) и np.log(y), так как субнормальные значения также были бы сброшены до нуля в них. Так что мы, вероятно, можем отбросить эту возможность.
x/y с плавающей запятой будет иметь какую-то ошибку, отличную от pow(10, 8), то это потому, что при их делении уже есть ошибки в x и y. Если в x и y уже есть ошибки, то логарифмирование, вычитание и возведение в степень эти ошибки не удалят.
- person Eric Postpischil; 10.01.2018
pow(10, -308 - -316) точнее, чем 1.0e-308/1.0e-316. Таким образом, если вы знаете логарифмы с самого начала (здесь log10 — это -308 и -316), вы можете сохранять точность, как только узнаете, что можете перейти к денормалям.
- person Rudy Velthuis; 10.01.2018
x и y в моем случае составляют примерно 10E-10; Я не знал, что субнормальный предел снижается до 10E-308. И да, мне как раз было интересно, действительно ли взятие журналов еще больше испортит ситуацию, как вы указали.
- person p-value; 10.01.2018
Деление, как и другие операции, указанные в IEEE-754, вычисляется с бесконечной точностью, а затем (с обычными правилами округления) округляется до ближайшего представимого числа с плавающей запятой. Результат вычисления x/y почти наверняка будет намного точнее, чем результат вычисления np.exp(np.log(x) - np.log(y) (и гарантированно не будет менее точен).
1/3, на самом деле невозможно иметь бесконечную последовательность 10101010101... перед округлением, но процессор должен найти способ вычисления окончательного значения, как если бы он это сделал. Все ошибки должны быть связаны с округлением, а не с вычислениями. FWIW, словосочетание бесконечной точности взято непосредственно из стандарта IEEE-754.
- person Sneftel; 10.01.2018
xиyслишком малы для представления в IEEE с плавающей запятой? - person Mark Ransom schedule 10.01.2018x/yне получится, и делалnp.exp(np.log(x) - np.log(y), но потом мне стало интересно, имеет ли это какое-то значение. Немного подредактирую вопрос. - person p-value schedule 10.01.2018logиexpдало бы лучший результат, чем прямое деление. Хотя известно, что иногда мне не хватало воображения. - person Mark Ransom schedule 10.01.2018