Глюк в ABAP-е

DKiyanov

Code:

REPORT ztest_round2.

DATA: ism01    TYPE afru-ism01.    " P(7) DECIMALS 3
DATA: ism01x   TYPE afru-ism01.    " P(7) DECIMALS 3
DATA: kbeasoll TYPE kbed-kbeasoll. " F(8)

ism01    = '20.920'.
ism01x   = '1.760'.
kbeasoll = '2.2680000000000000E+01'.

kbeasoll = round( val = kbeasoll dec = 3 ).

IF ( ism01 + ism01x ) > kbeasoll.
  WRITE: / 'Я здесь 1'.
ELSE.
  WRITE: / 'Я тут 1'.
ENDIF.

* Выводится 'Я здесь 1'

DATA: ism01y   TYPE afru-ism01.    " P(7) DECIMALS 3

ism01y = ism01 + ism01x.
IF ism01y > kbeasoll.
  WRITE: / 'Я здесь 2'.
ELSE.
  WRITE: / 'Я тут 2'.
ENDIF.

* Выводится 'Я тут 2'

Я в шоке

Кодер

Кажется, если верить курсу BC402, это не бага, это фича. Смотрите раздел курса Mixed Arithmetic Expressions.
Как я понимаю, за счет того что в if участвует число типа f, то и вычисления будут идти по правилам f, а значит - с погрешностью округления. Во втором случае просто сравнение p и f.

trop

во втором случае тоже должно к F приводиться,
язык который сравнивает разные типы не имеет будущего

в первом случае почему-то сумма получилась больше ,
скорее всего он по отдельности переводит p(7,3) в F перед сложением,
и чтобы как обычно не получилось например 0,199999999 f из 0,12 p(7,3)
он добавляет веществ "эпсилон",
сумма этих 2 поправок округл объясняет первый случай

Kengur

trop написал(а):

язык который сравнивает разные типы не имеет будущего

Скорее "программист который сравнивает разные типы не имеет будущего" :mrgreen:

Правила форума

Глюк в ABAP-е

Кто сейчас на конференции