C++ Community

Alexander Sulfrian

Hi,
wie kann man pi matematisch berechnen.

Danke!

KPC

Wer suchet der findet ...
Pi berechnen

The Amarin

hi, ich habe jetzt PI mal mit dem algo angenähert, und bekomme

3.141 592 648 589

raus.
calc.exe meint jedoch:

3,141 592 653 589

Kann mir mal jemand erklären, warum die "648" und "653" nicht übereinstimmen, die nächsten 3 ziffern jedoch wieder identisch sind? Ich habe das Programm mit double und 200M durchläufen gemacht. Wenn ich long double nehme, stimmen an anderen Stellen (aber immer mittendrin!) irgendwelche Ziffern nicht... das kann doch gar nicht sein?!

volkard

zeig mal dein programm.

The Amarin

#include<stdio.h>
void main()
    {
    long i,j;
    double pi,nen,zal;
    clrscr();
    pi=0.0; nen=1.0; zal=1.0;
    for(i=0;i<10000;i++) for(j=0;j<10000;j++)
            {
            pi+=zal/nen; nen+=2; pi-=zal/nen; nen+=2;
            }
    printf("%.20lg",pi*4);
    }

volkard

also ich nahm mal an, daß sich da irgendwelche fehler aufsummiert haben und hab das prog leicht umgebaut, damit ich das besser verfolgen kann.

#include<stdio.h>
#include<math.h>
void main()
{
    double i,pi,nen,zal;
    pi=0.0; nen=1.0; zal=1.0;
    for(i=0;i<10000000;i+=2)
    {
        pi+=1.0/(2*i+1);
        pi-=1.0/(2*i+3);
    }
    printf("%.20lg\n",pi*4);
    printf("%.20lg\n\n",atan(1)*4);
}

ausgabe:
3.141592 5 5358979 15
3.141592 6 5358979 31

ich lach mich kringelig, da stimmt irgendwas ganz und gar nicht.

wenn ich 10mal mehr zahlen nehme passiert das hier:

3.1415926 4 3589 326
3.1415926 5 3589 7931

edit: mir scheint, wenn man nur 10000000 (1 mit 7 nullen) reihenglieder nimmt, darf man nicht mehr als 7 stellen genauigkeit erwarten.
daß allerdings so viele stellen nachher stimmen, ist ein wunder.

double i,pi,nen,zal,sign;
    pi=0.0; nen=1.0; zal=1.0,sign=1;
    for(i=1;i<1000;i+=2)
    {
        pi+=sign/i;
        sign=-sign;
    }

also nur 500 glieder!

3.1395926555897851
3.1415926535897931
12 übereinstimmungen! was ist denn da los?

[ Dieser Beitrag wurde am 30.11.2002 um 19:53 Uhr von volkard editiert. ]

The Amarin

irgendwie seltsam, gell? :p

mrchat

huhuhuu *kringel*
Jungs also da kann irgendwas net stimmen.
Aber ist doch schon Lustig was für Käfer ( bugs) so alles auftauchen können

mfg

rapso

das könnte durch die rechenungenauigkeit der fpu kommen, es ist ganz legitim, dass ab ein paar stellen die genauigkeit nicht mehr vorhanden ist, dass es mal stimmt und später nicht mehr liegt vielleicht daran dass auch andere inputwerte kommen und somit ne art rauschen vorhanden ist.

es kann ganz schlimm werden wenn man 2 rechner per netzwerk synchronisieren muss, von denen einer AMD und einer INTEL ist, dafür mußte ich dann ne eigene mathlib machen, die auf der ALU rechnet, nicht fpu.

vielleicht liegt es auch an was ganz anderem bei euch, is nur ein tip.

volkard

erst lesen, dann mitreden.
ausgabe:
3.141592 5 5358979 15
3.141592 6 5358979 31
frage ist doch nicht, warum der erste fehler bei der 7. nachkommastelle ist, sondern weshalb danach 7 korrekte stellen sind.

rapso

"erst lesen, dann mitreden" dito

es darf ein rauschen geben, das kann cpu abhängig sein. (ein bit falsch nach zig stellen ist ein kleines rauschen, genau das meinte ich!)

außerdem hab ich geschrieben, dass es vielleicht nichts mit eurem problem zu tun hat, so ne dumme anmache kann man sich sparen, wollte ja nur helfen.

rapso->greets();

... das Verfahren zyklisch arbeitet treten auch die Fehler
zyklisch auf - würde ich jetzt mal so sagen. Zudem ist Pi ne
normale Zahl (siehe Wikipedia), evtl. haben solche Zahlen ein
solches Verhalten?

Hallo

Geht doch viel einfacher: Lern' einfach 50..100 Stellen von Pi auswendig, dann
brauchst Du keinen PC oder Taschenrechner mehr, um Pi mit vernünftiger Genauigkeit zu benutzen.

14159 26535 89793 23846
26433 83279 50288 41971
...

Langeweile? Nie gehört

Grüße

Jester

Was wäre, wenn ihr die Summationsschleife rückwärts läufen laßt? Möglicherweise würden sich dann die Rechenfehler, die aus der Addition von einer großen zu einer kleinen Zahl ergeben weniger stark ausfallen.

Jester

Hm, scheint nur bedingt was zu bringen. Wenn man allerdings die Ergebnisse mal ohne die Multiplikation mit 4 anschaut sind die Abweichungen größer. Allerdings läßt sich durch Erhöhung der Schleifendurchläufe auch die Genauigkeit erhöhen.
Könnte mir vorstellen, daß das beim Rückwärtsdurchlauf etwas besser geht als vorwärts.

@rapso: Na mach dir nix draus, so ist der volki halt.

rapso schrieb:

es darf ein rauschen geben, das kann cpu abhängig sein. (ein bit falsch nach zig stellen ist ein kleines rauschen, genau das meinte ich!)

Trotzdem komisch, denn es ist nicht ein Bit. Es ist eine Zahl in der Dezimaldarstellung, und das bedeutet normalerweise viele Bits in der Binärdarstellung.

Gruß, TGGC (\-/ returns)

warum lasst ihr die toten nicht in frieden ruhen?

TGGC

Cpt. Tanga schrieb:

warum lasst ihr die toten nicht in frieden ruhen?

Warum schreibst du Sachen, die nicht zum Thema passen? f'`8k

Gruß, TGGC (\-/ returns)

Urkel_

Warum Gleitkommazahlen an Genauigkeit verlieren können
Siehe auch
Codeoptimierung
Dezimale Gleitkommawerte können im Allgemeinen binär nicht exakt dargestellt werden. Das ist ein Nebeneffekt der Darstellungsweise von Gleitkommazahlen durch die CPU. Aus diesem Grund könnte ein gewisser Genauigkeitsverlust auftreten, und manche Gleitkommaoperationen können unerwartete Ergebnisse hervorbringen.

Dieses Verhalten kann auf die folgenden Umstände zurückgeführt werden:

Die Binärdarstellung der Dezimalzahl ist möglicherweise nicht genau.
Es gibt einen Typenkonflikt zwischen den verwendeten Zahlen (z. B., wenn float und double gemischt werden).
Um das Verhalten zu korrigieren, stellen die meisten Programmierer entweder sicher, dass der Wert größer oder kleiner als benötigt ist, oder sie verwenden eine BCD (Binary Coded Decimal)-Bibliothek, durch die Genauigkeit gewährleistet wird.

Auszug aus dem MSDN

Taurin

Dann will ich mich auch mal das Thema aufwärmen:

Mit Gleitkommarechung hat das Ganze - soweit ich das Problem durchschaue - nix zu tun. In exakter Rechung (d.h. gerundet wird erst nach der Summation!) ergibt sich mit Maple:

> e(10)     := evalf(4*sum((-1)^k / (2*k + 1),k=0..10)) - evalf(Pi);
> e(100)    := evalf(4*sum((-1)^k / (2*k + 1),k=0..100)) - evalf(Pi);
> e(1000)   := evalf(4*sum((-1)^k / (2*k + 1),k=0..1000)) - evalf(Pi);
> e(10000)  := evalf(4*sum((-1)^k / (2*k + 1),k=0..10000)) - evalf(Pi);
> e(100000) := evalf(4*sum((-1)^k / (2*k + 1),k=0..100000)) - evalf(Pi);

e(10)      := 0.0907231558157994488
e(100)     := 0.0099007474811973368
e(1000)    := 0.0009990007497498124
e(10000)   := 0.0000999900007499750
e(100000)  := 0.0000099999000007500

Ich vermute jetzt einfach mal, dass wird sich so weiter fortsetzen. Warum der absolute Fehler solch eine Gestalt hat, ist mir auch ein Rätsel...