neues Thema: Primfaktorzerlegung bricht mit exitcode 201 ab

[pyromane]

Hoi,
ich schreib grade eine "Algorithmen" Bibliothek, mit einer grafischen Benutzeroberfläche.
Ich hab schon die Berechnung des ggTs von 2 Zahlen über den Euklid'schen Algorithmus und die darauf basierende Berechnung des kgVs.
Jetzt schreib ich mehrere Verfahren zur Berechnung von Pi.
-> 1. Monte-Carlo-Verfahren.
Ich berechne dieses folgendermaßen:

Delphi-Quellcode:

function pi_montecarlo(n : int64):double;       {Ermittlung von Pi mit der Monte Carlo Methode}
var
x,sy:double;
i: int64;
begin

sy:=0;
  for i:= 0 to n-1 do
    begin
      x:=Random;
      sy:=sy+sqrt(1-sqr(x));
    end;
  result:=(4*sy/n);

end;

und geb Pi mit

Delphi-Quellcode:

label5.caption:=floattostr(pi_montecarlo(n));

aus...
Warum bekomm ich dann immer Ungültige Gleitkommaoperation??
Unter Turbo Pascal funktioniert dieselbe Formel einwandfrei!

Delphi-Quellcode:

program MonteCarloRechteck;
uses crt;
var
  x: double;                    { Koordinaten }
  i,n: Longint;
  sy: double;                   { Summe der Fkt-Werte }          { Anzahl der Druchläufe }
begin
clrscr;
writeln('n : ');
readln(n);
  Randomize;
  sy := 0;
  for i := 0 to n-1 do begin
    x := Random;
    sy := sy + sqrt(1-sqr(x))   { y ausrechnen und addieren zu sy }
  end;
  WriteLn(4*sy/n);              { ueber Flaecheninhalt in pi umrechnen }

Readln;
end.

mfg Pyromane


//Edit: es scheint, dass n immer 0 ist, da nach der Abfrage

Delphi-Quellcode:

if n=0 then result:=0
else result:=4*sy/n
immer 0 zur+ckgegeben wird. Das Erklärt auch die Ungültige Gleitkommaoperation (
Division durch 0)^^

[Fussball-Robby]

Das dürfte so eigentlich garnicht funktionieren, da eine Schleifen-Variable von ordinalem Typ sein muss, und Int64 ist kein solcher.

In welcher zeile tritt der Fehler denn auf?

Mfg

[Klaus01]

Zitat:

Zitat von Fussball-Robby

Das dürfte so eigentlich garnicht funktionieren, da eine Schleifen-Variable von ordinalem Typ sein muss, und Int64 ist kein solcher.

Mfg

Warum ist int64 denn kein Ordinaler Wert?
Int64 ist doch ganz klar auf- und auch abzählbar.

Grüße
Klaus

[pyromane]

jop das mit dem int hab ich schon wieder auf Longint gestellt. Das hatte ich nur live verändert.
Es geht um die Div durch 0 ;)

LOOL ...
ich hab Das zuweisen der Var n vergessen sry ;)

//Edit:das coole isr nur, dass das Ergebnis Variert, da Es auf Zufallszahlen basiert.
//Edit2: Weis einer, wie ich trotzdem größere Zahlwerte benutzen kann?
Ich mein.. die heutigen Rechner rechnen ja schon die Volle IntegerZahl viel zu schnell aus...
Int64 geht nicht, und Double kann ich ja net als Zählvariable benutzen. würde folgendes funktionieren:

Delphi-Quellcode:

var i, n:double
i:=0;

repeat 
 i:=i+0,1;
 {Anweisung}
until i=n;

??? So könnte man ja durch verschieben des Kommas die Zählvariable immer vergrößern.

[Matze]

Zitat:

Zitat von Klaus01

Warum ist int64 denn kein Ordinaler Wert?
Int64 ist doch ganz klar auf- und auch abzählbar.

Sollte man meinen. :gruebel:

Zitat:

[Pascal Fehler] Unit1.pas(34): E2032 FOR-Schleifenvariable muss von ordinalem Typ sein

Edit: Ah, wieder was gelernt: INT64 nicht ordinal?

[pyromane]

mkay
also das mit +0.1 scheint net zu gehen:(
er hat so 90% auslastung, es kommt aba niy bei raus...

[Klaus01]

..reicht Dir LongWord als großer Zahlenraum.
Longword 0..4294967295 unsigned 32-bit

Delphi-Quellcode:

function pi_montecarlo(n : LongWord):double;       {Ermittlung von Pi mit der Monte Carlo Methode}
var
x,sy:double;
i: LongWord;
begin

sy:=0;
  for i:= 0 to n-1 do
    begin
      x:=Random;
      sy:=sy+sqrt(1-sqr(x));
    end;
  result:=(4*sy/n);

end;

Grüße
Klaus

[Matze]

Wenn die Auslastung 90% beträgt, dann rechnet dein Rechner sicher noch. Hast du lange genug gewartet?

Ich habe bei deinem ursprünglichen Algorithmus spaßeshalber mal 5000000 (5 Millionen) als n eingegeben und da rechnete mein Laptop einige Zeit. Ich möchte gar nicht wissen wie lange das bei einem Integer, der auch bis über 2 Milliarden reicht, dauert.
Für die Repeat-Schleife könntest du auch Int64 nutzen ohne Umweg über einen Double.

[pyromane]

ne ich meinte, dass diese ungewöhnliche hohe Auslastung zustanden kam, als ich von i:=0 n:=10 To n-2 in 0.1er Schritten vorangin... (10-1)/0.1=90.... 90Durchgänge können nicht so lange dauern.!

[Matze]

Ah, das meinst du.

Man sollte Gleitkommazahlen nie direkt vergleichen, da intern immer Ungenauigkeiten auftreten können. So könnte intern beispielsweise der Wert 0.1 den Wert 0.099999999999999 haben (nur zur Veranschaulichung, tatsächlich wird dieser vermutlich anders aussehen). Das Problem hat man übrigens nicht nur bei Delphi.
Es kann daher sein, dass du eine Endlosschleife programmiert hast. Versuche mal, die beiden Double-Werte mit dieser Funktion zu vergleichen:

Delphi-Quellcode:

// ...
until VglDouble(i, n);

Grüße, Matze