Unwanted rounding using inline declaration

[rosenberg_eitan]

Hi,

What will be the result of value_2 and value_3 ?

Using debug this what I get:

IMHO it needs to be like value4 .

Am I missing something here....

Regards.

The code:

DATA(value_2)  = ( '5.555' + '1.77777' ) .

  data c_1 TYPE p DECIMALS 3 VALUE '5.555' . " 1 of type Packed Number

  data c_2 TYPE p DECIMALS 5 VALUE '1.77777' . " 2 of type Packed Number

  DATA(value_3) = ( c_1 + c_2 ) .

  DATA: value4 TYPE p DECIMALS 5 . " Data: value4 of type Packed Number

  value4 = ( c_1 + c_2 ) .

[rosenberg_eitan]

I have done a small thes in VBS .

And the result:

As value4.

Any idea friends

Regards.

[Former Member]

Hi Eitan,

I don't know the exact reason of this issue ('Hello, ABAP gurus, where are you?') but what I noticed is that value2 and value3 got type P(8) - without DECIMALS part (you can see it in debugger). So they naturally truncate all decimal parts, like if you simply declare them as 'data value2 type p'.

I thought it is because ABAP cannot chose between DECIMAL 3 and DECIMALS 5 (as you have both types on the right side), but when I changed both c_1 and c_2 to DECIMALS 5 - it didn't work neither. So it seems like ABAP cannot correctly specify decimal part of type p and always uses DECIMALS 0.

Thank you.

[rosenberg_eitan]

Hi,

I was under the assumption that SAP will behave under the same rules as my math teacher thought me at junior school.

It seems that whoever wrote VBS interpreter have the same teacher.....

Regards.

[SuhaSaha]

Hi Eitan,

I think you should dig further into the conversion rules defined for ABAP - ABAP Keyword Documentation

IMO the developer should not a generic type for the LHS of the expression, you can use the operator CONV to do the conversion for you. See the sample code below -

TYPES pack_dec TYPE p DECIMALS 5.

START-OF-SELECTION.

  DATA(value_2) = CONV pack_dec('5.555' + '1.77777').
  cl_demo_output=>write_data(
    EXPORTING
      value = value_2
      name  = 'Variable 2'
  ).

  DATA c_1 TYPE p DECIMALS 3 VALUE '5.555' . " 1 of type Packed Number
  DATA c_2 TYPE p DECIMALS 5 VALUE '1.77777' . " 2 of type Packed Number

  DATA(value_3) = CONV pack_dec( c_1 + c_2 ).
  cl_demo_output=>write_data(
    EXPORTING
      value = value_3
      name  = 'Variable 3'
  ).

  DATA value_4 TYPE pack_dec. " Data: value4 of type Packed Number

  value_4 = c_1 + c_2.
  cl_demo_output=>write_data(
    EXPORTING
      value = value_4
      name  = 'Variable 4'
  ).

" Display the log
cl_demo_output=>display( ).

BR,

Suhas

Message was edited by: Suhas Saha

[ceedee666]

Hi Eitan,

just to add to what Suhas already said. There is quite some discussion on the topic in the comments to s original post on the topic:

https://scn.sap.com/community/abap/blog/2013/05/23/abap-news-for-release-740--inline-declarations

Christian

[rosenberg_eitan]

Hi,

Thanks for the daily lesson .

You solve the mystery for me.

I was under the impression that ABAP will behave more along the lines of the rest of the industry.

For example take a look at this java script code:

Result:

Regards.

[horst_keller]

Hi all,

Suhas recommended the right thing to do, using CONV, and Alexander Skaskevich is also correct in saying that ABAP is not able to determine the "right" type here.

The reason is that for an arithmetic expression as RHS of an inline declaration, the calculation type of the arithmetic expression is used as data type for the declaration. Unfortunately, the compiler cannot extract an unambiguous data type from calculation type p (it cannot not take the operand with largest value range or most decimal places because type p is handled in a very special way in calculations). Therefore, for calculation type p, the data type for the declaration is always set to  p, length 8 without decimal places. This results in loss of decimal places and even can lead to overflow exceptions (if you have numbers too large for p length 8 on the RHS).

I admit that this has been missing in the documentation .

For 7.50, SP02, I added this fact and a warning hint to

• =, Arithmetic Expression
• arith_exp - Calculation Type

The portal version of the documentation will be updated.

I also asked the developer, if it wouldn't be a good idea to raise a syntax warning when using calculation type p on the RHS of an inline declaration.

Thanks Christian for notifying. Interestingly I had hotline service that week and received the same incident internally the same day ...

Horst

PS: A summarizing example:

TYPES pack8_3  TYPE p LENGTH 8 DECIMALS 3. 
TYPES pack16   TYPE p LENGTH 16. 
DATA  number1  TYPE pack8_3 VALUE '12345.6789'. 
DATA  number2  TYPE pack16 VALUE  '12345678901234567890'. 

DATA(result1) = number1.                    "p, length 8, decimals 3 
DATA(result2) = number2.                    "p, length 16 
TRY. 
    DATA(result3) = 1 * number1.            "p, length 8, decimals 0 
    DATA(result4) = 1 * number2.            "p, length 8 ->exception 
  CATCH cx_sy_arithmetic_overflow. 
ENDTRY. 
DATA(result5) = CONV pack8_3( 1 * number1 ). "p, length 8, decimals 3 
DATA(result6) = CONV pack16(  1 * number2 ). "p, length 16 

[Former Member]

Hi Horst,

Thanks for the clarification.

I wonder how the "internal" calculation data type is being determined in such case?

According to Eitan's example, I understand that it doesn't use P length 8 (Otherwise, the result of 5.555 + 1.77777 should have been 8, but that's not the case).

[horst_keller]

I knew that someone is going to ask that .

Now that's the old story of calculation type p as documented under arith_exp - Calculation Type.

Calculation type p 
Fixed point arithmetic The arithmetic expression is calculated to an internal accuracy of 31 decimal places and using a special decimal floating point arithmetic for intermediate results. During the calculation, the decimal point for numbers of type p is not fixed. If an overflow occurs because an intermediate result is greater than 10^31 - 1, the whole expression is recalculated to an internal accuracy of 63 decimal places, or a maximum value of 10^63 -1 for intermediate results. If another overflow occurs, the handleable exception CX_SY_ARITHMETIC_OVERFLOW is raised. An overflow always occurs if the level of accuracy is not sufficient for all decimal places before the decimal separator. Surplus decimal places do not raise an exception, but are rounded to the nearest whole number for each intermediate result. 

It's a runtime thing. The compiler cannot evaluate that for type inference.

.