| Autor |
Nachricht |
Kha
        

Beiträge: 2962 Erhaltene Danke: 22 Dabei seit: 12.11.2005 Wohnort: Brackenheim
Win 7 F#, C# (VS2010)
|
Auch wenn Bonuszahlungen dieses Jahr wirtschaftsbedingt ausfallen werden, darf sich der Weihnachtsmann immerhin über die Zahl 4304761169 auf seinem nächsten Gehaltszettel freuen  .
Im Anhang findet sich das ausgefüllte Schema (txt, 8.03 KB) sowie eine Skizze (pdf, 87.27 KB) des angedachten Lösungsverfahrens. Anscheinend haben bei vielen aber auch simplere Ideen zum Ziel geführt, wie langweilig ;P .
Einloggen, um Attachments anzusehen!
_________________ >λ=
Bis 10.9. im Urlaub
|

|
|
BenBE
        

Beiträge: 8055 Erhaltene Danke: 17 Dabei seit: 16.07.2004 Wohnort: Jahnsdorf
Win95, Win98SE, Win2K, WinXP D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, L0.9\FPC2.0
|
Also, meine Lösung ist so einfach, wie genial: Wie erschlagen die Aufgabe mit einem linearen Gleichungssystem
Jetzt bleiben da noch die Fragen:
1. Wie sehen die Gleichungen aus?
2. Wie behandelt man die dabei auftretenden Faktoren?
Hier mal meine (zusammengehackte) PHP-Lösung:
Zusammengehackte PHP-Lösung: ausgeblendet | markieren | | |
Das Verstehen sei dem geneigten Leser überlassen
Zur Erklärung aber vielleicht soviel:
Ich ordne jedem Wichtel\Weihnachtsmann eine Variable zu. Zusätzlich merke ich mir, wo dieser im Original-Array steht (Anzeige später)
Nun stelle ich Gleichungen mit den Abhängigkeiten auf:
Davor trage ich aber für alle Wichtel, deren Gehalt bekannt ist dies auch als Gleichungen ein:
Danach das Gleichungssystem linear erschlagen und die Lösungen zurück in die Gehaltsliste übertragen und den Kram ausgeben.
Auf Grund von Rundungsfehlern liefert PHP für die unteren Reihen ein wenig ungenaue Werte. Diese Rundungsfehler stören aber für die oberen Zahlen nicht, da diese auf Grund des frühen Auftauchens in den Gleichungen als erste ermittelt werden.
Um die genaue Lösung haben sich dann aber doch noch andere gekümmert: Wer etwas in der letzten Zeit aufgepasst hat, dürfte ggf. mitbekommen haben, dass Flamefire eine Erweiterung meiner BigNum2-Unit zum Verarbeiten von Vorzeichen geschrieben hat. Flamefire hat das entstandene Gleichungssystem nämlich mit BigNum2 erschlagen - einen Aufwand, den ich mir nicht antun wollte, da ich mit sehr hoher Wahrscheinlichkeit davon ausgehen konnte, das meine Lösung ausreichend genau war - für den Weihnachtsmann (Geizhals  )
Eine andere Lösung basiert auf linearer Optimierung. Das erklärt aber IMHO dessen Anwender am Besten
P.S.: SolveLES ist eine Portierung der gleichnamigen Funktion aus der Mathe-Bibliothek von Omorphia.
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|

|
|
Xentar
       
Beiträge: 2077 Erhaltene Danke: 2 Dabei seit: 09.12.2007
Win XP Delphi 5 Ent., Delphi 2007 Prof
|
Hm.. Gleichungen..
Hab mir einfach ne Software geschrieben, die den Baum durchrechnet, also lösbare Felder einträgt.
Danach hab ich einfach Werte in der unteren Reihe ausprobiert, und mir das Ergebnis angesehen
Hatte nur leider keine Zeit mehr, das fertig zu machen 
_________________ PROGRAMMER: A device for converting coffee into software.
|

|
|
Oliver Marx
Hält's aus hier

Beiträge: 13 Dabei seit: 11.11.2003 Wohnort: Böhl-Iggelheim
Win XP, Win 7 Prof. D7 Prof.
|
Hi,
ich wünsche euch allen frohe Weihnachten!
Meine Lösung basiert auf einer linearen Optimierungsstrategie: Integer Linear Programming. Eine ILP-Problembeschreibung besteht aus zwei Teilen: Der zu minimierenden Funktion und den Bedingungen. Der ILP-Solver sucht nun nach der Variablenbelegung, welche alle Bedingungen erfüllt und die zu minimierenden Funktion dabei minimiert.
Die Bedingungen haben dabei alle fogenden Aufbau:
Die zu minimierende Funktion hängt ebenfalls von den ganzzahligen Variablen linear ab.
Zur Lösung dieser Paranuss habe ich folgende Variablenbenennung benutzt.
Da es in diesem Fall nur eine Lösung gibt, bzw. gesucht ist, gibt es keine zu minimierende Funktion. Daher habe ich die Funktion f(x_0_0,...,f_29_29) = x_0_0 als zu minimierende Funktion gewählt.
Die Bedungungen lauten wie folgt:
x_i_(j+1) + x_(i+1)_(j+1) = x_i_j
Da allerdings das "=" Zeichen nicht erlaubt ist, benutzt man folgende Formulierung:
x_i_(j+1) + x_(i+1)_(j+1) <= x_i_j
-x_i_(j+1) - x_(i+1)_(j+1) <= -x_i_j
zusätzlich kommen die vorgegebenen Werte in diese Liste:
x_1_3 <= 542353018
-x_1_3 <= -542353018
Nun füttert man einen ILP-Solver mit diesen Informationen und erhält nach ca. 0,5 Sekunden die Lösung: 4304761169
Oliver
|

|
|
Kha
        

(Threadstarter)
Beiträge: 2962 Erhaltene Danke: 22 Dabei seit: 12.11.2005 Wohnort: Brackenheim
Win 7 F#, C# (VS2010)
|
@ BenBE:
Statt Koeffizienten für eine-Gleichung-pro-Gegebene auszurechnen, einfach die elementare Grundgleichung mehrmals aufzustellen, darauf bin ich nicht gekommen.
Mathematik ist dann leider ganz außen vor  und die Implementierung wird etwas komplexer, aber von der Idee her geht es wohl nicht mehr direkter und simpler.
@ Oliver Marx:
Wow, ebenfalls eine äußerst interessante Lösung! Es muss eben nicht immer die direkte Lösung sein, wenn man das Problem stattdessen in ein bekanntes umformulieren kann und dadurch die Implementierung quasi geschenkt bekommt  .
_________________ >λ=
Bis 10.9. im Urlaub
|

|
|
Noob23
        

Beiträge: 93 Dabei seit: 09.08.2006 Wohnort: Bayern
Win XP, Win Server 2003, Win 7, Ubuntu Delphi 7, c/c++ Dev-c++, µC-8051 Keil, Webdesign Notepad++
|
Hallo zusammen,
auf die Idee, für jede der gegebenen Werte eine Gleichung (Grundlage: Binomialkoeffizienten) aufzustellen, bin ich zwar anfangs gekommen ...da es aber an der Progammumsetzung fehlte, wurde eben mit teilweisem Bruteforce drangegangen
Angeboten hat sich natürlich die linke Pyramidenseite, da hier schon relativ viele Zahlen bekannt waren und Lösung ist Lösung auch wenns eleganter ginge
Grüße
Noob23
PS: Der Weihnachtsmann wird wohl von den 4304761169 noch an jeden seiner Mitarbeiter ein Weihnachtsgeld auszahlen 
_________________ Man streitet zwar noch über die Entstehung der Erde -
Aber über den Untergang sind sich doch schon alle einig...
|

|
|
Flamefire
        

Beiträge: 1013 Erhaltene Danke: 14 Dabei seit: 03.01.2007 Wohnort: Dresden
Win XP Delphi 7 Pro; Delphi 2009 Pro
|
tja dann Mein Ansatz:
Der Baum ist vollständig durch die Variablen der untersten Reihe berechenbar.
Also habe ich jede vorgegebene Zahl als Gleichung von den Variablen der untersten Reihe ausdrücken lassen. Das geht mittels Binomialkoeffizienten
Am Ende das Gleichungssystem mittels Gauß hoch und runter rechnen und fertig.
Problem waren die episch großen Zahlen bei den Zwischenschritten. Daraus ist dann die Vorzeichen-BigNum-Lib entstanden 
|

|
|
Hidden
       

Beiträge: 1953 Erhaltene Danke: 12 Dabei seit: 07.01.2008
Win7(Home)x64, FF 3.6.8 Delphi 2010 Professional
|
Hi
Ich hatte Anfangs die gleichen Ansätze wie Flamefire und BenBE. Nach ein Paar Sekunden sind mir dann die episch großen Zahlen aufgefallen und BenBE meinte in der SB, es ginge schöner als das was ich vorhatte(Matrizen).
Ironischerweise hat BenBE mich falsch verstanden, und mein Ansatz war seiner.  Nur hat er von schöner geredet, was ich als "Mathematiker-schön" und nicht "komplizierter aber schneller" verstanden habe und erstmal weitergesucht.
Aus Frustration dass ich nichts schöneres gefunden habe, hab' ich dann den Computer die Rosinen aufpicken lassen und triviale Teildreiecke ergänzen. Dann habe ich jeweils per Hand ein GLG auf Binomealkoeffizientenbasis gelöst(mit einer Unbekannten und 2 Gleichungen  ), um zwei Teildreicke zu vereinen und wieder die Rosinen ergänzen lassen. So kommt man innerhalb von 5-10min zu dem Punkt, wo noch 2 Variablen fehlen um das ganze Ding zu bestimmen(inclusive Codingzeit  ). Hier sei es dem Geneigten Leser überlassen, ob er diese als X und Y einsetzt und ein finales GLG bildet, oder einen 5-Sekunden-Bruteforce macht. Jedenfalls bitte nicht so wie ich, mit oberen und unteren Schranken für alle Felder hab' ich's echt nochmal verkompliziert. War zwar schnell getippt, hat aber lange zu debuggen gebraucht.
lg
_________________ Hokey religions and ancient weapons are no match for scissors, though they do beat paper and rock.
|

|
|
Kha
        

(Threadstarter)
Beiträge: 2962 Erhaltene Danke: 22 Dabei seit: 12.11.2005 Wohnort: Brackenheim
Win 7 F#, C# (VS2010)
|
_________________ >λ=
Bis 10.9. im Urlaub
|

|
|
Flamefire
        

Beiträge: 1013 Erhaltene Danke: 14 Dabei seit: 03.01.2007 Wohnort: Dresden
Win XP Delphi 7 Pro; Delphi 2009 Pro
|
Nunja bei BenBEs Code hätte ich trotzdem kalte Füße, da es falsche Zwischenlösungen gibt. Trotzdem stimmt es am Ende. Ist etwas ungewöhnlich
Bei deinem Code, steige ich grade etwas zäh durch.
Wenn ich das richtig sehe, löst du das LGS so:
Variablenweise+ZeilenWeise die Gleichungen durchgehen (Also für i.Zeile i.Variable(i.Spalte)) also normal.
Jetzt suchst du die Zeile, mit dem größten Koeffizienten für die aktuelle Variable und vertauschst sie mit der aktuellen Zeile. Jetzt diese Zeile auf 1 normieren.
und dann normal weiter.
Die backward verstehe ich gar nicht
Aber ich vermute, das ist dann ohne tricks, oder?
|

|
|
Kha
        

(Threadstarter)
Beiträge: 2962 Erhaltene Danke: 22 Dabei seit: 12.11.2005 Wohnort: Brackenheim
Win 7 F#, C# (VS2010)
|
Flamefire hat folgendes geschrieben : | | Nunja bei BenBEs Code hätte ich trotzdem kalte Füße, da es falsche Zwischenlösungen gibt. |
Gut, vielleicht hat er durch die höhere Anzahl von Gleichungen größere Abweichungen. Bei mir ist auch die unterste Reihe hinreichend genau:
Flamefire hat folgendes geschrieben : | | Bei deinem Code, steige ich grade etwas zäh durch. |
Brauchst dich nicht dafür durch F# zu quälen, denn der Code ist wirklich "ohne Tricks"  . gaussRef ist eine 1:1-Übersetzung hiervon, backwardSubstitution eine davon.
Bei ersterer Funktion lässt sich leider nicht viel mit funktionaler Programmierung drehen, was die Lesbarkeit aber wohl eher erhöht hat  .
_________________ >λ=
Bis 10.9. im Urlaub
|

|
|
Martok
       

Beiträge: 1950 Erhaltene Danke: 11 Dabei seit: 05.08.2006 Wohnort: MD
Win2000, IksPeh Delphi 7, Turbo Delphi Exp.
|
F# ist das was man dann nimmt, wenn man auch vor .NET-Reflection sicher sein will
Meine Lösung ist noch etwas anders, und basiert auf der Tatsache dass jedes gegebene Feld die "rekursive Summe" aller Felder unter ihm ist. Man kann also ein Dreieck darunter aufspannen, so dass man einen Abschnitt der untersten Reihe bekommt.
Die Koeffizienten kriegt man aus (n k) für n=20 und k=Spalte.
Den Wust an Gleichungssystemen überführt man in eine Matrix und einen Vektor, übergibt das ganze in gewünschtem Format an den Kernel eines grade verfügbaren CAS, und hole sich das Ergebnis aus Stdout. Da hätte man dann auch direkt die Gleichung für den obersten Wert aufstellen können, ich hab aber nur die Werte eintragen lassen und dann iterativ nach oben addiert. Alle vorgegeben Werte haben reingepasst, musste also richtig sein.
Anders gesagt: der selbst geschriebe Anteil war lediglich eine Hilfe um das LGS aufzustellen und damit elegant an der beabsichtigten Aufgabe vorbeiprogrammiert 
_________________ "[the ++ operator] is a parable on learning: even if you throw away the result, you still gain something" - mgedmin on Freenode (Außer: c=c++;)
Ich code EdgeMonkey - In dubio pro Setting-~==~- #ee-lounge in Freenode
|

|
|
Flamefire
        

Beiträge: 1013 Erhaltene Danke: 14 Dabei seit: 03.01.2007 Wohnort: Dresden
Win XP Delphi 7 Pro; Delphi 2009 Pro
|
Nunja am Ende war mir das mit der Bignum doch am liebsten, da man so wirklich sicher gehn konnte, dass alles stimmt
UND: Man hat die Aufgabe gelöst, wie man es sollte. Nicht was fertiges verwendet
Ne ok, bei der andren Aufgabe mit den Funken habe ich ja auch bei Narses abgeguckt also sollte ich da still sein ^^
|

|
|
ub60
        

Beiträge: 420 Erhaltene Danke: 2 Dabei seit: 13.09.2005
|
Flamefire hat folgendes geschrieben : | | Nunja am Ende war mir das mit der Bignum doch am liebsten, da man so wirklich sicher gehn konnte, dass alles stimmt |
Also, ich habe Int64 verwendet, das ging auch ganz gut.
Und ich hab es auch SELBST programmiert
ub60
|

|
|
Hidden
       

Beiträge: 1953 Erhaltene Danke: 12 Dabei seit: 07.01.2008
Win7(Home)x64, FF 3.6.8 Delphi 2010 Professional
|
Hi
Ich habe auch komplett mit Int64 gearbeitet. Selbst das Gehalt des Weihnachtsmanns war aber schon Int64 und nicht mehr Integer, und beim Gauß-Algorithmus werden ständig Zeilen miteinander multipliziert. Für höhere Genauigkeit bei Gauß-Jordan werden dann zu allem Überfluss noch jeweils extra die größten Zahlen ausgewählt.
Selbst bei geschickter Programmierung muss es hier doch bei Binomialkoeffizienten der untersten Zeile zum Überlauf kommen, wenn man immer nur multipliziert und nie ganze Zeilen mit 0<k<1 malnimmt, wie es der Gauß-Jordan tut?
Zwar ist Int64 mit High(Int64) = High(Integer)² = +9.223.372.036.854.775.808 schon sehr groß, aber mit dem Produkt zweier Zahlen im Bereich High(Integer) kommt man sehr schnell in den Bereich.
Flamefire hat folgendes geschrieben: | | Nunja am Ende war mir das mit der Bignum doch am liebsten, da man so wirklich sicher gehn konnte, dass alles stimmt |
Wenn man es raushatte, konnte man sein Ergebnis doch sehr einfach durch Hochrechnen von der untersten Zeile und Vergleich mit allen gegebenen Zahlen überprüfen
Nur schnell zusammengehackt, meine Überprüfung vom Abgabetag: ausgeblendet | markieren | | |
lg,
_________________ Hokey religions and ancient weapons are no match for scissors, though they do beat paper and rock.
|

|
|
Werbung ausblenden? Dann registriere Dich kostenlos.
Weitere Gründe für eine Registrierung.
Werbung ausblenden? Dann registriere Dich kostenlos.
Weitere Gründe für eine Registrierung.
|
|
|
|
|