|
|
|
|
|
|
|
Argument, warum das gut ist/sein soll:
Dann weiß man wenigstens, wann sich das Verhalten der Funktion ändert.
|
|
|
|
|
|
|
|
|
|
|
Da ich Unit Tests als Absicherung gegen Regressionen eh viel geiler finde, also im TDD Style, finde ich das gar nicht so dermassen dämlich. Dazu fehlt aber der Kontext. Kann natürlich auch saudumm sein, wenn man das Verhalten durch das übrige System nicht verifiziert hat 
¤: Wie immer: it depends.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 27.07.2018 20:40]
|
|
|
|
|
|
|
|
|
Kann ich schon nachvollziehen. Zu wissen, welche Änderung das Verhalten ändert, kann Gold wert sein. Allerdings hat ein Unit Test, der die Funktionalität anhand eines von Hand konstruierten Beispiels verifiziert, komplett gefehlt.
|
|
|
|
|
|
|
|
|
|
|
|
Auch schon öfter gemacht... hauptsächlich wenn eh keiner weiß was das tun soll aber man halt was ändern muss
|
|
|
|
|
|
|
|
|
|
|
Aber wenn ich so was habe
| |
| Code: |
self.assertEqual(get_cancer(), 'HIV') |
|
dann bringt mir das nur einen grünen Haken und Verzweiflung beim Code-Review.
Dann benenn die Funktion halt sinnvoll, du Eimer!
Ich mein, ich bin ja froh, dass die Einsicht da ist, dass TDD sinnvoll ist, aber Einsicht und Umsetzung sind zwei paar Schuhe ...
PS: Ich mein, klar, wenn da eine Funktion rumoxidiert, die keine Tests hat, aber von der ich weiß, dass sie funktioniert, weil sich seit Jahren keiner beschwert hat, dann klar, dann hab ich keine große Wahl, wenn sie verändert/optimiert werden muss. Aber wenn ich eine Funktion schreiben will, dann weiß ich doch vorher, was herauskommen soll, oder bin das nur ich?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von cms am 28.07.2018 0:53]
|
|
|
|
|
|
|
|
|
Im Prinzip ja, aber
Wobei ich persönlich für viele Dinge inzwischen Unit-Tests wieder vermeide. Diesen ganzen Glue- und Füller-Code, da braucht man imho keine x-Tests für. Da schreibt man ein paar brauchbare Integrationstests und rutscht damit drüber. Das geht tendenziell auch schneller und ist meist näher an der realen Nutzung des Codes als Tests die viele Mocks benötigen (die auch wieder Fehler enthalten können und mitgepflegt werden müssen) o.ä.
Faustregel: Je weiter ein Stück Code von einer "pure function" (verarbeitung(eingabe) → ausgabe), desto unpassender sind Unit-Tests. Entsprechend versuche ich auch eine Kapselung zu erreichen, bei der komplexe Logik u.ä. (wie Parser) eben relativ pure ausgedrückt ist. Dann kann man das wunderbar UT-mäßig angehen und sehr schön durchtesten.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 28.07.2018 1:09]
|
|
|
|
|
|
|
|
Sehe ich fast genauso. Acceptance Tests sind ein muss, ansonsten werden für kritische und/oder komplizierte Funktionen Tests geschrieben.
Ich hab mir aber auch teilweise schon einige Kopfschmerzen erspart, indem ich immer mal wieder stumpf TDD angewandt habe.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
, aber
| |
Sehr dies.
| | Zitat von cms
Ich hab mir aber auch teilweise schon einige Kopfschmerzen erspart, indem ich immer mal wieder stumpf TDD angewandt habe.
| |
Ich finde stumpf hier eigentlich genau das richtige Wort. TDD ist einfach nicht für alles geeignet. Neuer Endpoint in einem bestehenden Service, Swagger hat die API gemacht, payloads sind klar -> TDD ist trivial und perfekt geeignet, weil man wirklich direkt einfach den neuen Teil in Isolation testen kann, und dann das verhalten mit abstrahierteren Tests verifizieren.
Aber TDD bei einer neuen Librarykomponente, bei der man noch am prototypen ist, Architektur noch unklar... das ist TDD einfach völlig falsch, weil man effektiv nur Zeit verschwendet.
¤: Und jaja, ich weiss, der Test ist Teil des Codes, der Test wird mitrefactored, Zuerst wieder Rot dann Grün *sing*. Ist halt trotzdem alles Zeit, die ich lieber in gute Integrations- und Regressionstests stecke. Unittestbarer Code kommt auch dann heraus, wenn man nicht von der ersten Zeile an alles durchtestet (mit ein wenig Erfahrung).
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 28.07.2018 11:09]
|
|
|
|
|
|
|
|
|
Eine vermutlich dumme Frage, aber ich weiß nicht so recht, nach welchen Stichworten ich googeln soll.
Ich habe ein FFNN welches für mich Entscheidungen trifft, aber die Fitness von einer ganzen Reihe von Inputs kann ich erst nach vielen runs bestimmen.
Also, es geht um eine Simulation und in jedem Simulationsstep füttere ich einen Input in ein NN und mit dem Output mache ich irgendwas. Erst nach der ganzen Simulation kann ich eine einzige Fitness bestimmen. Fürs Optimieren des Netzwerks muss ich also mit jedem NN die ganze Simulation durchlaufen lassen, Weights updaten, wieder durchlaufen lassen usw.
Sehe ich es richtig, dass das mit den Standard Lernfunktionen bei Keras nicht geht? (Normalerweise hat man ja zu jedem Input einen gewünschten output beim supervised learning)
/e: Vielleicht wird es deutlicher, wenn ich die Anwendung beschreibe. Ich will ein NN haben, welches mir bei einem Truck, der eine (beliebige) Steigung herabfährt, vorgibt wie der Truck zu schalten und zu bremsen hat, um mit bestimmten Einschränkungen (Bremsentemperatur, Maximalgeschwindigkeit, etc.) möglichst schnell den Berg runter zu kommen. In jedem Zeitschritt werden also die aktuellen Daten (Speed, Temperatur, Slope) ins NN gefüttert und das rechnet mir den benötigten Bremsdruck aus und ob hoch oder runtergeschaltet werden soll. Das wiederholt sich solange, bis der Truck unten an der Steigung angekommen ist. Dann erst kann ich die Zeit bestimmen, nach welcher ich optimieren will.
Ich habe sowas in Matlab schonmal mit einem selbst geschriebenen NN gemacht, wo man halt die Gewichte selbst irgendwie bestimmt. Jetzt will ich es mit TensorFlow oder Keras machen, weiß aber nicht, wie ich diese Lernmethode implementiere.
B0rg zu Hülf!
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Oli am 29.07.2018 14:02]
|
|
|
|
|
|
|
|
|
|
Bewerbungs-Hausaufgabe bekommen?
|
|
|
|
|
|
|
|
|
|
|
Nee, das ist aus einem alten Kurs vor vielen Jahren, eine Hausaufgabe die ich nicht fertig geschafft habe (mein Truck ist immer stehen geblieben.  )
Das habe ich mir mal als Übungsprojekt für ML ausgewählt, aber du siehst ja wie weit ich komme. Das NN einfach selbst zu schreiben geht hier vermutlich zig mal schneller als alles auf TF oder so hinzubiegen, aber man will die Frameworks ja kennen lernen.
|
|
|
|
|
|
|
|
|
|
|
Ich und Statistik, ein Drama in vielen Akten.
Ganz triviale Frage; Urnenmodell, Ziehen mit zurücklegen.
Nehmen wir an ich hab eine Urne mit N wohl unterschiedenen Murmeln, eine davon ist rot, alle anderen sind anders farbig. Ich möchte wissen was die Wahrscheinlichkeit ist nach X zügen die Rote zu ziehen.
Nach meiner Logik ( ) müsste das doch dann so aussehen
Wenn ich das jetzt aber mir mal konkret ausrechne ist die Wahrscheinlichkeit unabhängig von X immer 1/N. Auf welcher Leitung steht ich gerade....
|
|
|
|
|
|
|
|
|
|
|
Mit zurücklegen? Ist das nicht einfach
Wenn es ohne zurücklegen ist, würde ich deine Formel auch so aufschreiben...
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Oli am 29.07.2018 14:38]
|
|
|
|
|
|
|
|
|
Blöde Frage zum Truck, weil ich mich mit dem Thema nicht auskenne...
Warum unterteilt man da nicht die Strecke in Abschnitte und optimiert die Zwischenzeiten, quasi wie bei den Streckenabschnitten bei einer Skiabfahrt oder so?
Ich vermute die perfekte Lösung kann sich möglicherweise immer noch erst auf der Gesamtstrecke ergeben, aber kann man damit seine Modelle nicht schon mal in eine plausible Richtung schubsen?
|
|
|
|
|
|
|
|
|
|
|
Das Problem mit Teilabschnitten wird sein, dass die Lösung einfach nicht so gut ist. Beispiel: Bergkuppe befahren. Wenn du das in einen Anstieg, einen flachen Teil und einen Abstieg unterteilst, dann wird deine Lösung sein:
Anstieg: Ausreichender Gang und Gas
Flacher Teil: Ggfs. höherer Gang ohne Gas
Abstieg: Hoher Gang ohne Gas, ggfs. Bremsen
Tatsächlich hätte man aber schon vor dem flachen Teil vom Gas gehen können, ohne die Minimalgeschwindigkeit zu unterschreiten.
e: Achso, die Aufgabe ist einfacher.
| | | möglichst schnell den Berg runter zu kommen, v <= vmax, tbrake <= tmax, n <= nmax | |
Ist das nicht schlicht runterschalten, bis n ~ nmax und wenn v weiter steigt halt bremsen? i.e. maximale Motorbremse.
e: Klassischer "So einfach für einen Menschen, dass man nicht drüber nachdenken muss, aber wie bringe ich das jetzt einen Computer bei?!"
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 29.07.2018 14:49]
|
|
|
|
|
|
|
|
|
Ich habe ja ein Trainingsset an 1km langen slopes. Kann die auch kürzer machen, aber den score hat der Prof dann halt mit einer 1km slope ermittelt.
/e: Rats, die Bremse wärmt sich auf und darf nur eine Maximaltemperatur haben... Ganz so leicht ist es leider nicht.
Hier die Aufgabe (2.3): https://www.dropbox.com/s/jbd3t5gx1f0antm/SOA2010_HP2.pdf?dl=0 (Den Teil mit dem Genetic Algorithm zum Trainieren vom NN könnt ihr ignorieren, darauf kommt es mir gerade nicht an. Mir geht's ums NN und wie man Lernen mit den bekannten Frameworks in so einem Fall implementiert.)
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Oli am 29.07.2018 15:03]
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Mit zurücklegen? Ist das nicht einfach
Wenn es ohne zurücklegen ist, würde ich deine Formel auch so aufschreiben...
| |
Ach quark, ich mein ohne zurücklegen
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
B0rg zu Hülf!
| |
Kurze Antwort ist du willst eine policy trainieren in einem reinforcement learning setting und deine fitness ist die approximation der value function. Lange Antwort gibt's wenn ich daheim bin heute Abend :-).
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von con_chulio
| | Zitat von Oli
Mit zurücklegen? Ist das nicht einfach
Wenn es ohne zurücklegen ist, würde ich deine Formel auch so aufschreiben...
| |
Ach quark, ich mein ohne zurücklegen
| |
Hm. Macht es nicht sinn, dass es für alle X ungefähr gleich wahrscheinlich ist? Wenn du das Experiment häufig wiederholst, wird die rote Murmel gleich verteilt auf den X zwischen 1-N liegen. Oder nicht?
(Außerdem ist es bei mir nicht für alle X gleich wahrscheinlich. Bei großen X nimmt die Wahrscheinlichkeit ab.)
| |
| Code: |
N = 100
X = 2
s = 1
for i in range(1,X):
s *= 1-1/(N-i)
s /= N-(X-1)
print(s) |
|
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 29.07.2018 15:11]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von con_chulio
| | Zitat von Oli
Mit zurücklegen? Ist das nicht einfach
Wenn es ohne zurücklegen ist, würde ich deine Formel auch so aufschreiben...
| |
Ach quark, ich mein ohne zurücklegen
| |
Dann stimmt deine Aussage ja auch.
Ich liebe ja immer einfache Beispiele
5Kugeln - 1Rot und 4Weiß
usw
|
|
|
|
|
|
|
|
|
|
|
Auch wichtig bei der Frage: musst du genau bei X Zügen ankommen, oder sind Y < X Züge auch valide? In dem Fall muss natürlich noch summiert werden.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
Kurze Antwort ist du willst eine policy trainieren in einem reinforcement learning setting und deine fitness ist die approximation der value function. Lange Antwort gibt's wenn ich daheim bin heute Abend :-).
| |
So, jetzt nochmal in länger. Das Setting lässt sich gut als eine Instanz des Reinforcement Learning interpretieren, da du ein System hast, das du nicht verändern kannst (den Berg, den Lastwagen, ...) und mit diesem System mit einer fest definierten "Schnittstelle" interagieren kannst. Du weißt nicht, welche Interaktion sinnvoll ist, denkst aber, dass du das durch (überlegtes) ausprobieren schon rausfinden kannst. Das ist genau wie ich RL charakterisieren würde. Ich habe zwar das Gefühl, dass die ewigen Buchtipps nicht so auf Gegenliebe stoßen, aber eine brauchbare Quelle hierzu ist das Buch von Sutton und Barto: Reinforcement Learning, an Introduction. Speziell Sektion 3.1, die ich an deiner Stelle inmal durchlesen würde bevor du anfängst. Sind nur 20 Seiten oder so. Der von dir verlinkte Artikel schlägt denke ich in die selbe Kerbe und sieht nicht unbrauchbar aus, wenn auch der Code glaube ich nicht so elegant ist.
Verglichen mit dem allgemeinen RL-Setting hast du eine etwas vereinfachte Situation, weil du ja direkt mit dem System interagieren kannst so viel du willst. Das ist cool, denn dann kannst du Modell-basiertes Reinforcement Learning (das einzig wahre!!11) mit einem perfekten Modell machen, nämlich der Umgebung selbst. Was du also noch trainieren musst ist eine Policy, die du gern in einem neuronalen Netz darstellen würdest. Damit hast du zwei von drei wesentlichen Komponenten und kannst einfach so Trajektorieren in deinem System erstellen (also Berge runterfahren und dabei Entscheidungen treffen), nämlich indem du in jedem Zeitschritt dein Netz fragst, was es denn gern tun würde, und diese Aktion dann anwendest auf das System, um einen neuen Zustand zu bekommen. Das kannst du machen bis du unten bist.
Die dritte Komponente ist nun die Bewertung dieser Trajektorie, die wird durch den Reward modelliert. Der setzt sich bei dir wohl aus den Constraints (zu viel Temperatur ist sehr schlecht) und der Aufgabe (Zeit die man braucht um runter zu kommen) zusammen und muss korrekt formuliert werden. Sollte hier nicht so schwer sein. Ich würde etwa so vorgehen: In jedem Zeitschritt bekommst man, sofern man nicht unten ist, eine (konstante?) Bestrafung. Außerdem gibt es eine sehr große Bestrafung, wenn man illegale Dinge tut (der Lastwagen explodiert oder so). Damit bekommst du die Zielfunktion für die Optimierung. Du könntest dann entweder immer alle Berge gleichzeitig auswerten und sogar ein richtig wohldefiniertes Optimierungsproblem bekommen oder aber Minibatches betrachten und dann wird das alles ein wenig stochastischer, was aber eher nicht schlecht ist. Du wirfst dann da einen Optimierer drauf, der mit sowas klar kommt (Adam zum Beispiel) und raus kommen sollte eine sehr gute Policy.
Was das Implementieren angeht: Ich habe so ein Problem für mich gelöst, indem ich ein Keras-Netz als Policy verwende. Dazu habe ich mir Custom-Layer in Keras implementiert, die die Systemdynamik abbilden (in Tensorflow implementiert) und die Rewards aufsammeln. Diese Rewards sind dann die Ausgabe das Modells und werden zum Training maximiert. Das ist ein bisschen am Design von Keras vorbei, funktioniert aber sehr gut. Also so in recht einfachem Pseudo-Code:
| |
| Code: |
policy = build_policy_MLP()
dynamics = build_dynamics_layer()
reward = build_reward_layer()
state = starting_state
rewards = []
for t in range(maximum_episode_length):
action = policy(state)
state = dynamics(state, action)
rewards.append(reward(state))
rewards = sum(rewards)
model = Model(input=starting_state, output=rewards)
model.compile(loss=lambda output: -output, ...)
model.fit(my_starting_states)
|
|
Das hat jetzt natürlich Ecken und Kanten, da die Dynamik ja irgendwie wissen muss auf welchem Berg du bist und so, aber die grobe Idee kommt hoffentlich rüber.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von con_chulio
| | Zitat von Oli
Mit zurücklegen? Ist das nicht einfach
Wenn es ohne zurücklegen ist, würde ich deine Formel auch so aufschreiben...
| |
Ach quark, ich mein ohne zurücklegen
| |
Schnelles Argument, sofern es dir wirklich darum geht, exakt nach X Zügen die rote Kugel zu ziehen: Wenn du dir alle möglichen Permutationen vorstellst, in welcher Reihenfolge du die Kugeln ziehen könntest, dann findest du die rote Kugel an jeder stelle exakt gleich oft, denn das System hat ja keinen Bias. Entsprechend muss die Antwort symmetrisch sein, also  . Klarer gesprochen: Sind alle anderen Kugeln schwarz, dann gibt es genau N mögliche Permutationen, jeweils mit der roten Kugel an einem anderen Ort und diese Permutationen sind gleichverteilt.
|
|
|
|
|
|
|
|
|
|
|
Danke! Ich beschäftige mich morgen damit. Custom layers klingt erstmal scary. Ich hatte gehofft sowas sei ein 3 Zeiler mit Keras.
Aber durch so Probleme lernt man am effektivsten glaube ich.
|
|
|
|
|
|
|
|
|
|
|
|
Das Problem ist eher die Dynamik in Tensorflow zu implementieren. Wenn du das hast ist der Layer in der Tat ein Dreizeiler vermutlich.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
| | Zitat von con_chulio
| | Zitat von Oli
Mit zurücklegen? Ist das nicht einfach
Wenn es ohne zurücklegen ist, würde ich deine Formel auch so aufschreiben...
| |
Ach quark, ich mein ohne zurücklegen
| |
Schnelles Argument, sofern es dir wirklich darum geht, exakt nach X Zügen die rote Kugel zu ziehen: Wenn du dir alle möglichen Permutationen vorstellst, in welcher Reihenfolge du die Kugeln ziehen könntest, dann findest du die rote Kugel an jeder stelle exakt gleich oft, denn das System hat ja keinen Bias. Entsprechend muss die Antwort symmetrisch sein, also . Klarer gesprochen: Sind alle anderen Kugeln schwarz, dann gibt es genau N mögliche Permutationen, jeweils mit der roten Kugel an einem anderen Ort und diese Permutationen sind gleichverteilt.
| |
Danke das leuchtet ein.
D.h. die Wahrscheinlichkeit das nach dem Xten ziehen die rote gefunden wird ist X*1/N
|
|
|
|
|
|
|
|
|
|
|
|
Das klingt falsch, weil der Term größer als 1 werden kann.
|
|
|
|
|
|
|
|
|
|
|
Wieso?
Es gilt ja X <= N
Wenn ich 5 murmeln in der Urne habe kann ich maximal 5 mal ziehen
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von con_chulio
D.h. die Wahrscheinlichkeit das nach dem Xten ziehen die rote gefunden wird ist X*1/N
| |
Dem selben Argument folgend sollte das stimmen, ja.
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XXII ( Jetzt nehmen uns Computer schon die Memes weg! ) |
![AUP [smith] 29.07.2010](./avatare/upload/U1066026--zeratul.png)
