Überflüssige Algorithmen Teil III (Programme, die die Welt nicht braucht)

[p. specht]

Hallo und Willkommen im Teil III unserer "Müllkippe für Programme".
- Der Vorgänger-Thread (Teil II) ist hier zu finden.
- Der erste Teil war glaube ich das hier.

Jedermann ist herzlich eingeladen, hier seine (XProfan-ähnlichen) Altprogramme, Versuche, Kälber mit zwei Köpfen reinzustellen. Vielleicht kann ein anderer ja was daraus lernen (z.B. wie man's NICHT macht) oder sogar einen Teil davon brauchen...

[p. specht]

Abt. Reise zum Mittelpunkt der Floatingpoint Welt
---------------------------------------------------------
Das Produkt aus den Größtmöglichen und Kleinstmöglichen Werten, die als Double Precision Floating Point Variable (8 Byte) in Normaldarstellung noch darstellbar sind (also nicht als Sonderwert 0 oder +Inf bzw. -Inf):

CLS:Font 2
print format$("%1.18e",val("-4.9406564584124654E-323")*val("+1.7976931348623157E+308"))
WaitInput

Das bedeutet auch, daß man Werte unter bzw. bis maximal 1.340780792994259635e+154 bedenkenlos miteinander multiplizieren darf, ohne einen Overflow Error mit Absturz zu risikieren. Beweis: Ändert hier unten mal die letzte Stelle von 5 auf 6

Cls:Font 2
print format$("%1.18e",val("1.340780792994259635e+154")*val("1.340780792994259635e+154"))
WaitInput

Hat man es mit einer Variablen zu tun, die größer als dieser Wert ist, muss die andere um so kleiner sein. Overflows kann man dann mit folgendem Mechanismus abfangen:

if (lg(abs(a!))+lg(abs(b!))) <= lg(abs(fmax!))
  print format$("%1,18d",a!*b!)
else
  print "Overflow abgefangen."
endif

Wie groß die anderen Zahl genau werden darf, wenn einer der beiden Faktoren schon gegeben ist, ergibt sich zu

print format$("%1,18d",10^(lg(abs(fmax!))-lg(abs(a!))))

Und folgende Zahl darf man gerade noch 3 x mit sich selbst multiplizieren: 5.6438030941223618e+102
Das Ergebnis ist aber nurmehr auf 13 Stellen genau.
Gruss

P.S.: Bei mir kommt -8.88178419700125075 * 10 ^ -15 bei der 1. Berechnung oben heraus, also im Prinzip:
-0.00000000000000888178419700125075. Die letzten 2 Stellen sind aber schon durch Rundungsfehler in der Binärabbildung der Dezimalwerte verzerrt, also gelten ohnehin nie mehr als 16 signifikante Stellen...

[p. specht]

Abt. Zufälliger Pseudo-Zufall
==================
Hier ein allererster Versuch, reproduzierbare Test-Zufallszahlen über den gesamten 64-bit IEEE FloatingPoint Bereich zu erzeugen. Ob da Gleichverteilung vorliegt (eher unwahrscheinlich) muss ich mir gelegentlich mal ansehen. Das Ganze muß (z.B. für Algorithmen-Stabilitätstests) selbstverständlich noch drastisch beschleunigt werden. Mein erster Versuch "Zwei Integerzufallszahlen in Bereich schreiben und als Float interpretieren lassen" hat sich jedenfalls nicht bewährt: Dazu gibt es zu viele "+Inf","-Inf" und "NotANumber (NAN)"-Bereiche, was zu Abstürzen führte.

WindowTitle "64bit FloatingPoint(Pseudo-)Zufallszahlen im gesamten  Darstellungsbereich"
Set("Decimals",18):Font 2:Cls Rnd(8^8)
'var fmax!=val("1.7976931348623157E+308")
'var fmin!=val("4.9406564584124654E-323")
Set("Randseed",65535)
Declare Ran!
While 1
Ran!=(1-2*Rnd(2))*(Rnd(67383496)*(10^-7)+Rnd(932747812)*(10^-16)- 3.36917479663739055)*10^(Rnd(631)-322)
Cls
print format$("%1.18e",Ran!);
WaitInput
EndWhile
End

[Jonathan]

Ich hab mal eben einen "Verteilungsprüfer" zusammengekloppt - sieht nicht gut aus. Die meisten Zahlen erscheinen im niedrigen Bereich - weiter oben kommen fast gar keine.

Declare Verteilung%[], Stelle%, Bereich!, Bereich_$
Declare Ran!
Randomize
Set("Decimals",18)
Font 2
Cls
ShowMax
Print "Bereich von 0 bis: ";
Input Bereich_$
Bereich! = Val(Bereich_$)
Cls
SetText %hwnd, "Verteilungsprüfer - Bereich von 0 bis " + Bereich_$
'var fmax!=val("1.7976931348623157E+308")
'var fmin!=val("4.9406564584124654E-323")
UsePen 0, 1, @Rgb(255, 0, 0)
Verteilung%[Width(%hwnd)] = 0
While 1
  Ran!=(1-2*Rnd(2))*(Rnd(167383496)*(10^-7)+Rnd(932747812)*(10^-16)- 3.36917479663739055)*10^((1-2*Rnd(2))*(Rnd(316)-15))
  'print format$("%1.18e",Ran!)
  If (Ran! >= 0) And (Ran! < Bereich!)
    Stelle% = Width(%hwnd) * Ran! / Bereich!
    Verteilung%[Stelle%] = Verteilung%[Stelle%] + 1
    Case Verteilung%[Stelle%] > Height(%hwnd): Verteilung%[Stelle%] = Height(%hwnd)
    Line Stelle%, Height(%hwnd) - Stelle%, (Height(%hwnd) - Verteilung%[Stelle%])
  EndIf
EndWhile
End

Gruß
Jonathan

[p. specht]

Vielen Dank für Deine Mühe - hatte ich auch bald bemerkt und die Funktion oben bereits etwas ausgebessert, gleichzeitig auch auf wiederholbare Zahlenfolgen umgestellt (Pseudo-Zufallsvariable). Das ganze geht bestimmt viel viel einfacher, bin weiter am tüfteln...

[_Joerg_]

Abt. Zufälliger Pseudo-Zufall

Hm - ich erhalte da sofort einen Absturz wegen Gleitkommaüberlauf.

[p. specht]

Jonathans Verteilungsprüfer verträgt sich irgendwie nicht mit meiner neuen Formel oben. Die klappt aber bei mir...

[Jonathan]

Deine neue Formel produziert so große Zahlen, dass If abschmiert ... Vielleicht kannst Du die Zahlen ja doch mal etwas kleiner machen...?

[p. specht]

Naja, es ging ja grad um das Ausloten der Grenzen. Bisschen zu viel gelotet, stimmt. Ursache gefunden
*auf die Stirn klatsch*: Wenn der Exponent in eine Endlage geht, kann man die Mantisse nicht mehr im vollen Zufallsbereich erzeugen, sonst kracht es irgendwann. Sorry...
Hier der nächste Versuch, diesmal mit der Absicht, symmetrisch um den Mittelwert Null zu bleiben:

Declare zuf!,n&
Set("randseed",0)
Font 2
Cls
While 1
print n&,format$("%1.18e",zuf!)+"             "
zuf!=rnd(4294967295)*10^-8+rnd(1000000000)*10^-17
zuf!=zuf!*10^(rnd(632-18)-308-19)
inc n&
case %csrlin>22:locate 1,1
EndWhile
End

[Jonathan]

Hmmmmm... Symmetrisch um Null ist es. Aber es kommen immer noch vieeel mehr Zahlen um Null, als in den höheren Bereichen. Der Verteilungsprüfer zeigt jetzt übrigens auch negative Zahlen an:

Declare Verteilung%[], Stelle%, Bereich!, Bereich_$, Col%
Declare Ran!
Randomize
Set("Decimals",18)
Font 2
Cls
ShowMax
Print "Bereich von 0 bis: ";
Input Bereich_$
Bereich! = Val(Bereich_$)
Cls
SetText %hwnd, "Verteilungsprüfer - Bereich von 0 bis " + Bereich_$
'var fmax!=val("1.7976931348623157E+308")
'var fmin!=val("4.9406564584124654E-323")
Verteilung%[Width(%hwnd)] = 0
While 1
  'Ran!=(1-2*Rnd(2))*(Rnd(67383496)*(10^-7)+Rnd(932747812)*(10^-16)- 3.36917479663739055)*10^(Rnd(631)-322)
  'Ran! = @Rnd() * Val("1E+250")
  'print format$("%1.18e",Ran!)
  Ran!=rnd(4294967295)*10^-8+rnd(1000000000)*10^-17
  Ran!=Ran!*10^(rnd(632-18)-308-19)
  
  If (Ran! > -Bereich!) And (Ran! < Bereich!)
    Col% = @Rgb(255, 0, 0)
    If Ran! < 0
      Ran! = -Ran!
      Col% = @Rgb(0, 255, 0)
    EndIf
    Stelle% = Width(%hwnd) * Ran! / Bereich!
    Verteilung%[Stelle%] = Verteilung%[Stelle%] + 1
    Case Verteilung%[Stelle%] > Height(%hwnd): Verteilung%[Stelle%] = Height(%hwnd)
    SetPixel Stelle%, (Height(%hwnd) - Verteilung%[Stelle%]), Col%
  EndIf
EndWhile
End

Rot = Positiv; Grün = Negativ.


Gruß
Jonathan

[p. specht]

Verflixt, das sind ja richtige Angstgrenzen... Nachstehend kann man die Randomfunktion selbst ändern und sich langsam an die genannten IEEE-Grenzen herantasten. Vorschlag: Die erste Million Randomzahlen sollte mal ohne Absturz funktionieren. Falls die Meldung doch kommt, bitte das Meldungsfenster (Overflow) wegziehen und die letzte gültige DURCHLAUF-Nummer merken. Da es sich um Pseudo-Primzahlen handelt, kann man so doch noch eruieren, was eigentlich schiefgelaufen ist. Wer sich näher an die genannten Grenzen rantraut und dabei mehr gültige Werte produziert, hat in dieser Kategorie dann gewonnen. Ich eröffne mal mit vorsichtigen Werten für die Kategorie "1 Mio klaglose Durchläufe":

if 0
$MAKE CL
endif
Windowtitle "Maximum Range Pseudo-Random 64bit Floats v0.4-preBeta"
Declare zuf!,n&,max!,min!,z&,fastmode&


Proc ZUF
  zuf!=rnd(4294967295)*10^-8+rnd(1000000000)*10^-17
  zuf!=zuf!*10^(rnd(612)-306)
return zuf!
EndProc



Min!=val("1.7976931348623157E+308") 'Startwert knapp unter +Inf
Set("randseed",65535)
Font 2
Cls
AppendMenubar 30,"IEEE-Min: 4.9406564584124654E-323  IEEE-Max: 1.7976931348623157E+308"

print "Für Schnellmodus 1 eingeben: ";:input fastmode&
IF fastmode&=1

WhileLoop 2147483647
  locate 4,1
  print &Loop,
  zuf!=ZUF()
  if (abs(zuf!)<min!) and (abs(zuf!)>0)
    min!=abs(zuf!)
    z&=%csrlin:locate 1,1
      print "Min bisher: "+format$("%1.18e",min!)+"   "
    locate z&,1    
  elseif zuf!>abs(max!)
    max!=abs(zuf!)
    z&=%csrlin:locate 2,1
      Print "Max bisher: "+format$("%1.18e",max!)+"   "
    locate z&,1
  endif
EndWhile


ELSE

locate 4,1  'Original
While 1
  print n&,
  print format$("%1.18e",zuf!)+"             "

  zuf!=ZUF()
  
  if (abs(zuf!)<min!) and (abs(zuf!)>0)
    min!=abs(zuf!)
    z&=%csrlin
    locate 1,1: print "Min bisher: "+format$("%1.18e",min!)+"   "
    locate z&,1
  elseif zuf!>abs(max!)
    z&=%csrlin
    max!=abs(zuf!)
    locate 2,1: Print "Max bisher: "+format$("%1.18e",max!)+"   "
    locate z&,1
  endif

  inc n&
  case %csrlin>22:locate 4,1
EndWhile


ENDIF
END

[Jonathan]

Läuft >1M mal ohne abzuschmieren:

Proc ZUF
  zuf!=rnd(4294967295)*10^-8+rnd(1000000000)*10^-17
  zuf!=zuf!*10^(rnd(627)-321)
  return zuf!
EndProc

[p. specht]

Da es sich bei e-Hochzahlen um eine "gebrochene" Darstellung handelt ("Halblogarithmisch" - Exponent funktioniert mit + wenn Mantisse mit * funktioniert), habe ich diese beiden Elemente mal getrennt auf ordentliche Verteilung geprüft. Bin nicht unzufrieden, bis auf die Verzerrung der Mantisse nach rechts zur + Seite. Die sollte nämlich auch um 0 streuen:

if 0
''$MAKE CL
endif

Window 0,0-%maxx,%maxy-56
AppendMenubar 30,"Horiz.x-Abszisse: Mantisse; Vertikal y-Ordinate: Exponent"
var xh&=Width(%hwnd)/2 : var yh&=Height(%hwnd)/2

declare x%,y%
var fmax!=val("1.7976931348623157E+308")
var fmin!=val("4.9406564584124654E-323")
set("randseed",65535)
declare zufx!,zufy!
line 0,yh& - Width(%hwnd),yh& : line xh&,0 - xh&,Height(%hwnd)
WaitInput


While 1



  zufx!=rnd(4294967295)*10^-8+rnd(1000000000)*10^-17
  'zufy!=rnd(612)-306  ' Specht (Klasse 1Mio, viel Angst)
   zufy!=rnd(627)-321  ' Jonathan (Klasse 1Mio, wagemuting)


  x%=xh&*(1+zufx!/22)
  y%=yh&*(1+zufy!/370)
'   rectangle x%-2,(y%-2) - (x%+2),y%+2
  rectangle x%-1,(y%-1) - (x%+1),y%+1

EndWhile

P.S.: Ich erlebe gerade den Unterschied zwischen "theoretisch klugscheissen" und "praktisch was zustande bringen" am eigenen Leib

[Jonathan]

Da geht noch mehr :

Proc ZUF
  zuf!=rnd(4294967295)*10^-8+rnd(1000000000)*10^-17
  zuf!=zuf!*10^(rnd(629)-322)
  return zuf!
EndProc

[p. specht]

Sorry Jonathan, beim 257206. Durchlauf oder so setzt Denormalisierung ein: Exponent wird -324.

Gradueller Underflow ist für Algorithmen noch gefährlicher als Overflow: Der wird gemeldet, Underflow leider nicht. Den kann man derzeit leider nur manuell überprüfen - darum die Angaben im Menübar. Aber derzeit bist Du noch immer Klassensieger in der Klasse 1 Mio *)
Gruss


_____
*) Bei 2.798.260 ist aber auch mit deinem ersten Ansatz Schluß: Gerade eben schnappte es auf -324. Teufelszeug, das...