größte Zahl für interne Berechnung im RPG

[itec01]

Hallo Zusammen,
diese Formel bricht ab:
for w@Idx = w@Start to Pi@K;
monitor;
Po@Poisson += ((Pi@Lambda ** w@Idx) *
(c@Eulner ** (Pi@Lambda * -1)) )
/ factorial(w@Idx);
on-error *all;
Po@Poisson = -1;
leave;
endmon;
endfor;

Es liegt an der Berechnung Pi@Lambda ** w@idx. Index 49 klappt noch, Index 50 geht schief.
Pi@Lambda = 35, sprich 35^50. Ist natürlich eine gigantisch große Zahl.

In der Formel geht es um den Poisson Wert kumliert, sprich Excel Formel POISSON.VERT.
Siehe auch: https://www.ibm.com/docs/de/i/7.3?topic=types-numbers

Es geht wohl max 10^63+1, aber das wäre ja schon kleiner als 35^50 und müsste somit viel früher abbrechen. Zusätzlich steht aber auch noch, dass es den Typ decimal floating point gibt, der wohl 10^6144 kann.
Wie bekomme ich das gelöst?

Danke.
Klaus

[itec01]

Ich habs:
https://www.rpgpgm.com/2018/06/diffe...rs-in-rpg.html

[Fuerchau]

Zu bedenken ist einfach, dass DecFloat nur 16 oder 34 stellige Genauigkeit hat.
Somit wird die Potenz im Ergebnis immer ungenauer und ob das akzeptabel ist....
Aber Excel kann ja nur Double und das ist max. 17-Stellig * 10^+/-308.
Somit kannst du in ILERPG auch Float(8) nehmen, um mit Excel gleich zu ziehen.

Excel Potenz(35;50):
15973578394645000000000000000000000000000000000000 0000000000000000000000000000,00

Calc.exe (kann wohlDecFloat)
1,5973578394644968506635155063919e+77

[BenderD]

Hallo Zusammen,
diese Formel bricht ab:
for w@Idx = w@Start to Pi@K;
monitor;
Po@Poisson += ((Pi@Lambda ** w@Idx) *
(c@Eulner ** (Pi@Lambda * -1)) )
/ factorial(w@Idx);
on-error *all;
Po@Poisson = -1;
leave;
endmon;
endfor;

Es liegt an der Berechnung Pi@Lambda ** w@idx. Index 49 klappt noch, Index 50 geht schief.
Pi@Lambda = 35, sprich 35^50. Ist natürlich eine gigantisch große Zahl.

In der Formel geht es um den Poisson Wert kumliert, sprich Excel Formel POISSON.VERT.
Siehe auch: https://www.ibm.com/docs/de/i/7.3?topic=types-numbers

Es geht wohl max 10^63+1, aber das wäre ja schon kleiner als 35^50 und müsste somit viel früher abbrechen. Zusätzlich steht aber auch noch, dass es den Typ decimal floating point gibt, der wohl 10^6144 kann.
Wie bekomme ich das gelöst?

Danke.
Klaus

... das gesuchte Ergebnis liegt per definitionem zwischen 0 und 1. Das Problem mit der Formel ist, dass was sehr großes durch was ziemlich großes dividiert wird und mit was sehr kleinem multipliziert wird.
Wenn du das mit float Arithmetrik machst, verlierst du dabei Genauigkeit.
Sowas berechnet man rekursiv, dann tritt das numeric overflow Problem später auf. Wenn das immer noch nicht reicht, dann gibt es noch die Stirling-Formel. Frag mal Marjorie nach Poisson Verteilung - da gibt es einen Wikipedia Artkel.
Wo ich gerade dabei bin: gewöhn dir mal den Klammeraffen in den Namen ab, der macht Probleme, weil der bei verschiedenen CCSIDs nicht immer an derselben Stelle sitzt.

D*B

[Fuerchau]

Solange bei der Umwandlung die CCSID passt, kann man @ und # verwenden. Beim Transport der Quelle auf ein anderes System kann es da schon mal Probleme geben.
Man erinnere sich nur an die Lib #LIBRARY, die nur in einer Jobumgebung passend zur Systemsprache (Language, nicht CCSID) passt und ansonsten als ungültiger Name abgelehnt wird.

[Fuerchau]

Bei der Berechung kann man auch den Umweg via Log10-Berechungen machen.
Schließlich sind Multiplikation/Division und Potenzrechnung mit LOG10 einfacher, da die Werte kleiner sind und bei 63-stelliger Genauigkeit wahrscheinlich auch performanter.
Ein packed(63:55) entspricht da schon einem 10 hoch 10.000.000!
Auch die Fakultät kannst du letztendlich mit Addition von LOG10 berechnen.
Somit hast du nur noch das Endergebnis mit 10 ** (Log10-Ergebnis) auszuwerten.