People would be able to replicate your findings more easily if you pasted your code, rather than an image of it.
DATA xxx(7) TYPE p DECIMALS 4 VALUE '60892.0000'.
DATA xxx2(7) TYPE p DECIMALS 4 VALUE '608.9200'.
DATA yyy(7) TYPE p DECIMALS 4.
DATA zzz(7) TYPE p DECIMALS 4.
yyy = '60892.0000' MOD 1.
WRITE yyy.
yyy = ( '608.9200' * 10 ** 2 ) MOD 1.
WRITE / yyy.
yyy = ( '608.9200' * 100 ) MOD 1.
WRITE / yyy.
Odd, isn't it. I suspect that it's the 10 ** 2 that's doing it. It will definitely be some kind of internal step in the calculation that's causing a type conversion and rounding error. If you change the types to f (floating point) you get:
0,0000000000000000E+00
9,9999999999272404E-01
9,9999999999272404E-01
MOD 1 is pretty weird anyway.
MOD 2, testing if it's even, also gives very strange results - changing your program to MOD 2 gives:
0,0000
2,0000
0,0000
Now, I am a mathematician, and so I know that x mod 2 NEVER equal 2!
matt
Hello matt
Thanks for the replay.
Actually from the following link,we can see that the MOD only can be used for integer division. http://help.sap.com/saphelp_nw73/helpdata/en/fc/eb32d5358411d1829f0000e829fbfe/frameset.htm
clike -> Performing Arithmetic Operations
But I am not sure whether it means : we shouldn't use MOD command to do P or F type division.
Hi Tom,
I tried using this code:
DATA yyy TYPE p DECIMALS 4.
yyy = '608.9200' * ( 10 ** 2 ). WRITE yyy.
yyy = yyy MOD 1. WRITE / yyy.
yyy = ( '608.9200' * ( 10 ** 2 ) ) MOD 1. WRITE / yyy.
And the result is this:
60,892.0000
0.0000
1.0000
******
It sure is odd; when you perform the operation step by step, it will yield the correct result but if chained, it got some weird results. The remainder can't be 1 for MOD 1.
The cause might be on the calculation type if you look closely at the documentation:
Determining the Calculation Type
The calculation type corresponds to one of the numeric data types i, p, f, or decfloat34. It is determined according to the following hierarchy, and in this order of priority:
******
Now, the calculation type used in the operation is F, but we need to store it in a P variable. The value of F will be rounded up to the number of decimal places you have in your P variable. Given this and Matthew's reply above regarding the F values, we will arrive to those weird values in question.
Hope this helps!
Regards,
Karl
I guess if we want to use MOD, we have to convert to integer first. A very interesting feature! Thank-you for raising it.