Page 1 of 1
floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 12:55 pm
by rko
ssss.d = 352814208929853800000.0 <------- numerical overflow number to big
Double .d 8 bytes unlimited
this should work. it does work with modula-2, freepascal and c. for this reason i can not get an fmod to work.
thanx.
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 1:15 pm
by Demivec
Use:
@Edit: corrected a typo regarding the exponent
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 1:16 pm
by STARGÅTE
You set too many digits, please use this format for large numbers:
Code: Select all
Double.d = 3528142089298538e5
Debug Double
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 1:31 pm
by rko
well, in calculations a number such as 352814208929853800000.0 results and the following function will not be able to calculate its correct value:
Code: Select all
Procedure.d fmod(left.d, right.d)
Protected quota.q
quota = left - (right * (left/right))
ProcedureReturn quota
EndProcedure
the call to the function with
352814208929853800000.0, 3732 and
352814208929853800001.0, 3732
will produce the same result : -104.0 which is definitely wrong.
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 1:45 pm
by STARGÅTE
352814208929853800001.0 is no valid double number, doubles only have 15 significant digits!
352814208929853800000 is also no valid quad number, quads only up to 2^63-1 !
the function "fmod" already in PB:
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 1:53 pm
by rko
yes it is - but it returns false results for large numbers:
1200.0 = Mod(3.528142089298538E20, 3732.0)
2872 = Mod(3.528142089298538E20, 3732.0) with a calculator
with the function
Code: Select all
Procedure.d fmod(left.d, right.d)
Protected quota.q
quota = left - (right * (left/right))
ProcedureReturn quota
EndProcedure
it returns -104.0 which is false. i guess there might be a problem with floating point calculations!
that renders -unfortunately- purebasic for the moment
unusable.
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 2:03 pm
by STARGÅTE
and again:
3.528142089298538E20 is :
352814208929853800000.0
and:
000000000000000003732.0
so you
can't calculate this numbers with that function that use doubles !!
Same like:
a "calculator" use quad-floats (128bit) or unlimited numbers (like mathematica)
but this number formats are very slow, but PB will be fast and not a mathematically correct language
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 2:24 pm
by rko
i might not understand you
but
help of
purebasic: Double .d 8 bytes
unlimited -
and that means it should calculate.#
from a modula compiler help:
LONGREAL 8 bytes Real numbers with an approximate range of 4.19E-307 to 1.67E+308 and an accuracy of about 16 decimal digits
and with function:
Code: Select all
PROCEDURE ffmod(left, right: LONGREAL): LONGREAL;
VAR quota: LONGREAL;
BEGIN
quota := left - (right * (left/right));
RETURN quota;
END ffmod;
#
it calculates correctly
maybe i am nuts, dumb or something else, but with 8 bytes it
should calculate correctly.
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 2:53 pm
by STARGÅTE
Pure Basic Help wrote:Double | .d | 8 bytes | unlimited (see below)
below wrote:However, you cannot store very large numbers with very high accuracy (big and small numbers at the same time, so to speak).
and i don't understand your function:
left - (right * (left/right)) = left - right * left / right = left - 1 * left = left - left = 0
i think you meen:
Code: Select all
Procedure.d fmod(left.d, right.d)
ProcedureReturn left - (right * Int(left/right))
EndProcedure
Debug fmod(2.4, 0.7)
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 3:21 pm
by rko
well your function will produce 0.0 with large numbers and that does make it unusable.
i maybe understanding a comment from above wrong, but i get the feeling, that NUMBER+E20 is the upper limit for calculations with purebasic. i am not expecting mathematica or a calculator, but when there are restrictions in floating point that are not mentioned in the help (they are unlimited), then i unfortunately can't use purebasic for my program. i tried to reproduce the function with several languages and it works.
i thank you for your tries to help, but i think i will need ask what the limits for doubles are first.
thank you very much.
p.s.
the function should be fmod (c++) and i know it is slightly different.
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 4:05 pm
by STARGÅTE
btw, the correct result of:
remainder of 352814208929853800000 / 3732 is 752
so you calculator work's wront too.
Edit: sry 352814208929853800000 to high for quads ^^
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 4:13 pm
by rko
i be damned. now i don't know what to trust anymore.
Re: floating point problem - version 5 beta
Posted: Wed Oct 03, 2012 4:25 pm
by wilbert
Re: floating point problem - version 5 beta
Posted: Fri Oct 12, 2012 1:52 am
by void
rko wrote:i thank you for your tries to help, but i think i will need ask what the limits for doubles are first.
The basic problem with floats and doubles is that they are approximations, moreover, they have fairly specific domains in which they remain accurate. With floating point math, you can have either very large scale numbers, or very precise numbers. You can't have both. The bounds within which you can have those change with the size of the object (4 bytes, 8 bytes, 16 bytes, etc), but the basic property is still there.
Most problems along this line can usually be resolved by understanding the scale at which you need to work. You might find there's intermediary steps you can take to prevent large/small interactions from taking place, or you can re-scale your problem domain so they don't happen at all.
What are you trying to do? This might better inform approaches to have non-erroneous results.