Extended = Double
Модератор: Модераторы
Extended = Double
Можно ли как-то сказать компилятору, что Extended=Double? Может есть какой-то ключ компиляции или директива есть? Что-то я не нашел ничего подходящего.
-
Снег Север
- долгожитель
- Сообщения: 3067
- Зарегистрирован: 27.11.2007 15:14:47
- Контактная информация:
Как впихать невпихуемое - новый тур 
Это потенциально опасная операция. Заменяй слова текстовыми редакторами, в том числе консольными, под свою личную ответственность.
да, странно что нет, в x86_64 Extended = DoubleДля процессоров Intel 80x86, тип extended занимает до 10 байтов памяти. Подробности см. в руководстве программиста Intel.
Для всех других процессоров, которые поддерживают операции с плавающей точкой, тип extended – это псевдоним для типа, который поддерживает наибольшую точность, обычно это тип double. На процессорах, которые не поддерживают операции сопроцессора (и которые имеют переключатель {$E+}), тип extended обычно отображается как тип single.
В linux 64-bit extended = 10 байт. Из-за этого у меня возникли проблемы с Pascal Script если в функциях параметры или возвращаемое значение типа Extended.
странно7bit писал(а):linux 64-bit extended = 10 байт
У меня давно в шпаргалке копипаста есть:sts писал(а):странно
Код: Выделить всё
Таблица 2.1. Целочисленные типы данных объектпаскаля
Тип Диапазон Размер,байт
Byte 0...255 1
Word 0...65535 2
LongWord 0...4294967295 4
ShortInt -128...127 1
Integer -2147483648...2147483647 4
LongInt -2147483648...2147483647 4
Smallint -32768...32767 2
Int64 -2^63...2^63 8
Cardinal 0...4294967295 4
Таблица 2.2. Вещественные типы данных
Тип Диапазон Кол-во знач-х цифр Размер, байт
Single 1.5E45...3.4E + 38 ___________________________ 7—8 __________ 4
Real 2.9E − 39...1.7E + 38 _________________________ 15—16 __________ 8
Double 5.0E − 324...1.7E + 308 _______________________ 15—16 __________ 8
Extended 3.4E − 4932...3.4E + 4932 _____________________ 19—20 __________ 10
Comp −2^63...2^63 _________________________________ 19—20 __________ 8
Currency −922337203685477.5808...922337203685477.5807 ___ 19—20 __________ 8
исхожу из этогоСквозняк писал(а):У меня давно в шпаргалке копипаста есть
https://wiki.freepascal.org/IEEE_754_formats
http://freepascal.ru/forum/viewtopic.php?f=1&t=17039extended is a 80-bit wide floating-point data type. There are FPUs that internally use 80 bits for increased precision. FPC allows to use this gain in precision.
Light bulb Note: If some platform does not support the extended data type, it will be mapped to largest available floating-point number data available, i. e. usually double.
еще мельком видал что ожидали софтварную реализацию extended, но сходу не нашел ссылку
Вроде работает extended в 64 битном линуксе:
А в вайне и десятке:
Для повышения счастья винду нужно не включать и вообще запретить за пределами тюрем 
Код: Выделить всё
var
q1: double;
w1:extended;
begin
q1:=pi;
w1:=pi;
writeln(q1);
writeln(w1);
end.Код: Выделить всё
3.1415926535897931E+000
3.14159265358979323851E+0000
Код: Выделить всё
3.1415926535897931E+000
3.1415926535897931E+000
x86 linux/windows = 10 байт
x86-64 Linux/BSD = 16 байт (10 - число +6 нулей на выравнивание)
Windows x64 = double
Все arm/arm64 = double.
И вопрос, навеянный топиком. Имеется некоторая библиотечка (анализ данных и прогнозирование), которая прекрасно работает в Linux64. Она была портирована на AArch64, и, в принципе, она работает, но результаты несколько отличаются. Незначительно, но тем не менее оказывают влияние на сортировку выходных данных, когда цифры "почти одинаковые". Изначально я пытался решить проблему с помощью своего типа, который хранит число как сумму двух Double с арифметикой на error-free примитивах. Результат - выиграл в точности, но очень сильно проиграл в производительности(время на обработку данных Linux64 Extended примерно 20 минут, arm64 Double примерно 10 минут arm64 со своим типом больше часа). И на этом я просто забил))).
Может есть еще у кого то какие то идеи как сохранить точность и производительность? Умом я, конечно, понимаю, что на самом деле точность 80 бит избыточна и самым оптимальным вариантом будет использование Double, но все же.
x86-64 Linux/BSD = 16 байт (10 - число +6 нулей на выравнивание)
Windows x64 = double
Все arm/arm64 = double.
И вопрос, навеянный топиком. Имеется некоторая библиотечка (анализ данных и прогнозирование), которая прекрасно работает в Linux64. Она была портирована на AArch64, и, в принципе, она работает, но результаты несколько отличаются. Незначительно, но тем не менее оказывают влияние на сортировку выходных данных, когда цифры "почти одинаковые". Изначально я пытался решить проблему с помощью своего типа, который хранит число как сумму двух Double с арифметикой на error-free примитивах. Результат - выиграл в точности, но очень сильно проиграл в производительности(время на обработку данных Linux64 Extended примерно 20 минут, arm64 Double примерно 10 минут arm64 со своим типом больше часа). И на этом я просто забил))).
Может есть еще у кого то какие то идеи как сохранить точность и производительность? Умом я, конечно, понимаю, что на самом деле точность 80 бит избыточна и самым оптимальным вариантом будет использование Double, но все же.
-
Снег Север
- долгожитель
- Сообщения: 3067
- Зарегистрирован: 27.11.2007 15:14:47
- Контактная информация:
По-моему проблема в том, что подавляющее число программистов выучила, в лучшем случае, школьную арифметику и не имеет представления о вычислительной неустойчивости алгоритмов и накоплении ошибок. И главное - как их избегать.
Отсюда все проблемы с длиной чисел и разными результатами.
Отсюда все проблемы с длиной чисел и разными результатами.
Спорить не буду, тем более это не совсем моя тема. Но в данном случае проблема мне видится не в вычислительных алгоритмах, а в том, что некоторые числа округляются в одно и то же значение, имхо. Это как раз из за размера.Снег Север писал(а):По-моему проблема в том, что подавляющее число программистов выучила, в лучшем случае, школьную арифметику и не имеет представления о вычислительной неустойчивости алгоритмов и накоплении ошибок. И главное - как их избегать.
Для Linux64 все работает как задумано, для систем с процессорами arm нет.
Добавлено спустя 43 минуты 56 секунд:
То есть алгоритм заточен на точность 80 бит, соотвественно он не подходит для точности 64 бита. Соответственно нужно или менять алгоритмы или решать вопрос с точностью (но без дикой просадки производительности я это сделать не могу)WAYFARER писал(а):Для Linux64 все работает как задумано, для систем с процессорами arm нет.
в любом случае там софтварная эмуляция, железо то не поддерживает, видимо в линухе в ядре были данные с этим типом вот и поднапряглисьСквозняк писал(а):Вроде работает extended в 64 битном линуксе:
Добавлено спустя 5 минут 42 секунды:
слыхал что для вычислений, типа mathcad, используют математические спец библиотеки, на железные типы надежды нет.WAYFARER писал(а):Имеется некоторая библиотечка
Нет, не эмуляция. По сути это long double из C (использует х87 FPU)sts писал(а):в любом случае там софтварная эмуляция, железо то не поддерживает, видимо в линухе в ядре были данные с этим типом вот и поднапряглись
странно что тогда для винды не стали так делать, ведь это уже относится к компилятору а не к платформеWAYFARER писал(а):Нет, не эмуляция. По сути это long double из C (использует х87 FPU)