error with MOD()

[foxteam1]

Hi

I use MOD() function but i have a problem comparing with calc. i try

With calc :
60000000000000001/23=2608695652173913,0869565217391304
and
with Mod(60000000000000001/23)=0
in VFP Command Window
60000000000000001/23=2608695652173913,000000000000000
(i have changed the number of decimal digits to 18 in the options)

Any idea ? why i can't use MOD() ?

Thanks
Franck

( i use VFP6 SP4)

 

[Mike Gagnon]

According to the help file
When storing floating-point numbers in Numeric fields, numeric precision is limited to approximately 15 digits in Visual FoxPro. Therefore, precision more than 15 digits might be lost when converting from decimal to binary numbers, storing numbers with infinitely repeating decimal values in binary, performing multiple repeated operations, and storing numeric values in Character fields and in memory variables in binary format.

This limitation is based on the way Pentium-based processors calculate and store floating-point numbers and follows the Institute of Electrical and Electronics Engineers (IEEE) floating-point specification for manipulating floating-point numbers in binary format. This standard makes it possible for floating-point numbers to be stored in reasonable amount of space and for performing calculations more quickly.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[Shardlow]

Hi FoxTeam1,
For starters Mod(60000000000000001/23) is an invalid function call. The mod function takes 2 parameters something like Mod(60000000000000001, 23).

Secondly the mod() function returns the remainder of a division not the result of a division.
For example the result of 60000000000000001/23 is 2608695652173913,0869565217391304
mod(60000000000000001, 23) is 1

The mod() function is not working for you in VFP, because the limit for digits of precision in numeric computations is 9007199254740992. As your 1st parameter of 60000000000000001 exceeds this value the mod() function is failing and returning zero.


Shardlow.

 

[mmerlinn]

Bottom line is that because NO computer understands anything except BINARY arithmetic, ALL decimal numbers are ALWAYS rounded to a specific number of decimal digits, typically 15 digits. Any time you use number with more than the number of SIGNIFICANT digits that the computer and/or program you are using can understand, you will run into this problem.


mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[dbMark]

As I recall the floating point numbers have precision up to about 18 digits. The reason the precision is stopped at 15 digits is to avoid getting "too close to the edge".

For example, if internally the program calculated and used all 18 digits, then you would often encounter impossible results:

x=10
? x=4+6
[COLOR=maroon].F.[/color]

How could that be? Looking at the unseen:

x=10    [COLOR=green]&& 10.00000000000000001[/color]
? x=4+6 &&  [COLOR=green]3.99999999999999999+5.99999999999999998[/color]
[COLOR=maroon].F.[/color]

By rounding off the last 3 digits, we avoid inexplicable erroneos calculations. If memory serves me right, back in the early versions of dBase in the 1980s, maybe II or III, the programmers had to send out an update to fix just such a problem.