Еще один странный глюк

[raz]

Имеем тестовый Job

static void Test_Job(Args _args)
{
    AmountCur         a,b,c,d,e,f,t1,t2;
    ;
    a = 13532.5;
    b = 100 / 2827;
    c = 2776851.86;
    d = 2776851.86;
    e = a / b;
    f = (a / b) / c * d;

    e = Currency::amount(e);
    f = Currency::amount(f);

    info(strfmt("%1", e));
    info(strfmt("%1", f));
}

Результат:

Цитата:

382 563,78
382 563,77

Т.е. получаем расхождение в копейку, обнаружено при сопоставлении.
Дело в этом куске:

b = 100 / 2827;

Если тут прописать:

b = 0.0353731871241599;

То результат:

Цитата:

Сообщение (15:46:14)
382 563,77
382 563,77

ЗЫ. DAX 3 KR1

[MikeR]

в 2009 такая же картина.
Мне кажется, что аксапта не хранит значения после четвертого знака после запятой.

[kornix]

DAX 4.0 - такого глюка нет.
Результат одинаковый.

А у вас в EDT Amount свойство NoOfDecimals чему равно?

[S.Kuskov]

А в чём вопрос? Это очевидно, что в общем случае погрешность операций с плавающей запятой не позволяет ожидать абсолютно точный результат. Например следующий код я думаю будет выдавать одинаковый результат на любой версии.

info(strfmt("%1", num2str(1/3*3, 0, 16, 0, 0)));

[Владимир Максимов]

Надо смотреть не результат, а промежуточные данные

static void Test_Job(Args _args)
{
    AmountCur         a,b,c,d,e,f,t1,t2;
    ;
    a = 13532.5;
    b = 100 / 2827;
    c = 2776851.86;
    d = 2776851.86;
    e = a / b;
    f = (a / b) / c * d;

    info("a / b = " + num2str(a / b,0,16,1,0));
    info("(a / b) / c = " + num2str((a / b) / c,0,16,1,0));
    info("(a / b) / c * d = " + num2str((a / b) / c * d,0,16,1,0));
    info("round((a / b) / c * d, 0.01) = " + num2str(round((a / b) / c * d, 0.01),0,16,1,0));
}

Ни одна программа не может хранить бесконечные дроби. В любом случае, количество значащих цифр мантиссы будет ограничено некоторым фиксированным числом. Скорее всего, как и большинство продуктов Microsoft, действительные данные в памяти Axapta храняться с точностью до 16 значащих цифр (точнее, то 15,95). Как следствие, выражение вида

1/3 = 0,3333333333333333

Не может иметь "бесконечное" число 3, чтобы при последующем умножении на 3 получить ровно единицу. Будет число чуть меньше единицы. На сколько "чуть" зависит от того, сколько значащих цифр хранится в данной программной оболочке

Ну, и кроме того, важными являются правила округления. Система Axapta, очевидно, использует "стандартные" правила округления

В приведенном изначально примере вопрос стоит об округлении числа

382563.7749999999000000

В данном контексте, фактически, с точностью до 2 знака после запятой. Очевидно, это будет число

382563.77

Все в соответствии с правилами округления.

[Poleax]

Варианты:
1) b = 0.0353731871241599;

e = 382563.7749999999;
f = 382563.7749999999;

2) b = 100 / 2827;

e = 382563.775;
f = 382563.7749999999;

Это имхо недостаток правила.
Если следовать правилу

Цитата:

Округление к ближайшему целому (англ. round) — наиболее часто используемое округление. Число в десятичной системе округляют до N-ого знака в зависимости от N+1 знака:
если N+1 знак < 5, то N-ый знак сохраняют, а N+1 и все последующие обнуляют;
если N+1 знак ≥ 5, то N-ый знак увеличивают на единицу, а N+1 и все последующие обнуляют.

То права воздействия на N имеет только цифра N+1.
Все остальные цифры в пролете

[raz]

Цитата:

Сообщение от Владимир Максимов

В приведенном изначально примере вопрос стоит об округлении числа

382563.7749999999000000

В данном контексте, фактически, с точностью до 2 знака после запятой. Очевидно, это будет число

382563.77

Все в соответствии с правилами округления.

В том то и проблема, что для:

e = a / b;

Результат будет: 382563.78

[AndyD]

А вот так

f = (a / b) * d / c;

округленные значения будут одинаковы, но f != e.

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

[KiselevSA]

А что получится, если в формуле записать b = 100 / 2827.0?

[S.Kuskov]

Цитата:

Сообщение от raz

Если тут прописать:

b = 0.0353731871241599;

То результат: ....

Вот где вкралась неточность в ваших расчётах!
Переменная b, значение которой вы вычисляете как 100 / 2827 на самом деле инициализируется не 0.0353731871241599, а 0.3537318712415989e-1. это легко проверить

b = 100 / 2827;
info(num2str(10*b, 0, 16, 0, 0));

Дело в том что когда мы говорим о точности в 16 знаков после запятой, на самом деле имеются в виду 16 значащих цифр мантисы. Функция же num2str возвращает непосредственно первые 16 цифр после запятой, в момент преоброзования отбрасывая все невместившиеся значащие цифры и округляя 17 знак.

Интересно а есть ли в аксапте возможность преобразовать вещественное значение в строку без потери значащих разрядов (т.е в экспоненциальном формате)?

[AndyD]

На самом деле, не важно, какое значение будет в b
Если переписать так

f = (a / b) * (d / c);

то f == e

[S.Kuskov]

Цитата:

Сообщение от AndyD

На самом деле, не важно, какое значение будет в b
Если переписать так

f = (a / b) * (d / c);

то f == e

Ещё бы, ведь d == с

[AndyD]

Это просто еще одна иллюстрация к значениям промежуточных вычислений

1 / c * d != 1 * d / c != 1

в отличие от

1 * (d / c) == 1 / (c / d) == 1

PS Насчет 1 * d / c != 1 погорячился

[raz]

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

CustVendSettle.settleNow()
{
	....

	paym2Invoice = 100 / custVendTransOpenDebet.settleExchRate;

	....
	
	custVendTransCredit.settleAmountCur -= Currency::amount(settleAmountCur / paym2Invoice, custVendTransCredit.currencyCode);
	
	// так можно вылечить
	custVendTransCredit.settleAmountCur -= Currency::amount((settleAmountCur / paym2Invoice) / custVendTransCredit.amountCur * custVendTransCredit.amountCur, custVendTransCredit.currencyCode);

	....


	settleAmountMSTCredit   = Currency::amount(-(settleAmountCur / paym2Invoice) /
					custVendTransCredit.amountCur * custVendTransCredit.amountMST);
	
	custVendTransCredit.settleAmountMST  += settleAmountMSTCredit;

	....
}

DAX 3