Matroids Matheplanet Forum Index
Moderiert von viertel
Matroids Matheplanet Forum Index » Rätsel und Knobeleien (Knobelecke) » * Das kaputte (¼) Osterei
Thema eröffnet 2020-04-01 10:31 von viertel
Seite 4   [1 2 3 4 5 6]   6 Seiten
Autor
Kein bestimmter Bereich * Das kaputte (¼) Osterei
Ixx
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 05.04.2020
Mitteilungen: 340
  Beitrag No.120, eingetragen 2020-04-25

\quoteon(2020-04-25 10:42 - hyperG in Beitrag No. 118) Hört sich zunächst alles super an, aber der Code lief zunächst nicht. Die Klammer nach dem if (list[0]+list[2*n]==list[3*n-1]) konnte ich ja dann korrigieren [ -> { \quoteoff Ah, danke für den Hinweis! :) Da war ich beim Code-Abschreiben doch schon etwas müde... ;-) Ich korrigiere es oben. [Die Antwort wurde nach Beitrag No.118 begonnen.]


   Profil
Dies ist eine Knobelaufgabe!
Der Themensteller hat bestimmt, dass Du Lösungen oder Beiträge zur Lösung direkt im Forum posten darfst.
Bei dieser Aufgabe kann ein öffentlicher Austausch über Lösungen, Lösungswege und Ansätze erfolgen. Hier musst Du keine private Nachricht schreiben!
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.121, eingetragen 2020-04-25

Die 28 s kamen mir noch zu langsam vor (selbst für den Core 2) & so habe ich mein 14 Jahre altes Vista Notebook aus dem Keller geholt & zum Laufen gebracht. Mit Win32 & zig DLLs habe ich dann die winzige exe zum Laufen bekommen und bei exe 12 nur 20,7 statt 28 s benötigt: \sourceon nameDerSprache Startparameter | exe 13 10 20 30 | exe 12 | exe 13 |16 1 2 3 exe \ CPU; Zeit in s | ? | i7 | i9 | i9 |i7 |Aldi | IxxNB |Vista| Aldi | i9 |i9 |Aldi ------------------------+--------+-------+-------+------+----+-----+-------+-----+------+------------+-----+---- Borland CB6 / MingW-w64 | 35 | 18 | 16 | 29 | 33 | | | | | | | DreierPartitionen32 | | 20,49 | 17,3 | | | | | | | | | DreierPartitionen | | 17,42 | 14,5 | | | | 5 min| | |4,88 min | |71,4 min Ixx+hyperG | | 16,18 | 13,47 | | | 60 s| | | | | | Ixx+hyperG+SumAVX | | | 12,7 |22.9 | | | | | | | | IxxRekuSum + hyperG-Opt | | 10,6 | 9,82 |17.5 | 19 | | | | |3,46 min | | n2 | | 11 | 9,6 |17,3 | 20 | | | | 316 |204s=3,4 min|43min| IxxRekuSum per MingWw64 | | 12 | 12 |23 | 23 | | 55 s| | | | IxxRekuSum + Vorfiltern3| | | 5,0 |8,44 | | | 28 s| | |94,8s=1,5min| IxxRekuSum+VorfilternW32| | | 6,59 |10,14 | | | | 20,7| | \sourceoff BIOS, Betriebssystem, Compiler & meine restlichen Optimierungen in Summe sollen so viel ausmachen... [Die Antwort wurde nach Beitrag No.118 begonnen.]


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.122, eingetragen 2020-04-25

So, die n2 Version braucht bei 17 1 6 7 12866587574 hyperG statt 15 h n2 nur noch 12,39 h (selbe Ergebnis). Mit der letzten Optimierung sind 6 h drin!


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.123, eingetragen 2020-04-25

Bei 16 & 17 ist noch ein Problem: nicht mal die ersten 3 Zeilen kommen, egal ob ich 16 1 2 3 17 1 2 3 17 1 6 7 starte.. Nicht dass da ein Überlauf mit _int16 passiert... 13 geht und auch 13 10 20 30 geht, aber 13 1 2 3 geht nicht?


   Profil
Ixx
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 05.04.2020
Mitteilungen: 340
  Beitrag No.124, eingetragen 2020-04-25

\quoteon(2020-04-25 11:45 - Kitaktus in Beitrag No. 119) Es gibt (insbesondere durch Ixxs Ausführungen ist das nochmal deutlich geworden) Situationen, in denen man schon weiß, dass von den verbleibenden 3k Zahlen die oberen k Zahlen genau die Zahlen sind, die als Summe in den Tripeln auftreten. Wenn dieser Fall einmal eingetreten ist, wird sich das auch nicht mehr ändern, wenn man tiefer in die Rekursion hinabsteigt. Wenn man schon sicher _weiß_, dass die oberen k Zahlen genau der Summe der unteren 2k Zahlen entspricht, dann kann man einige Schritte weglassen. Man muss diese Summen nicht mehr berechnen, man muss keine Fallunterscheidungen nach dieser Summe mehr ausführen und man muss nur noch Konstellationen berücksichtigen, bei denen die beiden Summanden zu den ersten 2k Zahlen gehören und die Summe zu den größten k Zahlen. Die Idee ist, in diesem Fall nur noch eine abgespeckte Variante der Rekursion aufzurufen, die schneller ist, als die "volle" Variante. Vermutlich wird durch die Idee von Ixx schon eine Menge des Verbesserungspotentials gehoben, aber vielleicht lässt sich noch ein bisschen was rausholen. \quoteoff Hm, ich habe das mal mit einem zusätzlichen Schalter in der search-Funktion versucht umzusetzen: aus: alles wie gehabt; ein: nur die angesprochene reduzierte Variante ohne Summenberechnung und Fallunterscheidungen. Allerdings bin ich dabei wieder mit einer deutlich längeren Laufzeit herausgekommen... Hier möge doch bitte auch jemand anderes mal das Vorgehen prüfen und schauen, ob bei der eigenen Variante sich hier noch Geschwindigkeitspotential herausholen lässt. Wobei die Prüfung, ob der reduzierte Fall vorliegt, ja auch in der heute Nacht publizierten Version schon immer wieder direkt auch in der nächsten Rekursionsebene anschlägt: Ist nämlich list[0]+list[2n] >= list[3n-1] und im Gleichheitsfall dieses "Sonder-Tripel" schon betrachtet, dann wird als nächstes ein Tripel list[0]+list[j]=list[k] mit $1\leq j \leq 2n-1$ und $2n\leq k \leq 3n-1$ ausgewählt, bei dem zwei Zahlen aus den kleineren zwei Dritteln und eine aus dem oberen Drittel sind. Also ist für $k>2n$ der derzeitige Wert list[2n] auch in der nächsten Rekursionstiefe der kleinste Wert des oberen Drittels, sodass nun auf jeden Fall list[1]+list[2n] > list[3n-1] gilt, man also direkt im "reduzierten Fall" landet. (Ist $k=2n$, so ist nun das alte list[2n+1] das neue kleinste Element des oberen Drittels und die Aussage gilt analog.) [Die Antwort wurde nach Beitrag No.121 begonnen.]


   Profil
Ixx
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 05.04.2020
Mitteilungen: 340
  Beitrag No.125, eingetragen 2020-04-25

\quoteon(2020-04-25 12:47 - hyperG in Beitrag No. 123) Bei 16 & 17 ist noch ein Problem: nicht mal die ersten 3 Zeilen kommen, egal ob ich 16 1 2 3 17 1 2 3 17 1 6 7 starte.. Nicht dass da ein Überlauf mit _int16 passiert... 13 geht und auch 13 10 20 30 geht, aber 13 1 2 3 geht nicht? \quoteoff Dann ist da wahrscheinlich ein Bug in der Berechnung von sum2 in der main-Funktion. Ich habe den entsprechenden Code-Schnipsel \sourceon C if (c <= 2*N-1) { sum2 -= 2*N; } else if (b <= 2*N-1) { sum2 -= c; } else if (a <= 2*N-2) { sum2 -= c+b-(2*N-1); } else { sum2 -= c+b+a-(2*N-1)-(2*N-2); } \sourceoff gerade mal durch die langsamere, was aber für die Laufzeit völlig egal ist, aber einfachere Version \sourceon C sum2 =0; for (int i=2*(N-1); i<3*(N-1); i++) { sum2 += list[i]; } \sourceoff ersetzt, und bekomme Lösungen angezeigt. Wo der Fehler steckt, sehe ich aber gerade nicht.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.126, eingetragen 2020-04-25

OK -> DreierPartIxxRekuSum.exe 17 1 20 21 funktioniert nun mit der for() Summierung für sum2. Gut, dass ich immer erst teste, denn bisher waren oft noch Fehler, die ich nicht nach 13 h erst sehen möchte. Allerdings war diese sum2 Berechnung ja auch schon in der SumReku n2 Version -> dort hat aber alles scheinbar funktioniert. Ich hoffe, dass es keine Fehler, sondern nur Optimierungseinflüsse sind, die durch die fehlerhafte sum2 entstehen. Sonst müsste ich alle 17 1 7 8 ... 17 1 14 15 neu berechnen...


   Profil
Ixx
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 05.04.2020
Mitteilungen: 340
  Beitrag No.127, eingetragen 2020-04-25

Ah, ich sehe, was der Fehler war! Ich hatte die Formel für sum2 (genauer: die Berechnung von sum2 nach Elimination eines Tripels) aus der in der search-Funktion abgeschrieben. Dabei habe ich aber nicht bedacht, dass dort mit Indizes im Bereich [0; 3n-1] gearbeitet wird, während hier natürliche Zahlen im Bereich [1; 3N] verwendet werden. Also ein klassischer "off by 1"-Fehler... Das bedeutet: Im ersten Fall, wenn c in den ersten zwei Dritteln liegt, muss vom zuvor ermittelten Wert sum2 aller Zahlen im Intervall [2N+1; 3N], also sum2 = N*(2N+1 + 3N)/2, nun das bisher kleinste Element des obersten Drittels abgezogen werden, nämlich 2N+1; und nicht, wie in der Fallunterscheidung steht, 2N. Demzufolge war in der bisherigen Version, wenn $c<2N$ war, der Wert sum2 um 1 zu groß. Was bedeutet, dass es bei den Prüfungen auf Gleichheit sum == 2*sum2 zu Fehlern gekommen sein kann... Jedoch hat die Sache eine positive Seite: Der "richtige" Wert von sum2 ist kleiner, sodass die Abbruchbedingung sum > 2*sum2 eher erreicht wird. Sorry für den Fehler!


   Profil
Ixx
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 05.04.2020
Mitteilungen: 340
  Beitrag No.128, eingetragen 2020-04-25

btw: Kannst du noch mal eine von dir optimierte und compilierte Anwendung hochladen? Dann würde ich hier auch mal noch nen anderen Rechner anschmeißen und schauen, wie es da läuft...


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.129, eingetragen 2020-04-25

Du brauchst Dich nicht entschuldigen! Ich hätte ewig gebraucht, da ich ihn nicht in der Initialisierung der sum2 in der main gesucht hätte! Das Unglaubliche, was sich schon im Beitrag 118 andeutete: Der Geschwindigkeitszuwachs nimmt weiter zu!!! \sourceon nameDerSprache Startparameter | exe 13 10 20 30 | exe 12 | exe 13 |16 1 2 3 exe \ CPU; Zeit in s | ? | i7 | i9 | i9 |i7 |Aldi | IxxNB |Vista| Aldi | i9 |i9 |Aldi ------------------------+--------+-------+-------+------+----+-----+-------+-----+------+------------+-------+---- Borland CB6 / MingW-w64 | 35 | 18 | 16 | 29 | 33 | | | | | | | DreierPartitionen32 | | 20,49 | 17,3 | | | | | | | | | DreierPartitionen | | 17,42 | 14,5 | | | | 5 min| | |4,88 min | |71,4 min Ixx+hyperG | | 16,18 | 13,47 | | | 60 s| | | | | | Ixx+hyperG+SumAVX | | | 12,7 |22.9 | | | | | | | | IxxRekuSum + hyperG-Opt | | 10,6 | 9,82 |17.5 | 19 | | | | |3,46 min | | n2 | | 11 | 9,6 |17,3 | 20 | | | | 316 |204s=3,4 min|43min | IxxRekuSum per MingWw64 | | 12 | 12 |23 | 23 | | 55 s| | | | | IxxRekuSum + Vorfiltern3| | | 5,0 |8,44 | | | 28 s| | |94,8s=1,5min|9,55min| IxxRekuSum+VorfilternW32| | | 6,59 |10,14 | | | | 20,7| | \sourceoff \sourceon nameDerSprache Parameter| Faktor n3/n2 ---------+------------- 12 | 2,05 13 | 2,15 16 1 2 3 | 4,5 \sourceoff [Die Antwort wurde nach Beitrag No.127 begonnen.]


   Profil
viertel
Senior Letzter Besuch: im letzten Quartal
Dabei seit: 04.03.2003
Mitteilungen: 27785
Wohnort: Hessen
  Beitrag No.130, vom Themenstarter, eingetragen 2020-04-25

Ihr seid echt unglaublich 😲 Mein eigenes Programm braucht Ewigkeiten für 12 (von 13 gar nicht zu reden), und ihr seid im Bereich weit unter einer Minute! Schön, daß euch mein harmlos anmutendes Rätsel so viel Spaß macht. Und ein regelrechtes Rekord-Fieber entfacht hat (besser als ein Corona-Fieber😷) 👍


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.131, eingetragen 2020-04-25

Hier die beiden EXE: x64N3_x32.zip die x32 war nur heute früh zum Testen am alten Notebook & hat noch den Sum2 Fehler. (benötigt noch zig DLLs) Die DreierPartIxxRekuSumN3i9.exe - hat die neue N3-Vorfilter Funktion & meine Optimierungen - die 2 nötigen DLLs findet man in den beiden ZIP von mir zuvor - der sum2 Fehler sollte raus sein Man das macht ja richtig Spaß, wenn jeder was beisteuert & das Endprodukt dadurch immer besser wird! Schönes Beispiel was Menschen erreichen können, wenn alle an einem Strang ziehen & jeder seine Stärken einbringt! [Die Antwort wurde nach Beitrag No.129 begonnen.]


   Profil
StrgAltEntf
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 19.01.2013
Mitteilungen: 8028
Wohnort: Milchstraße
  Beitrag No.132, eingetragen 2020-04-25

Hallo, ich habe jetzt auch mal Ixx' neue Ideen und auch die Idee von Kitaktus' umgesetzt. Die Ergebnisse sind phänomenal! \quoteon(2020-04-25 12:52 - Ixx in Beitrag No. 124) Hm, ich habe das mal mit einem zusätzlichen Schalter in der search-Funktion versucht umzusetzen: aus: alles wie gehabt; ein: nur die angesprochene reduzierte Variante ohne Summenberechnung und Fallunterscheidungen. Allerdings bin ich dabei wieder mit einer deutlich längeren Laufzeit herausgekommen... Hier möge doch bitte auch jemand anderes mal das Vorgehen prüfen und schauen, ob bei der eigenen Variante sich hier noch Geschwindigkeitspotential herausholen lässt. \quoteoff Ich habe eine Funktion search2 geschrieben, die keine Summenprüfung macht und dementsprechend auch keine Summen als Parameter hat. In search2 wird davon ausgegangen, dass die letzten n/3 Glieder Summen der ersten 2/3 Glieder sind. Das hat mir noch mal 1/3 (!) Gesamtlaufzeit eingespart. \showon search2 \sourceon C void search2(int list[3*Nmax], int n){ int newlist[3*Nmax]; int j, k; if(n == 0){ solutioncounter++; // BINGO! Valid partition found printsolution(); if(builtintest()){ // for paranoids ... may be omitted printsolution(); printf("Fatal error in program!\n"); exit(0); } return; } if(list[0] + list[2*n-1] > list[3*n-1]) return; if(list[0] + list[2*n-1] == list[3*n-1]){ reduce(list, newlist, 2*n-1, 3*n-1, n); // delete triple from list solution[n-1][0] = list[0]; solution[n-1][1] = list[2*n-1]; solution[n-1][2] = list[3*n-1]; search2(newlist, n-1); return; } // searching for triplets (list[0] list[j] list[k]) for(j=1, k=2*n; j<2*n; j++){ for( ; k<3*n; k++){ if(list[0] + list[j] == list[k]){ // new triple found reduce(list, newlist, j, k, n); // delete triple from list solution[n-1][0] = list[0]; // add triple to solution solution[n-1][1] = list[j]; solution[n-1][2] = list[k]; search2(newlist, n-1); // search shortened list k++; break; // next j } if(list[0] + list[j] < list[k]) // for this (j, k) and greater k break; // no solution is possible -> next j } } } \sourceoff \showoff [Die Antwort wurde nach Beitrag No.129 begonnen.]


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.133, eingetragen 2020-04-25

Hallo viertel, wie hast Du das Bild hinter "Ihr seid echt unglaublich" mit Unterscheidung des Betriebssystems (oder Chrome-Version) hinbekommen? Unter Win7 ist es SW https://matheplanet.com/matheplanet/nuke/html/uploads/b/47407_SmilyFarbe.PNG und unter Win10 in Farbe?! https://matheplanet.com/matheplanet/nuke/html/uploads/b/47407_SmilyWin10Farbe.PNG Ein "normales" Bild kann es ja nicht sein... Hallo StrgAltEntf, hast Du den nichtlinearen Geschwindigkeitszuwachs gesehen? Für 16 1 2 3 wo Du noch 71,4 min brauchtest, sind wir nun unter 10 min Faktor 7,5 !! Wenn das so weiter wächst geht der bis 9 hoch und nach ein paar Stunden könnte ich 17 Stück schaffen -> also pro Tag 2 Runs macht 34/Tag!!!


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.134, eingetragen 2020-04-25

Ergebnisse sammle ich im bereits angefangenen Beitrag 111 : hier Ergebnisse Bitte Abstand 17 lassen, da ich "echt parallel" bis zu 17 exe Starte.


   Profil
viertel
Senior Letzter Besuch: im letzten Quartal
Dabei seit: 04.03.2003
Mitteilungen: 27785
Wohnort: Hessen
  Beitrag No.135, vom Themenstarter, eingetragen 2020-04-25

\quoteon(2020-04-25 14:56 - hyperG in Beitrag No. 133) Hallo viertel, wie hast Du das Bild hinter "Ihr seid echt unglaublich" mit Unterscheidung des Betriebssystems (oder Chrome-Version) hinbekommen? Unter Win7 ist es SW https://matheplanet.com/matheplanet/nuke/html/uploads/b/47407_SmilyFarbe.PNG und unter Win10 in Farbe?! https://matheplanet.com/matheplanet/nuke/html/uploads/b/47407_SmilyWin10Farbe.PNG Ein "normales" Bild kann es ja nicht sein... \quoteoff Es ist auch kein Bild, sondern ein Unicode-Zeichen. Und wie das jeweils dargestellt wird hängt vom Gerät (PC, Smartphone, Tablet und Betriebssystem) ab. Der einzige „Trick“ ist die Vergrößerung mittels CSS (font-size:250%;).


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.136, eingetragen 2020-04-25

Ahh, es liegt an Schriftart & Browser zusammen: hier Tabelle Die Schriftart allein reicht auch nicht, da fast alle Schriftarten dieses Unicode-Zeichen (2 Byte) unter Win7 nur als Rechteck zeigen! Erst der Browser entscheidet über endgültiges Aussehen. 🙉


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.137, eingetragen 2020-04-25

So, nach 7,4 h erster 17er mit neuster Version -> also etwa 3 mal schneller (Faktor 4,5 war leider Sonderfall).


   Profil
Ixx
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 05.04.2020
Mitteilungen: 340
  Beitrag No.138, eingetragen 2020-04-26

Mal ne Überlegung zum Umfang dieser Rechnerei: Gehen wir mal aus, dass die durchschnittliche Laufzeit für jedes 17er-Anfangstripel 1 n n+1 ca. 10 Kern-Stunden beträgt (die aktuelle Verbesserung bringt mehr, wenn viele kleine Zahlen zu Beginn schon weg sind, also am meisten bei 1 2 3), dann landen wir bei einem Gesamtaufwand von ca. 500 Kern-Stunden, wobei sich das auf seine schnelle Hardware bezieht. Ggf. sind es auch 1000 Kern-Stunden. Das erscheint mir noch machbar. Blicken wir mal weiter hinaus: Der nächste Fall wäre N=20. Da sich bei einer Erhöhung von N um 1 in dieser Höhe der Umfang ca. ver-50-facht, wären also ca. $10^{8}$ Kern-Stunden nötig, also ungefähr 1000-2000 Kern-Jahre. Das könnte man mit Verteiltem Rechnen, wie wir es mit dem Collatz-Problem auch gemacht haben, angehen. Natürlich müsste man dafür den Code noch etwas aufpolieren, z.B. einbauen, dass die Rechnung unterbrochen und ann einem nicht zu fern in der Vergangenheit liegenden Checkpunkt wieder aufnehmen kann, von der Kommunikation mit dem Server ganz zu schweigen (wobei letzteres mit dem BOINC-Wrapper wohl ganz gut geht). Ggf. kann man die Leute von yoyo@home, die das damalige Projekt gehostet haben, noch mal ansprechen...


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2352
Wohnort: Thüringen
  Beitrag No.139, eingetragen 2020-04-26

a(20) ist nicht 50fach, sondern 1000fach gegenüber a(17) a(17) ist in 2-3 Tagen Locker drin, wenn ich mit Gerd das durchziehe. Sind ja nur ~45 Durchgänge. Das Problem weiter zu optimieren ist löblich, aber es ist nur noch a(17) machbar. Wozu also viel Zeit in den Code noch investieren ? Gruß


   Profil
Ixx
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 05.04.2020
Mitteilungen: 340
  Beitrag No.140, eingetragen 2020-04-26

\quoteon(2020-04-26 12:33 - pzktupel in Beitrag No. 139) a(20) ist nicht 50fach, sondern 1000fach gegenüber a(17) \quoteoff Lies noch mal, was ich geschrieben habe. Ich rechne mit einem Faktor 50 bei einer Erhöhung von N um 1, also mit einem Faktor von $50^3=125.000$ für die Erhöhung von N=17 auf N=20... Und um auf deine zweite Frage zu antworten: Ich verwies ja gerade auf Verteiltes Rechnen. Wenn da 1000 Leute mitmachen, ist die Laufzeit schon wieder in einem handhabbarem Umfang.


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2352
Wohnort: Thüringen
  Beitrag No.141, eingetragen 2020-04-26

Achso Ixx...ne, ist aber nur ~10fach pro N+1 Nachtrag: Ja wenn 1000 Leute...aber die findet man nicht https://matheplanet.de/matheplanet/nuke/html/images/forum/subject/lookaround.gif a(20) hat iwas bei 1500-2000 Billionen !


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.142, eingetragen 2020-04-26

10 h pro Kern sind viel zu optimistisch, da selbst mein schneller PC jetzt schon über 10 h rechnet! Selbst der schnellste wird 30 h zum Ende hin brauchen und "normale kleine" werden auf 60 h hoch gehen... Zur Zeit finden sich ja nicht mal hier beim 17er ... [Die Antwort wurde nach Beitrag No.140 begonnen.]


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2352
Wohnort: Thüringen
  Beitrag No.143, eingetragen 2020-04-26

Ich rechne zum Ende hin ca 2-3 Tage pro Durchgang.


   Profil
Ixx
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 05.04.2020
Mitteilungen: 340
  Beitrag No.144, eingetragen 2020-04-26

Bei der Collatz-Rechnerei sind wir auf 1000 Rechner gekommen. Man sollte nicht unterschätzen, wie viele Leute weltweit ihre Rechenzeit in solche Projekte stecken. Aber vielleicht sollte man erst einmal N=17 abwarten, um eine bessere Hochrechnung zu erhalten. [Die Antwort wurde nach Beitrag No.142 begonnen.]


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2352
Wohnort: Thüringen
  Beitrag No.145, eingetragen 2020-04-26

Morgen früh ist der 9. Zyklus von der Offsetsuche abgelaufen. Da könnte ich mal pausieren und 16 eurer 51 Runs übernehmen. Das Programm sollte aber sauber arbeiten 😃 , also fehlerfrei vom inhaltlichen her. Okay ?


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.146, eingetragen 2020-04-26

Wenn überhaupt noch 16 über bleiben, da ich schon über die Hälfte fertig habe. Zur Erinnerung: Ergebnisse hier Damit wir uns nicht überlagern, schlage ich das Entgegenkommen aus Richtung 17 1 49 50 vor. Die "saubere exe" findet man im Beitrag No.131 (nur die 64 Bit! - die 32 Bit war nur zum Test & funktioniert nicht mit allen Parametern). Fehlende DLLs findet man in den ZIPs der Beiträge zuvor. Ich werde mal die letzte 17 1 50 51 starten um eine Maximalzeit zu bekommen.


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2352
Wohnort: Thüringen
  Beitrag No.147, eingetragen 2020-04-26

Okay, starte jetzt 17 1 49 50 bis 17 1 34 35 (geändert) Mit Programm DreierPartIxxRekuSumN3i9.exe


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.148, eingetragen 2020-04-26

Damit sind noch 4 offen.


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2352
Wohnort: Thüringen
  Beitrag No.149, eingetragen 2020-04-26

Bekomme es auf dem 2. PC nicht hin..will auch nicht groß nachinstallieren. Gibt es eine Ersatzversion für Win7 64bit + DLLs ? Anbei , der Peak wird bei 60 Mrd sein, das dauert ca. 2 Tage hier. Es laufen erstmal nur die hinteren 8 von 16


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.150, eingetragen 2020-04-26

Nix installieren. Du hast vermutlich die falschen DLLs. Probier mal die 3 hier im selben Ordner oder im System32: (entfernt)


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2352
Wohnort: Thüringen
  Beitrag No.151, eingetragen 2020-04-26

Wird nix erstmal, der 2.PC ist vom Stand nie mit Windows 7 Updates gefüttert worden. Da fehlt ne Menge um die DLLs zum laufen zu bringen.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.152, eingetragen 2020-04-26

Im gleichen LINK-Ordner habe ich noch weitere DLLs abgelegt. Nun sind es aber alle: https://matheplanet.com/matheplanet/nuke/html/uploads/b/47407_exe_DLLs.PNG


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2352
Wohnort: Thüringen
  Beitrag No.153, eingetragen 2020-04-26

Habe SP1 installiert...mal sehen obs klappt. Wenn ja, nehme ich dann alle 12 statt 8 und warten 2 Tage ab.


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2352
Wohnort: Thüringen
  Beitrag No.154, eingetragen 2020-04-26

SUPER ! Läuft, ich nehme dann alle 12 restlichen.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.155, eingetragen 2020-04-26

Ich habe bis 17 1 31 32 hyperG... Was sind denn Deine kleinsten Parameter, wenn Du von "12 restlichen" redest? Interessant wäre exe 12 um Geschwindigkeit zu vergleichen!


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2352
Wohnort: Thüringen
  Beitrag No.156, eingetragen 2020-04-26

Angepasst ! 17 1 32 33 ich 17 1 33 34 ich 17 1 34 35 pzktupel... 17 1 35 36 pzktupel... 17 1 36 37 pzktupel... 17 1 37 38 pzktupel... 17 1 38 39 pzktupel... 17 1 39 40 pzktupel... 17 1 40 41 pzktupel... 17 1 41 42 pzktupel... 17 1 42 43 pzktupel... 17 1 43 44 pzktupel... 17 1 44 45 pzktupel... 17 1 45 46 pzktupel... 17 1 46 47 pzktupel... 17 1 47 48 pzktupel... 17 1 48 49 pzktupel... 17 1 49 50 pzktupel... Vergleichen geht nicht mehr, aber ohne HT sind es ~3.5s pro Mio, 1 Mrd / h Wird etwa das doppelte an Zeit von Dir sein. Mittwoch vormittag,sollte er durch sein. Wäre aber schön gewesen, wenn das Resultat gespeichert würde, falls man das wegdrückt 😐


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1847
  Beitrag No.157, eingetragen 2020-04-26

Bisher gab es noch keine Nachfrage zum Datei-Speichern. Und ich glaube auch nicht an ein 20er, wenn es jetzt schon bei Dir 2 Tage pro exe dauern sollte und dann noch Faktor 1000...125000 dazu kommt. Bei 2 Tagen & 16 parallelen EXE besteht natürlich die Gefahr eines Tastaturklicks... Bei mir brauchen die 17er 1,8...2,75 s pro 1 Mio. (nicht konst!) Interessant finde ich die starke Nichtlinearität: manchmal (besonders bei exe 12) sieht man starke Geschwindigkeits-Unterschiede beim Printen der Zeilen. Für die Summen (also die Folge A108235) eine explizite Funktion zu finden ... wäre schon eine HAMMER-Algorithmus (Kombinatorik mit Randbedingungen).


   Profil
Ixx
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 05.04.2020
Mitteilungen: 340
  Beitrag No.158, eingetragen 2020-04-26

\quoteon(2020-04-25 14:37 - StrgAltEntf in Beitrag No. 132) Ich habe eine Funktion search2 geschrieben, die keine Summenprüfung macht und dementsprechend auch keine Summen als Parameter hat. In search2 wird davon ausgegangen, dass die letzten n/3 Glieder Summen der ersten 2/3 Glieder sind. Das hat mir noch mal 1/3 (!) Gesamtlaufzeit eingespart. \quoteoff Dazu kommt mir folgende Idee: Wenn es eine Funktion search2 gibt, die die Fälle abhandelt, dass die Summe der ersten 2/3 Glieder gleich die Summe der des letzten Drittels ist, dann könnte die Funktion search sich auf die Fälle spezialisieren, wo das nicht der Fall ist. Wenn hier eine echte Ungleichung sum1 < sum2 vorliegt, dann wissen wir, dass mindestens ein Tripel a+b=c mit a


   Profil
StrgAltEntf
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 19.01.2013
Mitteilungen: 8028
Wohnort: Milchstraße
  Beitrag No.159, eingetragen 2020-04-26

\quoteon(2020-04-26 21:40 - Ixx in Beitrag No. 158) Dazu kommt mir folgende Idee \quoteoff Das hört sich sehr interessant an! Ich werde es ausprobieren ... morgen ... bin echt gespannt! 😃


   Profil
Dies ist eine Knobelaufgabe!
Der Themensteller hat bestimmt, dass Du Lösungen oder Beiträge zur Lösung direkt im Forum posten darfst.
Bei dieser Aufgabe kann ein öffentlicher Austausch über Lösungen, Lösungswege und Ansätze erfolgen. Hier musst Du keine private Nachricht schreiben!
-->> Fortsetzung auf der nächsten Seite -->>
Seite 4Gehe zur Seite: 1 | 2 | 3 | 4 | 5 | 6  

Wechsel in ein anderes Forum:
 Suchen    
 
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001-2022 by Matroids Matheplanet
This web site was originally made with PHP-Nuke, a former web portal system written in PHP that seems no longer to be maintained nor supported. PHP-Nuke is Free Software released under the GNU/GPL license.
Ich distanziere mich von rechtswidrigen oder anstößigen Inhalten, die sich trotz aufmerksamer Prüfung hinter hier verwendeten Links verbergen mögen.
Lesen Sie die Nutzungsbedingungen, die Distanzierung, die Datenschutzerklärung und das Impressum.
[Seitenanfang]