math: MOD weak? - '=MOD( 6.3, 0.9 )' -> 0.8999999999999997 - C-code/compiler/library problem? - need to roll our own MOD?
A.) gnumeric: '=MOD( 6.3, 0.9 )' ->
0.8999999999999997,
B.) C-code: 'printf( "fmod( 6.3, 0.9 ) : %.25E\n", fmod( 6.3, 0.9 ) ); ->
fmod( 6.3,0.9 ) : 8.9999999999999968913755310E-01,
C.) but C-code: 'printf( "6.3 - (int)( 6.3 / 0.9 ) * 0.9 : %.25E\n", 6.3 - (int)( 6.3 / 0.9 ) * 0.9 );' ->
6.3 - (int)( 6.3 / 0.9 ) * 0.9 : 0.0000000000000000000000000E+00,
D.) and gnumeric: '= 6.3 - int( 6.3 / 0.9 ) * 0.9' ->
0 could be influenced by fake_floor in INT, IMHO not,
E.) and LO Calc: '= MOD ( 6.3, 0.9 )' ->
0,
F.) gnumeric-long: '=MOD( 0.5, 0.1 )' ->
0.099999999999999999995,
C., D. and E. look correct, what is failing in A. ( call to B ? ), and B. ?, and why?
( I know! that double representation for 6.3 is undershot: ~6.299999999999999822 while overshot for 0.9: ~0.900000000000000022,
but C., D. and E. hold, and in gnumeric as well as in C: 6.3 / 0.9 -> 7.0000..., and 7.0 * 0.9 -> 6.3, and 6.3 - 6.3 -> 0.0 )
( manual calculation is! weak for other sensitive pairs like 2.01, 2.0 reg. cancellation in the implicit subtraction,
but the fail for 6.3, 0.9 IMHO doesn't suffer from such, and is magnitudes apart )
It's less the deviations than the consistency break of MOD results disharmonic to DIV, and manual calculation better than library functions bothering me.
btw.> happy new year ...
tested with actual dev-1.12.54, Kali ( debian ) Linux,