Ответ на »сообщение 2297« (AVC)
___________________________

Впрочем, сам тип LONGREAL остается зарезервированным, так что не исключено, что тип, подобный long double, может появиться и в ББ.

Нет. Зарезервирован он для гораздо более важной вещи -- 128-битных вещественных.
После того как ББ немножко укрепится на линуксе, об этом нужно будет начинать думать, т.к. сразу придет народ с серьезными вычислительными приложениями, а там это нужно.

Ответ на »сообщение 2301« (Антон Григорьев)
___________________________

Ответ на »сообщение 2296« (PGR)
___________________________

И еще вопрос -- почему в BlackBox нет типа LONGREAL ?

Что-то краем уха слышал, что стандарт IEEE вообще не рекомендует использование 10-байтного вещественного из-за накопления ошибок. Якобы 10-байтный формат должен использоваться только для промежуточного внутреннего представления вещественных чисел, но наружу нигде вылезать не должен.

Из практики слышал об одном примере. Юрий Зотов рассказывал, что в какой-то вычислительной задаче удалось существенно повысить точность, заменив Extended (так в Delphi называется long double) на Double - ошибки перестали накапливаться.

Сомневаюсь, что применение самого 10-байтного формата сильно усугубит накопление ошибки. Но она точно будет накапливаться при постоянном преобразовании double <-> long double.

В стандарт IEEE 754 10-байтовый формат не входит, однако процессоры (x86, про другие точно не скажу) с ним работают. Стандарт определяет 32- и 64-разрядные вещественные форматы. Почти все современные процессоры умеют с ними работать, причем должны это делать одинаково. Поэтому в BlackBox и нет LONGDOUBLE.

А вообще, пора привыкнуть, что машинная вещественная арифметика неточна по определению. :)

Ответ на »сообщение 2303« (Lisp Hobbyist)
___________________________

Ответ на »сообщение 2301« (Антон Григорьев)
___________________________

А для борьбы с вычислительной погрешностью многие рекомендуют такой подход:

http://www.xsc.de/

О чем я уже упоминал N постов назад. Но это дело требует и соответствующего подхода к вычислительным алгоритмам.

Ответ на »сообщение 2301« (Антон Григорьев)
___________________________

Что-то краем уха слышал, что стандарт IEEE вообще не рекомендует использование 10-байтного вещественного из-за накопления ошибок. Якобы 10-байтный формат должен использоваться только для промежуточного внутреннего представления вещественных чисел, но наружу нигде вылезать не должен.


http://http.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

А для борьбы с вычислительной погрешностью многие рекомендуют такой подход:

http://www.xsc.de/

Ответ на »сообщение 2300« (Сергей Губанов)
___________________________
Ответ на »сообщение 2289« (Владимир Лось)
Ну тогда (хотя бы "на пальцах") раскройте мне мне этот "физический" термин (применительно к Миру, а не к одной из его моделей)...
Не знаю получится ли "на пальцах"...
Состояние системы есть суперпозиция собственных векторов гамильтониана этой системы. Нет оснований полагать, что это будет не справедливым если в качестве системы взять весь Мир. Разьве только, при описании всего Мира, вероятно, всё же надо использовать матрицу плотности состояний вместо самих собственных векторов (не все состояния всего Мира мы можем наблюдать - по ним надо будет просуммировать).
Вы говорите о "системе". В рамках какой МОДЕЛИ? В каких границах? Ведь говоря "система", вы подразумеваете "ЭТУ систему" (её модель). Но говоря про "ЭТУ систему" вы подразумеваете существование "ДРУГИХ" (природа самой системы, способ моделирования). Ведь, даже говоря о гамильтониане, вы упоминаете для какой системы (модели вы его получаете) - для тел (частиц) в потенциальных (какой природы?) полях он будет один, а, например, для биллиарда - другой... В каком "разрезе" (совокупности "точек зрения") вы рассматриватете Мир в этом случае?

Ответ на »сообщение 2296« (PGR)
___________________________

И еще вопрос -- почему в BlackBox нет типа LONGREAL ?

Его не только в BlackBox'е нет. В VC++ long double тоже начиная с какой-то версии (кажется, с 6-ой) исключили. Точнее, оставили, но сделали 8-байтным - long double = double. Связано это с какими-то неизвестными мне особенностями вычислений с 10-байтными вещественными. Что-то краем уха слышал, что стандарт IEEE вообще не рекомендует использование 10-байтного вещественного из-за накопления ошибок. Якобы 10-байтный формат должен использоваться только для промежуточного внутреннего представления вещественных чисел, но наружу нигде вылезать не должен.

Из практики слышал об одном примере. Юрий Зотов рассказывал, что в какой-то вычислительной задаче удалось существенно повысить точность, заменив Extended (так в Delphi называется long double) на Double - ошибки перестали накапливаться.

Ответ на »сообщение 2289« (Владимир Лось)

Ну тогда (хотя бы "на пальцах") раскройте мне мне этот "физический" термин (применительно к Миру, а не к одной из его моделей)...

Не знаю получится ли "на пальцах"...

Состояние системы есть суперпозиция собственных векторов гамильтониана этой системы. Нет оснований полагать, что это будет не справедливым если в качестве системы взять весь Мир. Разьве только, при описании всего Мира, вероятно, всё же надо использовать матрицу плотности состояний вместо самих собственных векторов (не все состояния всего Мира мы можем наблюдать - по ним надо будет просуммировать).

Ответ на »сообщение 2298« (AVC)
___________________________

Прошу прощения, везде вместо 1.0 и 1.0L следует читать 0.1 и 0.1L.
Просто я что-то засиделся за компом... :)

Ответ на »сообщение 2297« (AVC)
___________________________

В принципе, можно догадаться, откуда у проблемы "ноги растут".
Дело в том, что dt > 1.0L в силу округления.
1.0L выглядит так (дамп):
3f fb cc cc cc cc cc cc cc cd
в то время как округленный dt (после его приведения к типу long double) так:
3f fb cc cc cc cc cc cc d0 00.
Выходит, что 1.0 > 1.0L :) , а 10 / dt соответственно меньше, чем 10 / 0.1 (похоже, ББ формирует константу сразу как long double).
Похоже, проблема действительно в "излишней точности" (в отдельно взятом месте), как Вы раньше сформулировали.

Ответ на »сообщение 2296« (PGR)
___________________________
Был неправ. Вычисление с long double дает правильный ответ -- 100.
Просто константу 0.1 нужно задавать в виде 0.1L (типа long double), а не просто 0.1 (тип double).


#include <stdio.h>
#include <math.h>

int main()
{
  long double lx = 0.1L;
  printf("%d\n", (int) floorl(10.0 / lx));
  return 0;
}


Так, что проблема в блэкбоксовской ENTIER.

И еще вопрос -- почему в BlackBox нет типа LONGREAL ?


Действительно здесь какая-то "закавыка".
Но дело, возможно, не в функции ENTIER как таковой.
Например,

ASSERT(10 / 0.1 = 10 / dt)

приводит к генерации трапа, в то время как

VAR dt, t1, t2: REAL;
...
dt := 0.1;
t1 := 10 / 0.1;
t2 := 10 / dt;
ASSERT(t1 = t2);

проходит на ура.
Имеет смысл спросить Илью Ермакова или RBV.

Что касается long double, то могу только предположить, что этот тип нестандартный (?), могущий затруднить "переносимость" ББ. (Это может быть и глупое предположение. :) )
По крайней мере, КП следовал за Явой в том, чтобы стандартизовать размерности основных типов.
Впрочем, сам тип LONGREAL остается зарезервированным, так что не исключено, что тип, подобный long double, может появиться и в ББ.