andrey_anonymous-2-пропущено...
Между 10 ¹ и 10 ^-38 требуется точность 40 значащих цифр. binary_double дает до 18 десятичных знаков.
И что из этого следует?

следует то, что некорректно сравнивать граничные number и binary_float, в первый влазит намного больше "информации" - значащих цифр, разница между ними будет всегда

проблема же автора скорее из отряда того, что у него клиенские double/float (а это очень распостраненная практика - преобразовывать number, который base100 разновидность BCD в типы IEEE на клиенте, ибо там других типов нет) пишутся в базу данных без специальной коррекции, в результате он наступает на проблему

http://0.30000000000000004.com/

и тут ему только в trunc()/round(), ну и в dump() для полного просвещения, сама же СУБД тут абсолютно ни при чем.

andrey_anonymousdbpatchпропущено...


следует то, что некорректно сравнивать граничные number и binary_float
:)

Фикус немного в другом.
number в oracle имеет не только десятичную мантиссу, но и, что более важно, десятичный порядок.
Числа, представленные в IEEE-754, имеют двоичный порядок.

не совсем десятичный, там base100. но с натяжкой ок, можно считать десятичным :)
http://www.orafaq.com/wiki/Number#Internal_storage


andrey_anonymousИ тут наступает смешная штука - множества представимых чисел в этих представлениях тупо не совпадают .
И чем больше порядок - тем больше расстояние между представимыми числами, и, следовательно, больше абсолютная погрешность.
В итоге, сохраняя IEEE-754 (а они бывают 32, 64, и 80 бит) во вроде бы более точный number, получаем по факту потерю точности, поскольку в number не всегда возможно представить значение double.

а не наоборот ???

andrey_anonymousПотому и ввели в 12с binary_double и binary_float, чтобы классические приложения могли хранить данные без преобразования и не "наступать".
сомнительно, ИМХО это было скорее для вопроса перфоманса.

andrey_anonymousИ в этой связи мне показался слегка странным данный тут совет избегать этих типов.\
Oracle в подавляющем большинстве случаев используется для подсчета и хранения денег, а использование там нативного
double вообще говоря преступление с т.з. бухгалтерий всяких (если у тебя нет библиотеки для "нормализации" копеек после умножений и делений).

в IBM вообще есть целая библиотека для "правильного" подсчета денег https://github.com/libdfp/libdfp
даром что ей никто не пользуется (в Java и .NET тоже есть имплементации, тоже непопулярные).

andrey_anonymous Если что - устриц ел, в смысле - приходилось как-то плотно заниматься "самопальным" преобразованиями из IEEE-754 в number и обратно.
да нет там никаких устриц, задача для начального уровня. я с ней столкнулся практически на второй неделе после того, как вообще начал работать программистом - мне принесли два отчета где цифры Итого не сходились.

странно, что неофиты до сих пор наступают на такие грабли, и никто не решил проблему системно

andrey_anonymousdbpatchне совсем десятичный, там base100. но с натяжкой ок, можно считать десятичным :)

Сам когда-то так полагал (и вроде даже писал на этом форуме).
Но там чистый BCD.

ой да ладно. base100 это и разновидность BCD, но если мы говорим про IBM варианты, то .... блин, да нет понятия чистый BCD
https://en.wikipedia.org/wiki/Binary-coded_decimal



andrey_anonymousdbpatchа не наоборот ???

Что конкретно наоборот?
Расстояние между представимыми числами, точность или невозможность представить IEEE-754 в number?
всякий IEEE-754 можно представить как number, но не наоборот.
ты говорил что как раз не всякий IEEE-754 можно в number, что не есть научно


andrey_anonymousdbpatchстранно, что неофиты до сих пор наступают на такие грабли, и никто не решил проблему системно
Так нет тут "системной проблемы", потому и не решают.
Всего лишь особенности машинных вычислений, которые по идее должны преподаваться на профильных курсах.

это не техническая системная проблема, а проблема организационная.

практически все актуальные языки программирования имеют реализацию Money/Currency или подобного, от Fixed pointer до BCD вариаций, но этим никто не пользуются, все почему-то считают деньги через double, который без специальных библиотек можно использовать лишь для инженерных/научных расчетов, но никак не для бухгалтерий

есть даже специальный вид консалтинга - приходят и начинают код "линтать", на предмет некорректного использования double (первым делом ищут операторы деления и умножения, находят практически каждый раз в новом коде)

andrey_anonymousdbpatchпропущено...

ой да ладно. base100 это и разновидность BCD

Ну покажи вариант BCD, который нельзя назвать "BASE 100" :)


Я дал ссылку на википедию, все описанные там варианты BCD - не base 100.


andrey_anonymousdbpatchвсякий IEEE-754 можно представить как number, но не наоборот.

Неправда ваша.
Пример - выше :)

какой такой пример? с power? ну так power для double выдает искаженный результат, но это не означает, что существует
какое-то представимое в double число, которое нельзя воткнуть в number без потери значимых цифр.

или еще раз - число, в студию, которое можно присвоить в double, но нельзя такое-же число получить в number без искажений :)

andrey_anonymousЧто до научности - то независимо от системы счисления множество вещественных чисел нельзя представить ни в одном из машинных представлений уже просто ввиду перечислимости представимых множеств.
Из первого попавшегося можно почитать здесь:
http://www.softelectro.ru/ieee754.html
7.4 Точность представления вещественных чисел в формате IEEE754

А в обсуждаемом случае имеем ошибку преобразования из одного представления в другое просто ввиду несовпадения множеств представимых чисел.

вот жеж блин :\

где я говорил, что бесконечное множество вещественных чисел можно представить в number?
число 0.3(3), как результат 1/3 нельзя представить ни в double, ни в number, без потери точности, это и ежу понятно,

речь же была про другое, про то, что не всякий double можно в number - я к этому утверждению (ложному) и придрался

говоря проще - я утверждал (вернее предпологаю), что все конечное множество числел double можно поместить в множество number.


вот и прошу опровергнуть оное, примерами непомещаемых чисел

andrey_anonymousНу покажи вариант BCD, который нельзя назвать "BASE 100" :)

base100 это просто конкретный алгоритм и формат представления чисел в виде последовательности байт, а не некое понятие "по основанию 100"

https://amitzil.wordpress.com/2015/03/24/how-are-numbers-saved-in-oracle/

и этот BASE1000 алгоритм подобен BCD алгоритмам IBM, которые делают то или иное кодирование/декодирование и представление в виде байт, но, строго говоря, никогда официально как BCD не назывался

andrey_anonymousdbpatchчисло 0.3(3), как результат 1/3 нельзя представить ни в double, ни в number, без потери точности, это и ежу понятно
Зато 1/3 легко представить в системе счисления по основанию 3 точно также, как 1/7 - в системе счисления по основанию 7, 1/10 - в системе счисления по основанию 10.
Так понятнее?

нет, не понятее, как это все основание по 3 относится к теме double vs number

понятное дело, что будь у нас не 10 пальцев, а, допустим, 16, то мы бы использовали систему счисления по основанию 16 (некоторые древние народы даже 60-ричные системы умудрялись использовать), но это уже совсем офтопик и не отвечает на мой вопрос: какое такое впихуемое в double нельзя впихнуть в number?

andrey_anonymousКонкретный пример для double я привел выше.

никакого такого примера я не увидел. пример с power(2,-54) не актуален - обратное преобразование в из number дает изначальный результат:




еще раз - речь не про выражения, сложения или вычитания и их результат,
речь про конкретное число, которое или может или не может быть преобразовано из double в number без искажений

такое число будет?

Сергей Арсеньевaduka,

да что вы к мантиссе то привязались:




ок, про мантиссу принято, бревна в глазу я не заметил.

хотя диапазон чисел более 1.0E126 и менее 1.0E-130 вызывает сильные сомнения практического применения, но это уже нытье лузера, ни разу не спорт ;)

долго же вы держались...

молчать и слушать, молчать и слуdbpatchчисло, в студию, которое можно присвоить в double, но нельзя такое-же число получить в number без искажений :)
таки их есть на свете, если быть строгими:
1/2=0,5 - 1 значащая цифра
1/2 ² =0,25 - 2 значащие цифры
1/2 ³ =0,125 - 3 значащие цифры
1/2 ³⁹ и далее = ... - 39+ значащих цифр, более 38 цифр в Number-е не отразишь, приехали :)

так их и в Double не отразишь :)

молчать и слушать, молчать и слуandrey_anonymousНо там чистый BCD.


В каком месте там BCD?
Там именно base100.

base 100 относится к семейству BCD. BCD форматов существует масса разновидностей, абсолютно между собой не совместимых.
у них только одно общее - они все кодируют десятичные цифры, а не двоичные, все остальное - произвольно (форматы и алгоритмы)

adukadbpatchпропущено...


так их и в Double не отразишь :)

Число 2 ¹³⁰ = 1024 ¹³ > 1000 ¹³ = 10 ³⁹ имеет более 39 значащих цифр и не может быть представлено в Number. В двоичном представлении оно имеет только 1 значащую цифру, и поэтому должно представляться в Double точно.

ок, уделал, мое почтение!

прикольно осознавать, что ты (в смысле я) сел в лужу. верификацию double vs number мы делали для финансовых данных почти лет двадцать назад (там больше 1000 триллионов величины не имеют практического смысла, если ты не в Зимбабве)

на астрономические величины проверить тогда как-то не подумалось, каюсь

adukaadukaЧисло 2 ¹³⁰ = 1024 ¹³ > 1000 ¹³ = 10 ³⁹ имеет более 39 значащих цифр и не может быть представлено в Number. В двоичном представлении оно имеет только 1 значащую цифру, и поэтому должно представляться в Double точно.

dbpatch, нет, это я ошибся. Это утверждение верно только теоретически. Решил проверить его на практике, и оказалось, что число 2 ⁵⁶ в Double сохраняется точно, а вот число 2 ⁵⁷ округляется (144115188075855870 вместо 144115188075855872). Вот такая засада с Double.

не важно, в любом случае мантисса в double может быть больше, чем в number, т.е. уже есть класс чисел, которые нельзя сконвертировать

andrey_anonymousБлин, все самое интересное пропустил.
Вот пример без "астрономии" (double):
3FBF9ADD3746F67D=

0,12345678901234609370352046653351862914860248565673828125

диаметр Млечного Пути примерно

946073047258080000000000 миллиметров


если вон то число взять как угол в радианах, да в последнюю пятерку заменить на 6, какое уголовое отконение даст это в масштабах нашей Галактики (берем катеты равными диаметру Галактики, насколько изменится гипотенуза?)

andrey_anonymousdbpatchесли вон то число взять как угол в радианах, да в последнюю пятерку заменить на 6, какое уголовое отконение даст это в масштабах нашей Галактики (берем катеты равными диаметру Галактики, насколько изменится гипотенуза?)
Угловое - 1e-56 радиана
Гипотенуза - прирастет примерно на 9,4607304725808E-23 мм, а что?

а, ну да, 9.5E-23 мм на масштабе Галактики - это нет, не астрономическая величина, конечно же нет :)