topic Re: Why MOD has a incorrect result? in Application Development and Automation Discussions

Why MOD has a incorrect result?

tom_wan — Fri, 13 Apr 2012 13:24:05 GMT

We can see:

yyy = ( '608.9200' * ( 10 **2 ) ) mod 1

I don't understand why the result is '1'.

Re: Why MOD has a incorrect result?

matt — Fri, 13 Apr 2012 14:01:25 GMT

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

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

Re: Why MOD has a incorrect result?

tom_wan — Sat, 14 Apr 2012 01:08:57 GMT

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.

Re: Why MOD has a incorrect result?

Former Member — Sat, 14 Apr 2012 03:11:59 GMT

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:

If one of the data types involved is decfloat16 or decfloat34, the calculation type is decfloat34.
If one of the data types involved is f or if the operator ** is used, the calculation type is f.
If one of the data types involved is p, the calculation type is p.
If one of the data types involved is i, (b or s), the calculation type is i.

******

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

Re: Why MOD has a incorrect result?

matt — Sat, 14 Apr 2012 06:03:16 GMT

I guess if we want to use MOD, we have to convert to integer first. A very interesting feature! Thank-you for raising it.