Geldwechsler |
30.01.2021, 16:27 | Dopap | Auf diesen Beitrag antworten » | ||||
Geldwechsler Danach hingesetzt und nach dem Koeffizienten von im Polynom gesucht. Leider stieg der TR schon bei den 5 Euro Scheinen aus.
|
||||||
30.01.2021, 18:19 | HAL 9000 | Auf diesen Beitrag antworten » | ||||
1) Du traust nicht? Könnte deine Formel in der Schreibweise vereinfachen. 2) Du kannst die Summen auch durch Reihen ersetzen. Ist womöglich keine rechnerische Vereinfachung, sieht in der Formel aber hübscher aus: 3) Wie man solche Koeffizienten rekursiv berechnet - vermutlich rechenzeit- und kapazitätsschonender, als es ein CAS mit Polynommultiplikation tut - hatte ich ja oben im Primzahlwürfel-Thread demonstriert. -------------------------------------------- Ok, Berechnungsskizze für das vorliegende Problem: Münzwerte ... Anzahl Münzkombinationen der Münzsorten mit Summe Dann ist mit Start . Klar, im Fall von (wie hier) könnte man auch mit starten - ich wollte es nur möglichst allgemein halten. |
||||||
30.01.2021, 20:24 | xb | Auf diesen Beitrag antworten » | ||||
Geht das? |
||||||
31.01.2021, 23:50 | Dopap | Auf diesen Beitrag antworten » | ||||
nicht immer lustig, meist zu allgemein, aber sehr schön, dass das rekursive Vorgehen beim Geldwechseln verständlicher wurde. Konnte somit das Programm "A" in RPN schreiben ebenfalls mit . Laufzeit = 12 min. [A(5,100)=4111 zum Vergleich] 'A': das kann man, wenn man will, stufenweise algebraisch schreiben z.B. statt m k GET wie gewohnt 'm(k)' oder z.B. 'IFTE(bedingung,then_Term,else_Term)'. Letztlich geht es ohne Programmzeilen was mir aber zu pingelig wird. -------------------- Diese Rekursionen lassen sich bestimmt mit dem PC ziemlich weit treiben. Meine Idee war und ist aber, den Geldscheinwert derart in die Höhe zu treiben bis der PC aufgibt. Keine Ahnung wo das ungefähr sein könnte. Um danach mittels der unendlichen Reihen, ,
um damit auch oder auch für einen Geldschein von Euro bestimmen zu können. Bin dabei ein klein wenig optimistischer wie diese Bemerkung:
mal sehen... |
||||||
01.02.2021, 10:41 | HAL 9000 | Auf diesen Beitrag antworten » | ||||
Diese exorbitante Zeit lässt mich vermuten, dass du die Rekursion so direkt implementiert hast, d.h., ohne Zwischenspeicherung der "alten" Werte? Organisiert man das ganze hingegen so
und das sukzessive für , dann sollte das in Sekundenbruchteilen abgehandelt sein, selbst auf lahmer Hardware und Interpretersprache (na Ok, bei Interpretern vielleicht doch ein paar Sekunden). Zum Vergleich: Matlab-MuPad (auch keine Riese hinsichtlich Rechengeschwindigkeit) benötigt mit dieser Zwischenspeicherungsmethode für (entspricht der Zusammenstellung von 100 Euro bis zur Aufsplittung 10ct) ungefähr 3 Sekunden. Für (das wäre die 1ct-Auflösung dieser 100 Euro) sind es dann aber auch schon etwas über 4 Minuten. EDIT: Wert A(13,10000) nunmehr korrigiert. |
||||||
01.02.2021, 14:45 | Dopap | Auf diesen Beitrag antworten » | ||||
RPN muss man eben lesen können Stimmt, rein rekursiver Aufruf mit 2 Argumenten von A. mMn werden reichlich unvollendete Schleifen mit reichlich vielen Aufrufen im ELSE in den stack gestellt bis ein Aufruf auf THEN trifft. Das könnte den Speicher ( 200 kB ) und die Zeit strapazieren, andererseits sind 75 MHz auf einem Interpreter wahrlich nicht viel. Hab' die Türme von Hanoi früher mal ähnlich geschrieben. Schon nach 30s kam die erste Vertauschung, danach circa alle 2 Sekunden die Nächste und weiter so für die folgenden ca. 2E+19s ~ 650 Mrd Jahre. |
||||||
Anzeige | ||||||
|
||||||
01.02.2021, 17:04 | HAL 9000 | Auf diesen Beitrag antworten » | ||||
Aus sportlichem Ehrgeiz wollte ich jetzt mal noch messen, wie lange man mit vernünftigem C++-Code benötigt, diese Anzahl zu berechnen. Unter Verwendung von 64Bit-Integer für die Anzahlwerte dauert die Berechnung von obigem nur noch ca. 50ms, und das als Single-Thread-Applikation. EDIT: Verwendet man Datentyp mpz_class (ganze Zahlen beliebiger Größe) statt 64Bit-Integer, so verlängert sich die Rechenzeit auf 650ms. Dafür ist man mit mpz_class aber in der Lage, die Bastion 500-Euro-Schein zu nehmen, d.h. die Anzahl der Wechselmöglichkeiten bis hinab zum 1ct-Stück zu bestimmen: (75 Binärstellen), Rechenzeit ca. 16 Sekunden. So, diese Darstellungen jetzt alle mal auslegen, und Dopap ist für die nächste Billion Jahre beschäftigt - vorausgesetzt, er schafft 1000 Wechselmöglichkeiten pro Sekunde. Kann er ja nach den 650 Milliarden Jahren für den Hanoi-Turm machen. |
||||||
01.02.2021, 23:34 | Dopap | Auf diesen Beitrag antworten » | ||||
Wow beeindruckend! Habe auch etwas experimentiert: 1.) mit Fließ-komma geht es 4 x schneller als beim exakten rationalen Zahlentyp. 2.) die Simulationssoftware auf dem LAPTOP ist in der höchsten Stufe 40 x schneller als das Original. aber, trotz der 3.3E22 Möglichkeiten für 15 Geldeinheiten in 16s gebe ich noch nicht auf. Das Ziel * ist und bleibt eine mathematische "Formel" die das C++ zur Schnecke degradiert. Zur Not muss dann halt ein GOOGOL- Schein ( 1.E100 oder zehn Sexdezilliarden ) gewechselt werden. Zur Vorbereitung erst einmal die Münzen auf amerikanisch umgestellt. Ein Test vorab, (*) der Mensch braucht Ziele. 30 Jahre lang im 3 Band Billard vergeblich versucht einen Generaldurchschnitt von 1.0 zu erreichen. Es reichte dann nur zu ~ 0.65 |
||||||
02.02.2021, 09:10 | HAL 9000 | Auf diesen Beitrag antworten » | ||||
Na klar, man muss sich ambitionierte Ziele setzen. |
|