Besseres Random() - eure Vorschläge

[Codehunter]

Zitat:

Zitat von Sherlock (Beitrag 1452332)

Zitat:

Zitat von DieDolly (Beitrag 1452057)

Zitat:

Man kann Grafiken auch verkleinern.

Das ist eine ziemlich schlechte Idee bei Grafiken, bei denen es aufs Detail ankommt.

Besser als nix zu sehen... Und manchmal reicht es auch ein anderes Format zu wählen.

Das seh ich aber ganz anders. DieDolly hat das eigentlich völlig richtig gemacht. Erst als BMP erzeugt und dann als PNG umgewandelt. GIF wäre IMHO auch gegangen oder TIFF. Wobei keines davon einen wesentlichen Unterschied in der Dateigröße hätte bewirken können. Schließlich ging es ja absichtlich um Random Noise und der lässt sich für gewöhnlich nicht komprimieren. Man könnte auch sagen: Je geringer das Kompressionsverhältnis zwischen BMP und PNG, umso besser war der Random-Algo ^^

Dass es bei den hier verlinkten Bildern JPEG-Artefakte gibt deutet darauf hin, dass irgendwo, ob gewollt oder nicht, eine doppelte Konvertierung vorgenommen wurde. Wenn man ein Noise-PNG hochlädt, dieses dann erst in JPEG-Pixelpampe umgewandelt und dann wieder in PNG zurück konvertiert wird, dann ist das PNG hinterher tatsächlich kleiner als vorher. Nur ist die Aussagekraft im vorliegenden Fall fast Null. Das gleiche würde zutreffen, wenn man ein Bild in der Größe verändert: Pixelpampe.

Was mir beim Betrachten des Random-DEC-Bildes auffällt: Zumindest macht es in der zermatschten JPG-Darstellung den Eindruck als hätte der Algo einen hohen 0-Anteil. Es kommen jedenfalls wesentlich mehr dunkle Pixel (= niedrige Int-Werte) vor als bei den anderen. Ob die nun tatsächlich schwarz (= 0) oder nur sehr dunkel waren, kann man wegen der Pixelpampe nicht mehr beurteilen.

[DieDolly]

Hier noch einmal alles in Originalgröße und völlig unkomprimiert als BMP im Archiv. Es ist leider eine Sache der Unmöglichkeit diese Bilder auf img42.com hochzuladen.
Dort kann man angeblich Bilder unkomprimiert hochladen aber immer wenn ich ein 4MB-Bild dort hochlade, ist die Seite kurz darauf offline!
Hier im Forum kann ich gerade auch nichts hochladen. Deswegen so...

Teil 1 des Archivs
https://cdn.discordapp.com/attachmen.../Random.7z.001

Teil 2 des Archivs
https://cdn.discordapp.com/attachmen.../Random.7z.002

[Rollo62]

Delphi-Quellcode:

bmp.Canvas.Pixels[x, y] := RandomLong; // Aufrufen was man braucht ..

Ich frage mich wie man das optisch interpretieren sollte.
Auf den ersten Blick würde ich Erwarten das es grau wird (als Mittelwert aller Farben),
das manche Bilder eher weiss, manche eher schwarz wirken finde ich schonmal seltsam.

Das man da keinerlei Muster erkennen sollte ist auch klar.

Vielleicht macht es Sinn aus den Pixeln die Helligkeitswerte o.ä. zu berechnen,
um dann den "Grauwert" zu bekommen, der sollte ja eigentlich wirklich in der Mitte liegen.
(Weder hell noch dunkel).

Oder sehe ich das falsch (Zugegeben, ich bin jetzt kein Statistikbild-Experte) ?

[Codehunter]

Naja, es spielt ja auch der Faktor subjektive Wahrnehmung mit rein. Unser Hirn sucht automatisch nach Mustern und sieht auch welche wo keine sind.

Da ein Farbpixel aus wenigstens 3 Byte besteht, müsste demnach ein gutes Zufallsmuster nach dem hier verwendeten Mechanismus aus vielen bunten und unterschiedlich hellen Pixeln bestehen. Je einheitlicher die Helligkeitswerte (Grauwerte) würden, umso weniger zufällig wären die Zahlen.

[jobo]

Zitat:

Zitat von DieDolly (Beitrag 1452339)

Hier noch einmal alles in Originalgröße ...

Also ich könnte nicht behaupten, dass mein Monitor dafür geeignet ist, aber bei WELL sehe ich Wellen.

Das entspricht auch meiner Wahrnehmung, wenn ich bei Siedler immer verliere, die Würfel liefern kein Rauschen, sondern lassen mich gnadenlos im Wellental absaufen.
;)

[DieDolly]

Well basiert bein der Initialisierung auf dem Standard-Random. Von daher ist alles was folgt "wellig".

[Rollo62]

Zitat:

Zitat von Codehunter (Beitrag 1452368)

Naja, es spielt ja auch der Faktor subjektive Wahrnehmung mit rein. Unser Hirn sucht automatisch nach Mustern und sieht auch welche wo keine sind.

Da ein Farbpixel aus wenigstens 3 Byte besteht, müsste demnach ein gutes Zufallsmuster nach dem hier verwendeten Mechanismus aus vielen bunten und unterschiedlich hellen Pixeln bestehen. Je einheitlicher die Helligkeitswerte (Grauwerte) würden, umso weniger zufällig wären die Zahlen.

Ja, ich meinte ja auch zusätzlich die Helligkeitsverteilung, nicht statt der Farbe:
1. Farbe: gut zum Suchen nach Mustern
2. Grau : gut zum checken ob es gleichmäßiges Rauschen um eine mittlere Helligkeit ist

Zu 2. meine ich, wenn man dann über alle Pixel eine Statistik bildet müsste der Mittelwert bei exakt 127 liegen, und die Verteilung möglichst gleichmäßig.
Es wäre aber die Frage ob ein Random eines LongInt auch ein Random seiner einzelnen Bytes erzeugt (davon gehe ich mal gefühlsmäßig aus),
kenne die tiefere Methematik aber nicht.

[Luckie]

Dolly: "Random-DEC und Random-MT19937 schneiden am besten ab."
Sherlock: "Es geht um die Gleichmäßigkeit des Rauschens. Je weniger Form darin zu erkennen ist, desto zufälliger soll der Algorithmus sein."

Also gerade bei den beiden sehe ich auffällige Muster. Zumindest hier auf dem Tablet.

[Sherlock]

Zitat:

Zitat von Luckie (Beitrag 1452382)

Dolly: "Random-DEC und Random-MT19937 schneiden am besten ab."
Sherlock: "Es geht um die Gleichmäßigkeit des Rauschens. Je weniger Form darin zu erkennen ist, desto zufälliger soll der Algorithmus sein."

Also gerade bei den beiden sehe ich auffällige Muster. Zumindest hier auf dem Tablet.

Das ist nur meine Interpretation der ganze Geschichte hier...ich tendiere nur dazu, jeden Blödsinn, den ich von mir gebe mit reichlich Autorität zu unterlegen, darum glaubt man mir. Dennoch fände ich ein Balkendiagramm verständlicher. Gauss hat für seine Glockenkurve auch nicht Punkte auf einem Blatt Papier verteilt, sondern eben Häufigkeiten in ein geeignetes Koordinatensystem eingetragen. Und da kann man Häufungen auf den ersten Blick erkennen.

Sherlock

[Michael II]

Irgendwelche erkennbare Muster in den Bildern deuten daraufhin, dass der Pseudo-Zufallsgenerator eher P als Z ist ;-). Umgekehrt bedeuten Bilder ohne erkennbare Muster nicht unbedingt, dass der Generator gut ist.

Man muss die Bilder unkomprimiert betrachten. Aber auch unkomprimiert ergeben sich bei Dollys "Experiment" Muster beim Delpi Generator.

Auf HD Monitoren (oder schlechter und generell) sollte man beachten, dass die Bilder "in Originalgrösse" betrachtet werden. Werden die Bilder vom Anzeigeprogramm skaliert entstehen Muster, welche im Originalbild nicht vorhanden sind.

Für Tests mit dem Delphi Generator empfehle ich dir einen Initialwert randseed := ... zu setzen, dann werden - wenn andere experimentieren - die gleichen Zahlenfolgen erzeugt.

Wenn man den in asm geschriebenen Delphigenerator (Delphi 10.3.3) betrachtet, dann ist es nicht erstaunlich, dass die erzeugten Zahlen weit weg von "echtem Zufall" sind (hier asm Code in Delphi umgesetzt):

Delphi-Quellcode:

function ra( arange : integer ): integer;
(*
        PUSH    EAX
        IMUL    EAX,RandSeed,08088405H
        INC     EAX
        MOV     RandSeed,EAX
        POP     EDX
        MUL     EDX
        MOV     EAX,EDX
        *)
var eax, edx : cardinal;
    edxeax : Uint64;
begin
  eax := randseed * 134775813; // 3*17*131*20173
  inc( eax );
  randseed := eax;
  edxeax := arange*eax;
  edx := edxeax shr 32;
  Result := edx;
end;

Du erreichst u.U. eine bessere Verteilung, wenn du den Generator statt einmal eine grosse Zahl drei mal Zahlen in einem kleineren Intervall erzeugen lässt, zum Beispiel im Intervall [0,256[ (dabei spielt die Rechengenauigkeit des Generators eine wesentliche Rolle):

Delphi-Quellcode:

  hb := TBitMap.Create;
 try
  hb.SetSize( 1024,1024 );
  hb.PixelFormat := pf32bit;

  for x := 0 to hb.Width-1 do
    for y  := 0 to hb.Height-1 do
      begin
        hb.Canvas.Pixels[x,y] := RGB(random(256),random(256),random(256)); // statt random( $1000000 );
      end;

  hb.SaveToFile( 'C:\Users\micha\Desktop\bm2.bmp' );
 finally
  hb.Free;
 end;

Wenn du die Qualität eines P Zufallgenerators testen willst, reichen diese Bilder natürlich nicht.