n1 = 10000.00
n2 = 21832.60-11832.60

? n1-n2

Результат - 0.00

? (n1-n2)*10000000000

Результат - 0.02
Т.е, в первом сравнении результат тоже не 0, а просто округлен до 2-х знаков
Логично было бы в этом случае, чтобы результат выражения

? (n1-n2)==0.00

был .F.

но он .T.

В связи с этим возникает вопрос. Как выполняется сравнение numeric, внутренний формат которых double ?
Это не точное сравнение, а сравнение с учетом некоторой погрешности ?

По поводу особенностей операций с 8-ми байтными double я в курсе, что результат операции может быть не 0, а какое-то очень малое значение. И по поводу типа Currency тоже.
Вопрос заключается не в этом.
В приведенном примере как раз возникает такой случай, и сравнение двух значений должно давать .F.. Но оно дает .T.
Почему ? Как фокс сравнивает 2 числа double ? С учетом какой-то погрешности, так получается ?

Dima T [/src]

Я уточню

Исходя из того, что

? r*10000000000 && 0.0182

получается, что r не ноль, и сравнение с нулем должно давать .F.
Если написать этот код на C, то так и получится
Но фокс при сравнении с нулем дает .T.
Значит, у фокса алгоритм сравнения не просто сравнение двух значений, а какой-то другой
Меня интересует, какой

SSn888а как насчет поставить перед всем этим
SET DECIMALS TO 18
и "конкретизировать четкость сравнения"?

Я, собственно, не фокспрошник, и пришел на этот форум из

http://clipper.borda.ru/?1-4-0-00000596-000-0-0-1316771302

где обсуждается такой же вопрос. Меня заинтересовало, как фокс сравнивает double так, что игнорируются ошибки округления.
Что такое set decimals, я конечно знаю. Эта настройка определяет количество десятичных знаков для отображения, но никак не для сравнения. В фоксе, насколько я понимаю, неявно она используется и для алгоритма сравнения.

Но даже в msdn об этом ничего не сказано:

http://msdn.microsoft.com/en-us/library/azeb8csc(VS.80).aspx

Причем, если изменить set decimals после выполнения сравнения, то новая настройка на последющие операции сравнения не повлияет.

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

В любом случае, спасибо за ответы.

SSn888Dima TИ точность результата определяется точностью операндов и операцией. Например при сложении берется максимальная точность, при умножении - произведение точностей и т.д.
гы...
при делении аналогично
а при вычитании точность соответственно - залезает в минуса :(

максимально возможная точность, если не указана явно - определяется исходя из минимальной чисел в выражении, _отталкиваясь_от_типа_данных_

логическая ошибка была в самом начале на уровне "Как выполняется сравнение numeric, внутренний формат которых double"
и предположения, что присваивание
n1 = 10000.00
n2 = 21832.60-11832.60
дает doble этим переменным

то есть - при отсутствии предварительного декларирования переменных указании фокс сам решает, какой тип ей назначить, когда ей дается значение... по умолчанию - в нашем примере он назначает ей вовсе ну double, а обычное число с плавающей точкой, точность которого - не больше двух десятков
если хотите честно работать именно с double (точность, если не изменяет памать - больше 3 сотен - укажите это сперва перед вашим примером
LOCAL n1 as doub,;
n2 as doub
и "будет Вам щастье"

PS:
вот выдержка из доки:
"When storing floating-point numbers in Numeric fields, numeric precision is limited to approximately 15 digits in Visual FoxPro
...
This limitation is based on the way Pentium-based processors calculate and store floating-point numbers and follows the Institute of Electrical and Electronics Engineers (IEEE) floating-point specification for manipulating floating-point numbers in binary format. This standard makes it possible for floating-point numbers to be stored in reasonable amount of space and for performing calculations more quickly.
...
For values requiring higher precision, see Double Field Type."

Имеется в виду iee 754 одинарной точности aka float, что ли ? Нет, даже с 8-ми байтным double результат упомянутого выражения будет не ноль, а что-то вроде 2**-39
Если сделать простенький тест:

Local n1 = 10000.00
Local n2, n3, i
Local i1 = 0
Local i2 = 0
for i = 1 to 10000000
n2 = Round(n1+i*0.01, 2)
n3 = Round(n1+n1+i*0.01, 2)
if n1-(n3-n2)*10000000000 = 0.00
i1 ++
else
i2 ++
endif
next
? i1, i2

То видно, что где-то примерно в 13% случаев (для double, не для float) возникает погрешность.
Подобная этой програмка на С, если в ней прямо указать тип double, даст тот же результат.
И никакая заявленная точность в 16 разрядов не работает.
Вот такая она, арифметика чисел с плавающей точкой.

Dima TPavel09, ерунда какая-то у тебя в коде,

Да, прошу прощения, переводил с другого языка, скобки забыл поставить, и еще кое-какие огрехи
Вот запусти:

Public n1
n1 = 10000.00
Public n2, n3, i
Public i1, i2
i1 = 0
i2 = 0
for i = 1 to 10000000
n2 = Round(n1+i*0.01, 2)
n3 = Round(n1+n1+i*0.01, 2)
if (n1-(n3-n2))*10000000000 = 0.00
i1 = i1 + 1
else
i2 = i2 + 1
endif
next
? i1, i2