Comments 28
Так вот, вещественные числа соответствующие стандарту IEEE754 являются костылем.
а примеры некостылей можно?
Строго говоря, из того, что что-то является костылём, не следует существование некостылей и автор не утверждал обратного
Конечно, критикуешь что-то — предложи лучшее решение.
Но, боюсь, в настоящее время, это единственная математическая модель для работы с вещественными числами с использованием современной вычислительной техники доступная широкому кругу разработчиков.
Некоторые интересные идеи можно почитать в данной работе.
Но, боюсь, в настоящее время, это единственная математическая модель для работы с вещественными числами с использованием современной вычислительной техники доступная широкому кругу разработчиков.
Некоторые интересные идеи можно почитать в данной работе.
Причем стандартом языка сказано, что “the type long double provides at least as much precision as double”.
На микроконтроллерах ATmega328 и не только все еще интереснее.
Там по количеству разрядов double совпадает с float.
Если мне не изменяет память, в атмегах нет регистров для работы с вещественными числами.
Там по количеству разрядов double совпадает с float.Это зависит от компилятора.
Если мне не изменяет память, в атмегах нет регистров для работы с вещественными числами.
Вроде нет, но я не об аппаратной части, а о типах с плавающей точкой.
Ведь в том же x86 факт реализации или не реализации long double в разных компиляторах (аппаратная часть одна, а реализация отличается) тоже никак не зависит от аппаратной части
Это зависит от компилятора.
Не подскажете ли компилятор с нормальным double для ATmega.
А то точность вычислений с плавающей точкой никакая (мало разрядов после точки).
Приходится извращаться вместо простых арифметических операций с double.
Не подскажете ли компилятор с нормальным double для ATmega.Похоже на то, что IAR поддерживает:
Floating-point values are represented by 32- and 64-bit numbers in standard IEEE 754 format. If you use the compiler option --64bit_doubles, you can make the compiler use 64-bit doubles. The data type float is always represented using 32 bits.Правда он платный, с триалом на месяц или ограничением по объему бинарника.
Конечно же, можно было решить проблему переполнения, задействовав программный метод обработки больших вещественных чисел, но тогда падение производительности было бы значительным
Немного странно, что вы не рассматривали способ «провести рефакторинг кода так, чтобы код не использовал значения больше DBL_MAX». Что у вас за задача такая, в которой нужны числа с плавающей точкой от 64 до 80 бит и нельзя обойтись значениями до DBL_MAX? Какая-то библиотека отдаёт данные в расширенном формате? Или в коде захардкожена обработка именно расширенных значений, причём так, что это не изменить, не порушив всю архитектуру?
Или речь идёт всё ещё про проблему с факториалом из начала статьи, в котором double переполнялся, и для борьбы с этим вы применяете long double? А long double не переполняется? :) Я не видел вашу задачу, но даже задача «безопасно вычислить большой факториал» — проблема довольно нетривиальная. Подобную «грязную работу» лучше скидывать на специализированную библиотеку, например на gmplib.
Сейчас занимаюсь оптимизацией некоего кода, в котором много плавающей точки. Невооружённым взглядом видно, что сумрачные гении, которые его писали, навтыкали в куче мест double вместо float по принципу «а вдруг float-а не хватит, давайте double объявим — это же просто одно слово в С-коде поменять». Т.е. никто не занимался анализом алгоритма на предмет требуемой точности промежуточных значений. Причём речь не идёт о каких-то сложных действиях, сам алгоритм достаточно прост.
Подозреваю, что такой подход довольно распространён, и в этой статье ноги проблемы тоже могут расти из подобного места.
Подозреваю, что такой подход довольно распространён, и в этой статье ноги проблемы тоже могут расти из подобного места.
Очень много кода пишется с использованием «поверхностных оценок исходя из опыта», а в теорию погрешностей и т.п. начинают вникать только тогда когда появляются проблемы с несовпадением результатов и «ожиданий».
Есть очень жизненный пример из «другой области» мост в Волгограде.
Но если для строителей это обычно всё-же проблемы с безопасностью построенного объекта, то для программистов/разработчиков, это просто небольшая вероятность «небольших багов» в продукте, и в итоге из-за разного уровня потерь в «случае чего» таким серьёзным анализом алгоритмов мало кто занимается «сразу».
Есть очень жизненный пример из «другой области» мост в Волгограде.
Но если для строителей это обычно всё-же проблемы с безопасностью построенного объекта, то для программистов/разработчиков, это просто небольшая вероятность «небольших багов» в продукте, и в итоге из-за разного уровня потерь в «случае чего» таким серьёзным анализом алгоритмов мало кто занимается «сразу».
Да, задача была такая — обработка больших объемов астрометрических наблюдений. Обрабатывались матрицы с приблизительным размером 8000х72000 элементов расширенной точности
Вообще-то ARMv7 поддерживает float point. Правда, опционально, в качестве расширения. Так что наличие VFP зависит только от производителя SoC.
Последующие версии данного стандарта выходили в 1997 и 2008 годах
От того же комитетета, который в своё время не нашел внутри себя консенсуса, по причине чего Intel по-сути «стукнули кулаком по столу» и сказали: «Не можете никак определиться — так пусть будет по-нашему, ибо бизнес не ждет пока вы там в своей „академической среде“ договоритесь?
Интересно было бы почитать какие варианты предлагались, какие были у них плюсы или минусы по сравнению с тем что в итоге реализовал Intel.
Вот хороший рассказ собственно от «отца» стандарта.
Видно, например, что спор шёл между K-C-S и уже известным VAX форматом.
«Плавный underflow» стоил каких-то know-how по реализации (хотя, судя по тому, что до сих пор тормозят на ненормализованных — они сами не очень-то их внедрили).
Видно, например, что спор шёл между K-C-S и уже известным VAX форматом.
«Плавный underflow» стоил каких-то know-how по реализации (хотя, судя по тому, что до сих пор тормозят на ненормализованных — они сами не очень-то их внедрили).
например, каждый 512 битный регистр способен работать либо с четырьмя 64-битными числами двойной точности, либо с восемью 32-битными числами одинарной точности.
У вас всё хорошо с математикой?
В компиляторе от Borland размер long double всегда был 80 бит (10 байт).
docwiki.embarcadero.com/RADStudio/Tokyo/en/Constants_And_Internal_Representation
docwiki.embarcadero.com/RADStudio/Tokyo/en/Constants_And_Internal_Representation
А что в этой статье полезного? Вы просто описали историю вещественных типов данных
Неправда. Все основные целочисленные операции поддерживаются с SSE2/AVX2/AVX-512BW соответственно
MMX, SSE, SSE2, SSE3, SSSE3, SSE4, SSE5, AVX, AVX2, AVX-512 и др.… Эти расширения предоставляют возможность для работы только с вещественными числами одинарной и двойной точности
Неправда. Все основные целочисленные операции поддерживаются с SSE2/AVX2/AVX-512BW соответственно
Более того, в MMX только целые и есть. А SSE5 вообще что за зверь )
Разработка АМД, вот
Могу ошибаться, просто в статье был упомянут C++ Builder, который игнорирует 80 бит… У Delphi в до-XE'шную эпоху компилятор всегда использовал «сопроцессор» и соответственно был тип Extended (80 bit). Builder вроде тоже и аналогом у него являлся/является long double. Сейчас в XE используется только SSE, хотя надо бы проверить, что сгенерит компилятор если поставить тип extended. Аж интересно стало.
> если в процессе работы происходил выход за пределы короткого формата, то возвращался NaN (not a number — не число)
Всё-таки INF, а не NaN.
> среди игнорирующих 80-ти битный расширенный формат представления данных много известных и широко применяемых компиляторов, вот неполный список: Microsoft Visual C++
16-битные версии ещё знали long double как extended.
Потом это удалили, не совсем понятно, почему (я понимаю, переход к 64 битам — SSE везде — но не к 32).
> В интернете есть интересная статья[3], в которой, весьма эмоционально, описываются проблемы и недостатки существующего стандарта.
Именно, что «эмоционально». По сути же в этой статье ничего нет. Проблемам подсчётов на компьютере со всеми этими округлениями, потерями точности и т.п. учат даже студентов профильных специальностей, в достаточной детализации; а книги типа FMM, TAoCP, Hacker's delight в интернете на каждом углу; автор явно не освоил даже азы этой темы. В то же время при проектировании IEEE754 эти проблемы рассмотрены и отражены значительно лучше, чем в предыдущих реализациях.
> Так вот, вещественные числа соответствующие стандарту IEEE754 являются костылем.
Любые вещественные числа в компьютере являются костылём. Это не мешает их использовать и получать из этого практическую пользу.
> Потому что не бывает отрицательного нуля
Не бывает и положительного, и что?
> преобразование в десятичный формат и обратно неоднозначное
В каком смысле? Вот авторы Python считают, что однозначное — а именно, repr() на float-тип даёт самое короткое из десятичных представлений, которое обратно переводится в то же двоичное. Я как-то им верю больше :)
Резюме: статья ни о чём. Смесь «а мы смогли применить extended, хотя злой Гейтс нам мешал» с конспирологией. Конспирологии — больше.
Всё-таки INF, а не NaN.
> среди игнорирующих 80-ти битный расширенный формат представления данных много известных и широко применяемых компиляторов, вот неполный список: Microsoft Visual C++
16-битные версии ещё знали long double как extended.
Потом это удалили, не совсем понятно, почему (я понимаю, переход к 64 битам — SSE везде — но не к 32).
> В интернете есть интересная статья[3], в которой, весьма эмоционально, описываются проблемы и недостатки существующего стандарта.
Именно, что «эмоционально». По сути же в этой статье ничего нет. Проблемам подсчётов на компьютере со всеми этими округлениями, потерями точности и т.п. учат даже студентов профильных специальностей, в достаточной детализации; а книги типа FMM, TAoCP, Hacker's delight в интернете на каждом углу; автор явно не освоил даже азы этой темы. В то же время при проектировании IEEE754 эти проблемы рассмотрены и отражены значительно лучше, чем в предыдущих реализациях.
> Так вот, вещественные числа соответствующие стандарту IEEE754 являются костылем.
Любые вещественные числа в компьютере являются костылём. Это не мешает их использовать и получать из этого практическую пользу.
> Потому что не бывает отрицательного нуля
Не бывает и положительного, и что?
> преобразование в десятичный формат и обратно неоднозначное
В каком смысле? Вот авторы Python считают, что однозначное — а именно, repr() на float-тип даёт самое короткое из десятичных представлений, которое обратно переводится в то же двоичное. Я как-то им верю больше :)
Резюме: статья ни о чём. Смесь «а мы смогли применить extended, хотя злой Гейтс нам мешал» с конспирологией. Конспирологии — больше.
Sign up to leave a comment.
Особенности использования вещественных регистров x86 архитектуры