LINUX.ORG.RU
ФорумTalks

Объясните, что же не так с представлением чисел в памяти

 


0

1

Привет. Я читал что из-за сложностей преобразования из десятичной системы в двоичную возникают погрешности и другие странности, вроде отрицательного нуля или х*2=inf, а так-же, что размер числа ограничен размером машинного слова.

И может быть это всё нормально, но мне это кажется странным.

Я не вижу преград для разбиения числа на части и хранения его в нескольких словах, чтобы потом считать в несколько заходов. Таким образом, размер числа будет ограничен только размером виртуальной памяти.

А раз так, то float можно хранить как число с фиксированной точкой (правда, я читал что так погрешность даже выше, но наверное это опечатка), причём положение точки будет храниться отдельно и для операции над двумя числами они будут преобразовываться в дроби с одинаковой длиной дробной части.

Я понимаю, это ресурсозатратно, но ведь это же необходимая жертва?

Ответ на: комментарий от cvs-255

Везде где я работал, на плюсах почти вся стандартная библиотека была своя. Написанная спецом под проект. Это норма.

Deleted
()
Ответ на: комментарий от cvs-255

Мельком да. А как их обходить — нет.

Deleted
()
Ответ на: комментарий от Deleted

почти вся стандартная библиотека была своя. Написанная спецом под проект. Это норма.

Это норма среди старперов, не слышавших про STL, и пишущих свои велосипеды, которые к тому же не факт, что быстрее.

cvs-255 ★★★★★
()
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от cvs-255

Дане. Просто убирают ненужные проверки и пишут аккуратно, чтобы без этих проверок работало. Ты же знаешь, что generic имплементация проверяет все на свете и вообще тормоз. В инженерной софтине, которая и без того жрет 16 гигов памяти, такое какраз норма.

Deleted
()
Ответ на: комментарий от Deleted

и пишут аккуратно, чтобы без этих проверок работало

Вот это гораздо более чревато багами, нежели double

cvs-255 ★★★★★
()
Ответ на: комментарий от redgremlin

Facepalm. Погрешность — она не от процессора зависит (ну ладно, fdiv bug никто не отменял, но shit happens, это чисто инженерный косяк) и страны его производства, а от неумолимых законов математики.

Я может неправильно выразился:

2.0 - 1.1 = 0.8999999999999999

Вот этого нет, типа все числа получаюся ровные.

xwicked ★★☆
()
Ответ на: комментарий от xwicked

Это возможно только ценой сильного проседани скорости за счет использования десятичной записи чисел в памяти

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

Это возможно только ценой сильного проседани скорости за счет использования десятичной записи чисел в памяти

ВОт ты сам инженер? Ты понимаешь что такое мантиссы и как всё это организовано? Может нас налюбливают, а мы и не можем проверить?... Верим ББ на слово...

xwicked ★★☆
()
Ответ на: комментарий от RazrFalcon

Но зачем?

Чтобы у тебя по звонку слюни текли на новый проц более производительный, чем старый тормозной, как вариант.

xwicked ★★☆
()
Ответ на: комментарий от xwicked

Разве текущая реализация не самая быстрая? В любом случае выбора нет: или страдать или тормоза. Проц-то не пропатчишь.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Разве текущая реализация не самая быстрая?

Если верить инженерам МЦСТ то даже эта реализация,которая может быть не самой быстрой, так она ещё и криво реализована прямо в интеловском проце с тонной шлака, возможно даже обфусцированно...

xwicked ★★☆
()
Ответ на: комментарий от xwicked

когда изобретали числа с плавающей точкой, компутеры ещё не продавались за деньги, а военным нужно было считать свои вундервафли чем быстрее, тем лучше исходя из технологических возможностей, так что всё пучком, твоя теория заговора несостоятельна

Harald ★★★★★
()
Ответ на: комментарий от Harald

...так что всё пучком...

Подтвердил буквами... Теория осталась не доказана и не опровергнута. У каждого свои розовые очки, чо... :D

xwicked ★★☆
()
Ответ на: комментарий от xwicked

хотя вот ща вспомнил, что ЭНИАК был десятичным, а не двоичным, так что можешь врубать свою паранойю на полную мощность :)

Harald ★★★★★
()
Ответ на: комментарий от cvs-255

этого мало, еще надо как минимум точку заякорить

t184256 ★★★★★
()
Ответ на: комментарий от xwicked

Я знаю, как организована double в памяти. И знаю, что аппаратного вычисления decimal вещественных чисел нет на x86 и arm, и почти везде за исключением специализированных систем типа тех, что в калькуляторах. А значит придется программно все вычислять

cvs-255 ★★★★★
()
Ответ на: комментарий от Harald

твоя теория заговора несостоятельна
Harald ★★★★★ (12.06.2018 19:02:09)Юрист-фанатик1

Если что, я цитировал наших инженеров МЦСТ, включая главного конструктора. Ты фанатично веришь в любовь ББ ко всем людям? Похвально.

xwicked ★★☆
()
Последнее исправление: xwicked (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Очередной свидетель масонского заговора?
RazrFalcon ★★★★ (12.06.2018 19:49:28)Юрист-фанатик2

Я привожу доводы других более авторитетных «сектантов». Вам платят за безоговорочную веру в ББ, признавайтесь? Откуда вы такие берётесь?

xwicked ★★☆
()

Что за десятичное представление? Может быть десятично-двоичное, когда 4 бита = одна десятичная цифра?

russian-turist-2019
() автор топика
Ответ на: комментарий от RazrFalcon

Фанатик - ещё ладно, но при чём тут юрист?

Я пока сомневаюсь ты действительно фанатик и всё на веру воспринимаешь или всё таки юрист(е***й, представитель ББ).

xwicked ★★☆
()
Ответ на: комментарий от Deleted

ps: люди из нулевых думают, что создание объекта в java дорого. Это уже давно не так.

Как только ты попробуешь сделать сервис на java что отвечает за несколько сотен микросекунд ты сразу поймешь что таки да, дорого.

Но дорого не сразу, а когда GC пришел сказать привет.

catap ★★★★★
()
Ответ на: комментарий от Deleted

В 100% случаев в java надо создавать BigDecimal, если не хочешь выстрелить себе в ногу.

когда ты делаешь финансовый софт или софт где важна предсказуемость округления ценой производительности — да.

Я не так давно писал сравнение самопальных BigDecimal, благо там более менее фиксирвоанная длина, так что было все не так что бы больно.

catap ★★★★★
()
Ответ на: комментарий от Deleted

Берем такой вот бенчмарк в руки:

public class DoublesBenchmark {
    @Benchmark
    public double primitiveDouble() {
        return 1d + 1d;
    }

    @Benchmark
    public Double Double() {
        return Double.valueOf(1d) + Double.valueOf(1d);
    }

    @Benchmark
    public BigDecimal BigDecimal() {
        return new BigDecimal(1d).add(new BigDecimal(1d));
    }
}

И имеем:

Benchmark                         Mode  Cnt  Score    Error  Units
DoublesBenchmark.BigDecimal       avgt    5  0.106 ±  0.001  us/op
DoublesBenchmark.Double           avgt    5  0.006 ±  0.001  us/op
DoublesBenchmark.primitiveDouble  avgt    5  0.003 ±  0.001  us/op

BigDecimal дороже на два порядка, Double дороже double в два раза.

catap ★★★★★
()
Ответ на: комментарий от Deleted

java тормозит и жрет память, забыл?

вы просто не умеете ее готовить!

catap ★★★★★
()

разбиения числа на части и хранения его в нескольких словах

google://varint

beastie ★★★★★
()
Ответ на: комментарий от Deleted

И не смотря на это, за double могут выгнать с работы.

И правильно сделают.

Не гоже работать с какими-то клоунами, право. Разборчивее надо быть, разборчивее!

catap ★★★★★
()
Ответ на: комментарий от catap

И отдельно методичка по правилам округления.

Таки надо в массы! Мну на этих округлениях уже не превую шапку съел.

beastie ★★★★★
()
Ответ на: комментарий от beastie

fixed point был придуман специально для денег.

А те кто делает деньги на BigDecimal потом огребают на исках с не правильным округлением ;)

catap ★★★★★
()
Ответ на: комментарий от catap

Меня больше удивляет, чему учат современных CS на всяких пуддинг-абирурах. Мну, без степени, приодится объяснять вчёным, что порядок округления имеет играть роль и что ошибка неизбегама. Про float == float вообще молчу, об этом в университетах на учат.

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от beastie

Звучит как feedback на типичного data scientist :)

catap ★★★★★
()
Ответ на: комментарий от Harald

когда изобретали числа с плавающей точкой, компутеры ещё не продавались за деньги, а военным нужно было считать свои вундервафли чем быстрее, тем лучше исходя из технологических возможностей

В 60-е и 70-е годы не было единого стандарта представления чисел с плавающей запятой, способов округления, арифметических операций. В результате программы были крайне не портабельны. Но еще большей проблемой было то, что у разных компьютеров были свои «странности» и их нужно было знать и учитывать в программе. Например, разница двух не равных чисел возвращала ноль. В результате выражения «X=Y» и «X-Y=0» вступали в противоречие. Умельцы обходили эту проблему очень хитрыми трюками, например, делали присваивание «X=(X-X)+X» перед операциями умножения и деления, чтобы избежать проблем.

Это что ещё за «странности» реализации алгоритмов? Кроме не стандартизации была кривая реализация имеющихся алгоритмов, о чём инженеры МЦСТ и говорят, что там тонны шлака в ПРОЦЕССОРАХ, а не в компиляторах.
Это уже намекает на то, что МОЖНО сделать нормальный алгоритм работы с числами с плавающей запятой.

xwicked ★★☆
()
Последнее исправление: xwicked (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.