Extended = Double

[7bit]

Можно ли как-то сказать компилятору, что Extended=Double? Может есть какой-то ключ компиляции или директива есть? Что-то я не нашел ничего подходящего.

[Снег Север]

Как впихать невпихуемое - новый тур

[Сквозняк]

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

[sts]

Для процессоров Intel 80x86, тип extended занимает до 10 байтов памяти. Подробности см. в руководстве программиста Intel.

Для всех других процессоров, которые поддерживают операции с плавающей точкой, тип extended – это псевдоним для типа, который поддерживает наибольшую точность, обычно это тип double. На процессорах, которые не поддерживают операции сопроцессора (и которые имеют переключатель {$E+}), тип extended обычно отображается как тип single.

да, странно что нет, в x86_64 Extended = Double

[7bit]

В linux 64-bit extended = 10 байт. Из-за этого у меня возникли проблемы с Pascal Script если в функциях параметры или возвращаемое значение типа Extended.

[sts]

linux 64-bit extended = 10 байт

странно

[Сквозняк]

странно

У меня давно в шпаргалке копипаста есть:

Код: Выделить всё

Таблица 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


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

[sts]

У меня давно в шпаргалке копипаста есть

исхожу из этого
https://wiki.freepascal.org/IEEE_754_formats

extended 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.

viewtopic.php?f=1&t=17039
еще мельком видал что ожидали софтварную реализацию 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


Для повышения счастья винду нужно не включать и вообще запретить за пределами тюрем

[WAYFARER]

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, но все же.

[Снег Север]

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

[WAYFARER]

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

Спорить не буду, тем более это не совсем моя тема. Но в данном случае проблема мне видится не в вычислительных алгоритмах, а в том, что некоторые числа округляются в одно и то же значение, имхо. Это как раз из за размера.
Для Linux64 все работает как задумано, для систем с процессорами arm нет.

Добавлено спустя 43 минуты 56 секунд:

Для Linux64 все работает как задумано, для систем с процессорами arm нет.

То есть алгоритм заточен на точность 80 бит, соотвественно он не подходит для точности 64 бита. Соответственно нужно или менять алгоритмы или решать вопрос с точностью (но без дикой просадки производительности я это сделать не могу)

[sts]

Вроде работает extended в 64 битном линуксе:

в любом случае там софтварная эмуляция, железо то не поддерживает, видимо в линухе в ядре были данные с этим типом вот и поднапряглись

Добавлено спустя 5 минут 42 секунды:

Имеется некоторая библиотечка

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

[WAYFARER]

в любом случае там софтварная эмуляция, железо то не поддерживает, видимо в линухе в ядре были данные с этим типом вот и поднапряглись

Нет, не эмуляция. По сути это long double из C (использует х87 FPU)

[sts]

Нет, не эмуляция. По сути это long double из C (использует х87 FPU)

странно что тогда для винды не стали так делать, ведь это уже относится к компилятору а не к платформе