De precisie van FM berekeningen

[rmw]

Ik loop tegen het volgende aan:

 

Waarde = 2 ^ 10 (= 1024)
Lg ( Waarde ) = 10

So far so good (in goed nederlands )

 

Filemaker loopt echter uit de pas als de macht van 2 groter wordt dan 172....

Ik heb zitten stoeien met de functie SetPrecision. Dat levert niks op.

Nu werkt SetPrecision niet bij trigonometrische functies (zegt de helptekst).....de vraag is dus of Lg() in die categorie valt.

Ik heb het ooit wel geleerd, dacht ik.....maar zou het nu niet meer durven zeggen

 

Zo ja, hoe krijg ik dan voor elkaar dat het boven de 172 wel werkt (ik moet tot 288, het aantal keren dat 5 minuten in een dag past)

Zo nee, wat doe ik dan verkeerd, dat het bij mij boven de 172 niet meer matched.

 

rmw

Edited December 14, 2009 by Guest

[andries]

hier alvast het antwoord van FileMaker wat voor hun trigonometrische functies zijn:

 

http://www.filemaker.com/nl/help/html/func_ref3.33.108.html

 

Ln is volgens mij een logaritmische functie .

[rmw]

Ln is volgens mij een logaritmische functie .

 

Ik denk dat ik met je mee ga

Ik merk trouwens nu dat ik een typefout heb gemaakt: het gaat om de functie 'Lg' (niet onbelangrijk)

 

Blijft de volgende vraag dus staan:

Wat doe ik dan verkeerd, dat het bij mij boven de 172 niet meer gelijk loopt.

 

Probeer het maar zelf:

Waarde = 2 ^ 172
SetPrecision ( Lg ( Waarde ) ; 400 ) = 172

Waarde = 2 ^ 173
SetPrecision ( Lg ( Waarde ) ; 400 ) = 172,9999999999999999999999999985405... en een beetje

Ik ben bang dat we de grenzen van FM weer lekker aan het verkennen zijn....

 

rmw

[JeanWM]

Ik krijg in alle omstandigheden het juiste resultaat.

 

We weten dat als 2^x = y

 

Dan is Lg(y) = x

 

en die berekening maakt FM perfect in beide richtingen, zowel voor 172, 173 als 288 is alles na de comma 0.

Moest er iets zijn dan zou de waarde na de comma het tonen in de reverse berekening.

 

De berekening geeft 4,9732e + 86 in beide richtingen:

497323236409786642155382248146820840100456150797347717440463976893159497012533375533056

497323236409786642155382248146820840100456150797347717440463976893159497012533375533056

 

voor 288

 

Zou het kunnen dat je floating point van je computer parten speelt?

[rmw]

Hmmm, dat gaat weer lekker

 

Probeer het volgende eens

Let (
[
xExp = 2 ^ 288 ;
xValue = Lg ( xExp ) ;
xPreciseExp = SetPrecision ( 2 ^ 288 ; 400 ) ;
xPreciseValue = Lg ( xPreciseExp )
] ; 

xPreciseExp & " / " & xPreciseValue & "¶" & xExp & " / " & xValue

)

en dan dit

Let (
[
xExp = 2 ^ 288 - 1 ;
xValue = Lg ( xExp ) ;
xPreciseExp = SetPrecision ( 2 ^ 288 - 1 ; 400 ) ;
xPreciseValue = Lg ( xPreciseExp )
] ; 

xPreciseExp & " / " & xPreciseValue & "¶" & xExp & " / " & xValue

)

 

Er is iets niet lekker aan die uitkomsten, maar ik weet niet wat...

 

rmw

[JeanWM]

497323236409786642155382248146820840100456150797347717440463976893159497012533375533056 / 288

497323236409786642155382248146820840100456150797347717440463976893159497012533375533056 / 288

 

 

en dan

 

497323236409786642155382248146820840100456150797347717440463976893159497012533375533055 / 288

497323236409786642155382248146820840100456150797347717440463976893159497012533375533055 / 288

 

 

Wat geheel in de lijn ligt.

 

De rekenvolgorde is immers:

 

Machtsverheffen, Vermenigvuldigen, Delen, Optellen, Aftrekken

 

Verwacht dus niet 2 ^ 287.

Maar wel (2 ^ 288) - 1, wat het verschil geeft tussen 55 en 56.

 

Tenandere, een Let() gebruiken voor zo'n berekening is gevaarlijk.

Je neemt een mogelijke fout steeds mee in de onderliggende berekeningen.

 

Dat zou kunnen resulteren in 4,9732e+89 ipv 4,9732e+86

[rmw]

Ik was misschien wat onduidelijk.

Het ging me niet om de rekenkundige berekeningsvolgorde. Die is prima bij FM.

Het verschil zit in de precisie.

 

In het eerste voorbeeld verwacht ik bij de gewone expressie 288 als uitkomst en dat is ook zo.

Maar bij de berekening met precisie 400 krijg ik 287,9999999999999 en nog een beetje.

 

bij 2^288 dus

497323236409786642155382248146820840100456150797347717440463976893159497012533375533056 / 287,9999999999999999999999999995740844537222768267576979460244104655665817315692117705512991486613961904978351795864253203984662259182698723132636865711819581716250663280476925397300289522400232771431099730664210285696738588686555110283682524726878579447023150918958808955292387492917376418619566075222801079538939583836631187224413031705337019867027470717087522634571216572444686107078350981001922227919

 

497323236409786642155382248146820840100456150797347717440463976893159497012533375533056 / 288

 

En ik verwacht bij de precisie berekening toch ook echt 288

 

Als je er dan 1 vanaf trekt, waardoor je net naast de 288 uit zou moeten komen krijg ik dit

bij 2^288-1 dus

497323236409786642155382248146820840100456150797347717440463976893159497012533375533055 / 287,9999999999999999999999999995740844537222768267576979460244104655665817315692117705512991486613961904978351795864253203984662259182698723132636865711819581716250663280476925397300289522400232771431099730664210285696738588686555110283682524726878579447023150918958808955292387492917376418619566075222801079538939583836631187224413031705337019867027470717087522634571216572444686107078350981001922227919

 

497323236409786642155382248146820840100456150797347717440463976893159497012533375533055 / 288

 

Dat in het geval zonder precisie FM ook uitkomt op 288 als je van dat mega getal slechts 1 aftrekt kan ik me voorstellen.

Maar wat is de reden dat het eerste voorbeeld met een hoge precisie fout uitkomt.

 

Voor de zekerheid: iMac 20", OSX 10.6.2, 2,66GHz Intel Core 2 Duo

 

rmw

PS ik ben al bezig met een andere manier om 288 bits te kunnen bijhouden en omzetten, maar dit intrigeert me wel.

[JeanWM]

Dan is het voormij terug naar familie want ik krijg in beide gevallen netjes 288,0000....

 

Misschien dat er verderop (verder dan positie 86) een verschil begint te komen....maar daar twijfel ik een beetje aan.