OberonCore

потому что оно на то и внутреннее, чтобы не использовать. есть стандарт IEEE 754, он специфицирует представление в памяти. этот стандарт реализует множество железяк. и есть одно конкретное железо (которое даже разработчики уже давно объявили legacy), у которого есть приватное внутреннее представление значений. что же выбрать, что: переносимый стандарт, или нестандартное представление устаревшего FPU? точно второе, что может пойти не так.

Благодарю за ответ.

да, важное: прошу прощения за тон ответов. у меня есть железный отмаз, конечно, но всё равно выходит как-то криво. если вам от этого полегчает — представьте, что у меня болит зуб, меня всё бесит, но я стараюсь сохранять вежливость. оправдание так себе, но хоть что-то. ;-)

Единственная осмысленная опрерация сравнения над вещественными - ≤.

ну, это слишком общее заявление. я, например, в Oberon/Ur размеры файлов как REAL возвращаю. вполне себе осмысленны те же операции, что и над целыми, и делают то же самое. вплоть до файла размером 2^53 или около того (пока что этот случай можно игнорировать).

Потому что это тип EXTENDED ( 80bit).
Но SSE неспособно с ним работать и поэтому сейчас модно и EXTENDED, и LONGREAL a-ka DOUBLE делать одним и тем же -- 64-битным.

это не «модно», а целесообразно. нет абсолютно никаких причин использовать 10-байтные флоаты — которые внутренняя деталь реализации x87, и наружу были выставлены ровно по одной причине: чтобы можно было полностью сохранить и восстановить состояние сопроцессора. возможность ними оперировать помимо сохранения и восстановления состояния — досадный побочный эффект, а не дополнительная возможность.

если кому-то не хватает восьмибайтового — то во-первых, этот кто-то что-то делает неправильно, а во-вторых, пусть смотрит в сторону библиотек типа GNU MPFR.

Смотрю. Смотрю в сторону PARI/GP ( там та же библиотека mpfr ( или аналог) используется), в сторону double double и на честный 128bit REAL

P.S. В защиту EXTENDED ( 80bit) : туда помещается 64битовое беззнаковое целое
P.P.S. И на 10^3 арифметику из IEEE смотрю

«падла… падла… падлавил!»

а можно нескромный вопрос: где именно не хватило даблов-то? потому что мне довольно сложно представить задачу, для которой не хватает точности даблов, и при этом надо не переходить на что-то типа интервальных вычислений, а наращивать и нарищивать мантиссу. бесконечная мантисса — это обычно не самое лучшее (или вообще неправильное) решение.

p.s.: пожалуй, за исключением попытки сделать fused mul-add, где таки нужно откуда-то достать бо́льшую промежуточную точность.