Fuer Matheliebhaber, Knobler oder BruteForce Attacken!
-
Hat Spaß gemacht. Danke.
-
Irgendwie versteh ich nicht, wie volkard und ich bei Herausforderung 4 auf 249.956,00 kommen.
Ich denke ich bin alle möglichen Codes durchgegangen und hab zwei Codes mit denen ich auf 1.87083 komme und ich hab beide eingegeben. Gibt es noch einen dritten?
-
@TGGC: Meine ersten 4 Codes bei Herausforderung 3 kannst du schon löschen. (786495687)
-
irgendwer. schrieb:
Irgendwie versteh ich nicht, wie volkard und ich bei Herausforderung 4 auf 249.956,00 kommen.
Jo, die Liste hat mich ach schwer gewundert. Irgendwie verstehe ich nicht, warum Du da so wenig hast, Du fällst da völlig aus der Reihe.
Ich schau mal...
-
irgendwer. schrieb:
Ich denke ich bin alle möglichen Codes durchgegangen und hab zwei Codes mit denen ich auf 1.87083 komme und ich hab beide eingegeben. Gibt es noch einen dritten?
Jo, es gibt drei beste. Drei?
Oha, das ist endlich(!) mal ein Fall für nearly-Vergleiche auf Fließkomma-Zahlen. Es gibt zwei Bildschirme voll damit.
-
volkard schrieb:
irgendwer. schrieb:
Ich denke ich bin alle möglichen Codes durchgegangen und hab zwei Codes mit denen ich auf 1.87083 komme und ich hab beide eingegeben. Gibt es noch einen dritten?
Jo, es gibt drei beste. Drei?
Oha, das ist endlich(!) mal ein Fall für nearly-Vergleiche auf Fließkomma-Zahlen. Es gibt zwei Bildschirme voll damit.Dummer Fehler beim Ergebnisse sammeln, man sollte nicht nur ein double als key verwenden, wenn es mehrere gleich gute gibt. Darum hatte ich nur einmal 4 und einmal 3 Brüche.
volkard schrieb:
irgendwer. schrieb:
Irgendwie versteh ich nicht, wie volkard und ich bei Herausforderung 4 auf 249.956,00 kommen.
Jo, die Liste hat mich ach schwer gewundert. Irgendwie verstehe ich nicht, warum Du da so wenig hast, Du fällst da völlig aus der Reihe.
Ich schau mal...Du meinst Herausforderung 5? Die hab ich mit GA gelöst, was aber anfangs nicht so gut funktioniert hat, vlt. weil es nicht so viele gute Ergebnisse gibt. Als ich dann beim Mutieren nachgeholfen habe und ihn öfters "gute" Zahlen und weniger zufällige auswählen habe lassen, ging es besser. Jetzt bekomme ich in ein paar Sekunden gute Ergebnisse. Testest du mit Brute-Force alles durch? Wie lange rechnet dein Programm für Aufgabe 5?
Herausforderung 3 habe ich auch mit GA gelöst, da ging es viel besser.
-
irgendwer. schrieb:
Du meinst Herausforderung 5?
Ähm, kann auch sein, ja.
irgendwer. schrieb:
Die hab ich mit GA gelöst, was aber anfangs nicht so gut funktioniert hat, vlt. weil es nicht so viele gute Ergebnisse gibt. Als ich dann beim Mutieren nachgeholfen habe und ihn öfters "gute" Zahlen und weniger zufällige auswählen habe lassen, ging es besser. Jetzt bekomme ich in ein paar Sekunden gute Ergebnisse. Testest du mit Brute-Force alles durch? Wie lange rechnet dein Programm für Aufgabe 5?
Jo, die ist lieb.
20 Minuten.
Ich probier gerade mal einen anderen Ansatz...irgendwer. schrieb:
Herausforderung 3 habe ich auch mit GA gelöst, da ging es viel besser.
Die war nicht lieb, aber bruteforcen ging gerade so noch.
-
volkard schrieb:
Ich probier gerade mal einen anderen Ansatz...
Hat ein wenig gedauert, aber bin jetzt runter auf 0.2 Sekunden für die Aufgabe5.
-
volkard schrieb:
volkard schrieb:
Ich probier gerade mal einen anderen Ansatz...
Hat ein wenig gedauert, aber bin jetzt runter auf 0.2 Sekunden für die Aufgabe5.
Bekommst du jetzt noch alle Ergebnisse oder hast du die Suche auf einen Bereich beschränkt?
-
irgendwer. schrieb:
volkard schrieb:
volkard schrieb:
Ich probier gerade mal einen anderen Ansatz...
Hat ein wenig gedauert, aber bin jetzt runter auf 0.2 Sekunden für die Aufgabe5.
Bekommst du jetzt noch alle Ergebnisse oder hast du die Suche auf einen Bereich beschränkt?
Alle werden berechnet.
Von den kleinsten Werten
284000256: 5184 54784 -> 1
284000256: 284000256 -> 0
bis zu den größtzen Werten
284000256: 8 24 24 24 24 107 -> 130
und sie werden auch feierlich ausgegeben, wenn ich alle Ausgaben anmache.Aber die Ausgabe mit nur
if(value>=120)
dauer halt für die 15 oder so Zeilen nix und dann sind es 0.2 (jetzt 0.15) Sekunden Rechenzeit.
Ich habe nur eine teure weil verdammt oft aufgerufene Division im Code, die ich gerade noch ersetzt hatte von
x=y/t
zu
if(t==2) x=y/2 else x=y/t
Das brachte dann von 0.2 die Beschleunigung auf 0.15. Weil so unglaublich oft die 2 als Teiler kömmt. Oder bei Dir als Multiplikator.
compile@localhost ~ $ factor 284000256 284000256: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 107
Alle auszugeben sind 75000 Zeilen und die dauern auf der Windows-Konsole 70s.
Die Suche wird nicht durch beschnitten kein pruning oder branch&bound anhand von bisher bekannten Bestwerten, nur die Bildschirmausgabe wird beschnitten.
Bei Aufgabe 3 lohnt sich das Beschneiden, da gehts auch (Hab's aber auch da nicht gemacht. Werde ich irgendwann mal nacholen, um eine Lösung anzustreben, die alles schnell absucht, aber nicht gerade 60G Spicher braucht). Hier wüßte ich gar nicht, wie es geht.
-
Als ich die Ergebnisse gesehen hatte, hab ich auch das Gefühl gehabt, dass da auch was mit Teilern gehen müsste, hab aber nicht mehr weiter nachgedacht. Interessant fand ich auch, dass viele gute Ergebnisse mit einer Primzahl aufhören.
-
irgendwer. schrieb:
Als ich die Ergebnisse gesehen hatte, hab ich auch das Gefühl gehabt, dass da auch was mit Teilern gehen müsste,
Nee, im Prinzip nicht. Durch die Einschränkung mit den hinteren Bits sehe ich da keine4n mathematischen Zugang.
irgendwer. schrieb:
hab aber nicht mehr weiter nachgedacht.
Warum?
irgendwer. schrieb:
Interessant fand ich auch, dass viele gute Ergebnisse mit einer Primzahl aufhören.
Meinste die Primfaktorzerlegingen?
compile@localhost ~ $ factor 284000001 284000001: 3 191 495637 compile@localhost ~ $ factor 284000002 284000002: 2 11 13 67 14821 compile@localhost ~ $ factor 284000004 284000004: 2 2 3 3 659 11971 compile@localhost ~ $ factor 284000008
Alle davon hören mit einer Primzahl auf. Da bin ich ganz ganz sicher.
Daß große Zahlen normalerweise sehr viele kleine Teiler haben aber auch ein paar sehr wenige sehr große, das ist normal.