floating point problem - version 5 beta

[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.

[Demivec]

Use:

Code: Select all

ssss.d = 3.528142089298538E20

@Edit: corrected a typo regarding the exponent

[STARGÅTE]

You set too many digits, please use this format for large numbers:

Code: Select all

Double.d = 3528142089298538e5
Debug Double

[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.

[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:

Code: Select all

Debug Mod(2.6, 0.7)

[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.

[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:

Code: Select all

Debug 10000000000000000.0 + 1.0

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

[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.

[STARGÅTE]

Double | .d | 8 bytes | unlimited (see below)

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)

[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.

[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 ^^

[rko]

i be damned. now i don't know what to trust anymore.

[wilbert]

WolframAlpha knows the answer
http://www.wolframalpha.com/input/?i=35 ... 0+mod+3732

[void]

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.