Please explain the logic

[Former Member]

Hi all,

The output of the following program is 1.

***************************************************

DATA: pack TYPE p DECIMALS 0.

pack = 1 / 3 * 3.

WRITE pack.

***************************************************

Please explain me the logic.

Regards,

Lakshmanan

[Former Member]

Congratulations, you have made a great arithmetical discovery !

[Former Member]

hi,

SInce you have defined decimals 0, the number is rounded to the nearest number.

you might have expected to display .9999999, but it rounds the decimals to display 1.

Try the same research with different data types.

Regards,

Subramanian

[matt]

>

> Hi all,
> 
>  The output of the following program is 1.
> ***************************************************
> DATA: pack TYPE p DECIMALS 0.
> 
> pack = 1 / 3 * 3.
> 
> WRITE pack.
> ***************************************************
> 
> Please explain me the logic.
> 
> Regards,
> Lakshmanan

Did you not do well in your simple arithmetic exams? Anyway, the answer in base 3.5 is Pi, funnily enough.

hth

[Sandra_Rossi]

Olivier and Matt, I had the same reaction, but if I understand well the question, it's not so simple to answer.

As explained in [abap help - calculation type|http://help.sap.com/abapdocu_70/en/ABENARITH_TYPE.htm], SAP looks at the type of all variables concerned which are P (pack), I (1), I (3), I (3). This means that the calculation type will be P (the type which can handle the highest value). SAP uses a very large temporary P with maximum of digits and decimals. Thus, the result of 1 / 3 * 3 will be 0.999999999999. Then it copies the value to "pack" variable, and as this last has no decimals, it rounds it to the nearest value, which is 1.

Lakhshaman, please be careful with your question, you should have expected such reactions, you should have indicated what is exactly the problem you have.

But that was fun

[matt]

But Sandra - he says the output of his program is 1, Not 0,999999999. So, according to the question, he wants to understand why 1 divided by 3 multiplied by 3 is 1.

What I want to know is, why -1 raised to the power of (4/6) has more answers than -1 raised to the power of (2/3).

[Former Member]

Hi All,<br><br>

Thanks for all of your time and responses.<br><br>

As Rossi said, I should have made my question clear. <br><br>

Now, the following statement is found in the ABAP keyword documentation:<br><br>

<pre>Within one set of parentheses, calculations with operators of higher priority are performed before calculations with operators of a lower priority. For consecutive operators with the same priority, the calculation is performed in the order specified.

Operator Calculation Priority Order

+ Addition of operands 1 from left to right

- Subtraction of the right from the left operand 1 left to right

• Multiplication of operands 2 from left to right

/ Division of the left by the right operand 2 from left to right

DIV Integer portion of the division of the left by the right operand 2 from left to right

MOD Integer remainder of the division of the left by the right operand 2 from left to right

• Exponentiation of the left with the right operand 3 from right to left

</pre>

Now, here is the program and the result is 1.<br><br>

<pre>DATA: pack TYPE p DECIMALS 0.

pack = 1 / 3 * 3. </pre><br><br>

Here the calculation type of the expression is p(pack).<br><br>

=> According to the table above, / and * have the same priority 2, for consecutive operators with the same priority, the calculation is performed in the order specified in the table. In the table above * comes before / .<br><br>

So the calculation should be performed with multiplication first and division next. <br><br>

So 1 / 3 * 3 => 1 / 9 which results to 0.111111..... and not 0.99999.....<br><br>

Now, in 0.11111.... the fractional part will be rounded to 0.1<br><br>

Earlier I wondered how 0.1 can be rounded to 1, as 0.1 < 0.5.<br><br>

Now with the responses of friends like Subramanian, Rossi and others ,<br>

I have understood that since the result variable pack has 0 decimal places, 0.1 is assigned as 1 to 'pack'.<br><br>

Please let me know whether my understanding is correct.<br><br>

<br><br>

Thanks & Regards,<br>

Lakshmanan<br><br>

<br><br>Edited by: Matt on Sep 1, 2009 1:58 PM - cleanup formating<br><br>

[Sandra_Rossi]

>

> Here the calculation type of the expression is p(pack). YES
> 
>  => According to the table above, / and * have the same priority 2, for consecutive operators with the same priority, the calculation is performed in the order specified in the table. In the table above * comes before  / . when you have the same priority, you must not consider that one operator is "above" or "below" the other, but use the "order" column, here it is "left to right"
>
> So the calculation should be performed with multiplication first and division next. NO, when it's the same priority, you must evaluate as indicated in "order" column, here from "left to right", so sap calculates first 1 / 3, 0.3333333, then it multiplies by 3 which gives 0.99999... Then, when SAP transfers this value to "pack", it must round it because this last has 0 decimals, which gives 1
>
> So 1 /  3 * 3 => 1 / 9 which results to 0.111111..... and not 0.99999..... bad initial assumption
>
> Now, in 0.11111.... the fractional part will be  rounded to 0.1 bad initial assumption
>
> Earlier I wondered how 0.1 can be rounded to 1, as 0.1 <  0.5. it can't, SAP always rounds \[x....x4999...\] to x, and \[x5...x9999...\] to x+1, it's just a bad initial assumption
> 
> Now with the responses of friends like  Subramanian, Rossi and others ,
>  I have understood that since the result variable pack has 0 decimal places, 0.1 is assigned as 1 to 'pack'. bad initial assumption. Just a remark here, maybe you confuse with statement PACK (or program not using "fixed point arithmetic") which would sometimes transform 0.1 to 1. But 99.9999% of the time, you will not encounter this situation.

Hope it's clear now

[SuhaSaha]

Hello Sandra,

I think Lakshmanan doesnot remember basic arithmetic rule BODMAS.

I dont think SAP overrides (or rather dares to override) the BODMAS rule.

Lakshmanan assumes that

1 / 3 * 3 = 1 / 9 = 0.11111....

But apply BODMAS

1 / 3 * 3 = 0.33333.... * 3 = 0.99999...

I agree with Matt that this is question is not about SAP rounding off logic, rather a lack of basic arithmetic principle.

Cheers,

Suhas

[Sandra_Rossi]

2 fun exercises:

data int type i.
int = 1 / 3 * 3.
write int.

what do you expect? what is the result?

That's zero!

Now with that:

data int type i.
int = 1 / 3 * '3'.
write int.

That's one!

Fun

Not always so obvious. I think Lakshmanan expected my answer

okay, with packed fields, it's really more obvious, but not always.

[SuhaSaha]

Hello Sandra,

OMG !!! C'mon SAP can't do this

BTW, how did you come about this? I can never imagine this in my wildest dreams )

BR,

Suhas

[matt]

Now switch off the fixed point arithmetic flag...

matt

[Former Member]

>

>  => According to the table above, / and * have the same priority 2, for consecutive operators with the same priority, the calculation is performed in the order specified in the table. In the table above * comes before  / .<br><br>
> 
> So the calculation should be performed with multiplication first and division next. <br><br>
> So 1 /  3 * 3 => 1 / 9 which results to 0.111111..... and not 0.99999.....<br><br>

Check the order column next to * and / . Its from left to right.

Thus in 1 / 3 * 3 , consider it from left to right. Thus / will be performmed first and not the *. You are considering right to left which is wrong.

Hope you are clear now.

Regards,

Vikranth

[Former Member]

Now lets assume that we don't have absolute figures but variables,

So

" Assume that all the values are of type XKWERT

A = 1

B = 3

C = 3

So, Z = A / B * C

Z = 1/9 = 0.111111111

How does this happen?

Now as strange behaviour has been noticed, in one of our clients Z = 1 and in other client z = 0.111111111

Please let me know the solution.

Regards,

Dantham Conplowedson