Опять плавающая запятая

[Sharfik]

..смайлик с дергающимся глазом нужен.

Число 42,3 считывается из XML и записывается в Variant как Double, и еще раз записывается в переменную типа Double.
В одном случае это при исполнении 42,299999999997, а в другом 42,300000000004 при просмотре через отладчик.
Ладно, допустим. Но стоит закрыть "проект" в исполняемой программе, открыть его заново любое кол-во раз.. и эти числа везде становятся одинаковыми.

Далее...та же программа.
В одном месте SimpleRoundTo делает так

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

//SizeDout:=42,299999999997
SizeA     :=SimpleRoundTo(SizeDout/2,-2);
//SizeA     :=21,15000000001


В другом месте SimpleRoundTo делает так. И это никак не связано с делением

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

//SizeDout:=27,00000000001
SizeA     :=SimpleRoundTo(SizeDout,-2);
//SizeA     :=27


И еще мне непонятно, почему где то вообще просто 21,37 без кучи нулей выводится.

[wavebvg]

А в чем проблема? На уровне погрешности так работает FPU и ничего особенного в этом нет. Используйте типы большей точности (к примеру, extended) или организуйте расчеты требуемой вами точности на CPU, реализовав/взяв готовые алгоритмы/библиотеки, к примеру из этой статьи: http://freepascal.ru/article/freepascal/20190411080000/

[Sharfik]

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

[zub]

21,15 не имеет точного представления в плавающей запятой, поэтому это чтото очень рядом, но не ровно 21,15. Хоть зароундись

[Сквозняк]

Нужно проверять, не используется ли где-то при преобразовании и хранении чисел другой тип переменных, тот же Extended.

[Sharfik]

21,15 не имеет точного представления в плавающей запятой, поэтому это чтото очень рядом, но не ровно 21,15. Хоть зароундись

Ага, только если не так глубоко смотреть - с учетом указанной переменной определенная часть должна отбрасываться и не влиять на сравнения. Иначе у типа Currency тоже большие проблемы были бы.

Нужно проверять, не используется ли где-то при преобразовании и хранении чисел другой тип переменных, тот же Extended.

С утра, на свежую голову тоже так подумал. Спасибо

[wavebvg]

Посмотрел на свежую голову:

Число 42,3 считывается из XML и записывается в Variant как Double, и еще раз записывается в переменную типа Double.
В одном случае это при исполнении 42,299999999997, а в другом 42,300000000004 при просмотре через отладчик.

Точность Double (15-16 значащих) говорит о том, что при чтении происходит что-то ненормальное, должно быть "точнее"

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

42,299999999997
42.299999999999997

При использовании Variant, вообще такой проблемы не должно наблюдаться:

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

program Project1;

uses
  Math,
  Variants;

var
  SizeDout, SizeA: Variant;
begin
  SizeDout := Double(42.3);
  SizeA := SimpleRoundTo(Double(SizeDout) / 2, -2);
  WriteLn(SizeDout);
  WriteLn(SizeA);
  WriteLn(VarType(SizeA) and VarTypeMask);
end.

Вывод в консоль:

42.3
21.15
5

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

[Sharfik]

wavebvg спасибо, но у меня крыша едет именно от того что хранение идет в памяти в Variant с принудительной типизацией как Double, в функцию все загружается как Double. И когда идет деление FPC все рассчитывает у себя внутри как extended, и возвращает в переменную Double значение без округления до Extended и сравнивает (A=B) тоже не с учетом типа переменной, а как Extended.
Насколько я понял, в модуле Math есть упоминание что какого то типа данных может и не быть, т.е. для отдельных процессоров отключаемые типы. Интересно вот как ему отрубить Extended
Тыкать везде округление, и сравнивать через функцию округления или дельты не самое красивое решение.
Пока костыли:

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

function ReadNodeValueAsDouble(Node:TXMLNode;Name:ShortString):Double;
var
    ChildNode :TXMLNode;
    l         :integer;
    Val       :String;
begin
    Result    :=0;
    ChildNode :=Node.NodeByName(Name);
    Math.SetRoundMode(rmUP);
    Val       :=ChildNode.Value;
    if not TryStrToFloat(Val, Result, XMLFileDefaultFormatSettings) then
    begin
       raise Exception.Create('Error read XML as Double');
    end
    else begin
       l:=Pos(XMLFileDefaultFormatSettings.DecimalSeparator,Val);
       if l>0 then
       begin
          l      :=Length(Val)-l;           //0,174
          l      :=-1*l;
          Result :=SimpleRoundTo(Result,l); //0,1739999999...
       end;                                 //0,1740000000...
    end;
end;


Кусок кода ниже оставил для подстраховки. Пока экспериментировал, оказалось что Math.SetRoundMode(rmUP); перед TryStrToFloat достаточно чтобы получать почти то, что написано в XML.

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

       l:=Pos(XMLFileDefaultFormatSettings.DecimalSeparator,Val);
       if l>0 then
       begin
          l      :=Length(Val)-l;           //0,174
          l      :=-1*l;
          Result :=SimpleRoundTo(Result,l); //0,1739999999...
       end;


[LearnMagic]

Sharfik
См статью

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

... Иначе у типа Currency тоже большие проблемы были бы.

Не совсем. Тип Currency является вещественным типом данных с фиксированной точкой (4 десятичных знака после точки), представляющий значения в диапазоне от -922337203685477.5808 до 922337203685477.5807. Тип данных Currency используется с целью получения точного результата при арифметических вычислениях