GI = Guckis Intelligenz

[Rumgucker]

Hallo,

nach der Verscheuchung erstaunlich vieler Bugs aus erstaunlich wenigen Programmzeilen hat sich mittlerweile auch meine Faszination über das Wachsen und Vergehen von "Links" etwas gelegt.

--------

Mit der nun von Helmut geforderten Dekodiererei steh ich allerdings noch auf Kriegsfuß. "Klatschi" optimiert die zeitliche Korrelation. Ein Dekoder optimiert Funktionen.

Klatschi reißt den Lenker nach links, wenn ihm etwas von rechts vors Auto läuft und fragt sich nicht erst stundenlang, ob das ne alte Oma, ein Auto oder ein Hund ist.

Helmuts Dekoder fährt erstmal drüber weg, setzt zurück und analysiert dann die Überreste des Opfers und entscheidet mit 89%-iger Sicherheit, dass das mal ne alte Oma gewesen sein könnte.

Vermutlich muss ich den Begriff "dekodieren" irgendwie anders verstehen. Bei mir gehts wohl eher um die zeitliche Staffelung als um die Anzahl und Kombination von statischen Eingängen. Ich kann mir zum Beispiel vorstellen, dass Klatschi das Start- und Stopbit in einem Datenstrom finden ("dekodieren") könnte.

Irgendwas beibringen muss ich dem System eigentlich nicht. Die Neuronen sollten sich vollautomatisch auf Pegelsprünge synchronisieren und Cluster bilden.

Ja... so muss ich - glaub ich - Helmuts Aufgabe an Klatschi anpassen. Klatschi ist was serielles, was chronologisches.

Helmut könnte jetzt fragen, woher ich denn wissen will, welcher (parallele) Ausgang welchem (seriellen) Datum zugeordnet ist. Das weiß ich schlichtweg nicht. Ich könnte also zur Zeit nicht mit Sicherheit sagen, ob Klatschi das Lenkrad wirklich nach links reißt. Vielleicht reißt er auch das Lenkrad nach rechts.

Die Bordelektronik eines Teslas sollte also zur Zeit noch nicht mit einem Klatschi-PIC ersetzt werden. Auch wenn der Kostenvorteil sehr verlockend erscheint.

-------

Ich bau den Generator für den Datenstrom kurzerhand mit ins Klatschi rein.

Mal gucken, was passiert.

Viele Grüße

Wolfgang

[HaWe]

Ich fürchte, du hast weder meine Frage zu deinem Netz noch mein eigenes BP Netz verstanden, was es genau wie tut, daher deine aus meiner Sicht momentan etwas seltsamen Interpretationen. Mich interessiert:
a) jedes einzelne mögliche Inputmuster, und auf welches Outputmuster es per Training abgebildet werden soll (also was genau gelernt werden soll), und
b) ob nach dem Training diese Muster auch tatsächlich korrekt nachgebildet werden:

auf 00000 folgt Output...
auf 00001 folgt Output...
auf 00010 folgt Output...
auf 00011 folgt Output...
auf 00100 folgt Output...
usw.
Lässt du einzelne Reizmuster untrainiert, musst du sie später nachtrainieren können, falls darauf nicht die gewünschte Reaktion erfolgt.

Das heißt:
a) DU bist es, der dem Netz im Detail vorgeben muss, wie bestimmte Lernmuster aussehen müssen (Trainingssets: auf Inputmuster=Reiz abcde folgt Outputmuster=Reaktion yz)
und
b) JETZT kommen erst die Auswertungen ("Dekodierungen?") während der Laufzeit usw., wo du nach dem Lernen experimentelle definierte Reize setzt und dein Netz dahingehend kontrollierst, ob die Reaktion genau das ist, was vorher trainiert wurde.

Hat das ganze eine zeitliche Dimension, musst du sagen können:

wenn erst Reiz abcde angelegen hat und darauf Reiz ghijk folgt, dann passiert Reaktion ßv,
wenn erst Reiz abcde angelegen hat und darauf Reiz lmnop folgt, dann passiert Reaktion wx,
wenn erst Reiz abcde angelegen hat und darauf Reiz qrstu folgt, dann passiert Reaktion yz,

wenn erst Reiz bcdef angelegen hat und darauf Reiz ghijk folgt, dann passiert Reaktion ß'v',
wenn erst Reiz bcdef angelegen hat und darauf Reiz lmnop folgt, dann passiert Reaktion w'x',
wenn erst Reiz bcdef angelegen hat und darauf Reiz qrstu folgt, dann passiert Reaktion y'z',

Sobald du aber dein System irgendwie sich selber überlässt, macht es wie schon geschrieben "irgend etwas Nebulöses", was keinem gezielten Lernmuster zuzuordnen ist ("bei welchem definierten Reiz muss wann wie ausgewichen werden und wann nicht?") noch eine Kontrolle und/oder Korrektur von gelerntem Verhalten ermöglicht.
Dazu musst du als allererstes kodieren, wie die möglichen Outputs
00
01
10
11
auf Fahr-Aktionen kodiert werden (gerade.vor, gerade.zurück, vorw.links, vorw.rechts, eigentlich auch stopp und ggf. rückw.li und rückw.re, das wären aber 5-7 Zustände, für die du mindestens 3 Outputs benötigst).

Wenn dann z.B. auf Input-Muster
00110 die falsche Reaktion erfolgt, muss per neuem Training korrigiert werden können:
"Das war Quatsch, hier hätte nach rechts statt nach links ausgewichen werden müssen"
oder falsche Reaktion auf 01001: "Auch das war Quatsch, hier hätte gebremst werden müssen"
oder falsche Reaktion auf 10011 "Hier hilft kein Bremsen und kein Lenken sondern nur Rückwärtsfahren")

[Rumgucker]

Hallo Helmut,

Klatschi arbeitet anders als das Dir Bekannte. Ich wollte lediglich erklären, wo und warum es Unterschiede in der Herangehensweise gibt. Ich hab kein Problem damit, wenn Dich mein Gerede nicht erreicht.

Aber ich hab ein Problem damit, wenn Du glaubst, dass ich schüchtern sei. Ich bin nicht schüchtern. Wenn ich was nicht versteh, frag ich stets nach. Ich kann mich nicht erinnern, dass ich bei Deinen Ausführungen schon jemals nachfragen musste. Du erklärst stets sehr gut und nachvollziehbar.

Also hab einfach Geduld. Ich arbeite an dem Dekoder-Problem.

---------------

Hallo Forum,

nach Beseitigung der Bugs bin ich mutig rangegangen und hab meinen ersten Dekodierungsversuch (drei Eingänge, drei Ausgänge) gemacht. Die parallelen Eingänge hab ich einfach per Software serialisiert.

Alles noch gänzlich ohne Training, weil ich erstmal die Selbstorganisation sehen wollte.

Der EEPROM-Inhalt nach dem Durchlauf:



Von jedem 16-Bit-Wort zählt immer nur das erste Byte. Drei Bytes geben einen "Link": Source-Zelle, Destination-Zelle und "Nutzen" (Gewichtungen). Ein Nutzen von 0x0A ist der Endanschlag.

Dann hab ich den EEPROM-Inhalt in einem Netz dargestellt:



Die Diodensymbole zeigen Zellen an. Die Anode ist der Eingang, die Katode der Ausgang. Die Verbindungen hab ich mit der Stärke beschriftet.

Erfreulich ist erstmal, dass die Software keinen Mist gebaut hat. Alle Verbindungen und Gewichtungen sind erklärlich. Und das in Millisekunden entstehende Netzwerk ist beeindruckend. Ich hab zwei Stunden gebraucht, um es zu analysieren. Ohne es allerdings wirklich zu verstehen. KNN ist schräger Stuff.

Wie erwartet, haben sich Cluster und sogar Rückkopplungen gebildet. Allerdings nicht vollständig ausgebildet. IN_0 ist umfangreich vernetzt. IN_1 schon deutlich weniger. Und IN_2 konnte gar nicht mehr verbunden werden. Mir fehlte es offensichtlich an Zellen und Links. Alle Links wurden verbraucht. Es konnten zwei Zellen überhaupt nicht angeschlossen werden.

Der PIC verfügt nur über 30 Zellen und 42 Links.

Das erinnert mich an ein Geschwür. Klatschi expandiert zu schnell. Zeitlich spätere Ereignisse (wie gesagt: ich musste Helmuts parallele Daten ja serialisieren) haben keine Chance.

Ich muss also das Wachstum bremsen. Erst wenn alle Inputs mit ungefähr gleich vielen Zellen versorgt sind, kann ich an Dekodierungen denken.

Viele Grüße

Wolfgang

[HaWe]

ich verstehe es nicht: Was ist ein "Nutzen"? Wann tritt ein "Nutzen" auf? Woran wird ein "Nutzen" gemessen?

Und welche "parallele Daten" von mir (?) mussten "serialisert" werden? Worauf beziehst du dich und was meinst du damit?

[stochri]

Hallo Wolfgang,

Die Diodensymbole zeigen Zellen an. Die Anode ist der Eingang, die Katode der Ausgang. Die Verbindungen hab ich mit der Stärke beschriftet.

eine sehr beeindruckende Graphik. Hast Du sie automatisch aus den Gewichten erstellen lassen?
Was ich nicht verstehe, wie die Werte dort genau zu interpretieren sind.
Ich sehen z.B. oft den Wert 0A.

- - - Aktualisiert - - -

Ein Interpretationsversuch:
WolfgangsNeuronalNet.pdf

[Rumgucker]

Hallo Helmut,

"Nutzen" = "Gewichtung". Hatte ich vielfach erklärt. Das mit der seriellen Arbeitsweise erklär ich nochmal in gebündelter Form, wenn ich die PDF erstelle. Im Moment ist es ja nicht so wichtig. Es ist beiden doch letztlich egal, wie Klatschi intern arbeitet. Wichtig ist das Ergebnis. Und das soll dekodieren können.

---------

Hallo stochri,

ich hab einfach LTSpice genommen und mir jedes Byte einzeln "händisch" aus dem Dump abgelesen und versucht, damit ein Netz zu zeichnen.

Mittlerweile bin ich aber schon deutlich schneller. Ich hab die Neigung zu Geschwüren durch zwei Maßnahmen gebremst. Ich duchsuche die Zellen jetzt vom Ausgang kommend. Dadurch können einzelne Eingänge das Netz nicht mehr so schnell mit Zellen vollwuchern. Und ich hab den Detektor zum Neuanlegen von Links etwas straffer gestellt.

Nun kommmt schon was raus (ohne jegliches Training), was an einen Dekoder erinnert (da fehlen noch ein paar Strippen, aber die sind alle unbedeutend:



Es hat sich also ganz ohne Training eine 1:1 Dekodierung ergeben. Das ist nun keine Spezialversion der 20 Zeilen. Das soll so bleiben. Er kann jetzt alten Omas ausweichen UND dekodieren. Zumindest stehen genug Zellen pro Pin zur Verfügung.

Das reicht mir erstmal für heute. Ich werde so langsam zum Klatschi-Versteher.

Ich muss mir nun eh Gedanken machen, wie ich das arme Ding für falsche Dekodierungen bestrafe und was dann genau mit dem Netzwerk geschehen soll.

Das kriegen wir auch noch hin.

Viele Grüße

Wolfgang