GI = Guckis Intelligenz

[Rumgucker]

Hallo,

wow.. Ihr seid aber charmant. Das geht mir ja runter wie Öl. Dankeschön!

Ich hab aber keinen Hintergrund und keine Ahnung. Das sehe ich als Vorteil, weil ich dadurch frei denken kann.

--------

Die Uni Ulm macht viel mit FPAAs rum, das analoge Gegenstück zum digitalen FPGA. Eine Ansammlung von analogen Rechenelementen und eine programmierbare Schaltmatrix.

https://www.uni-ulm.de/in/mikro/fors...altungen/fpaa/

Genau wie ein FPGA hat das Ding leider auch nicht die dynamische Konnektivität, die man eigentlich bräuchte.

DER Analog-Guru Prof. Bernd Ulmann beobachtet das Gebiet analog + KI sehr genau.

Viele Grüße

Wolfgang

[HaWe]

wie unterscheidet sich "analog" vom Rechnen mit Fließkommazahlen?


PS,
auch die DACs oder ADCs in FPAA rechnen ja wieder digitale Integer-Zahlen in analoge Spannungswerte (und umgekehrt) um, die man auch als floats repräsentiern kann.

[Rumgucker]

Hallo Helmut,

natürlich gar nicht. "Analoges Rechnen" bedeutet ja erstmal nur, dass ein Analogon erschaffen wird. Statt eines OPV-Integrators kann das auch der Wasserstand einer Badewanne sein.

-------

Aber es gibt gewichtige Unterschiede. Analoge Schaltungen arbeiten bevorzugt zeitkontinuierlich. Eine analog errechnete PWM schlägt beispielsweise einfach alles. Theoretisch können ihre Flanken in Attosekunden aufgelöst sein. Im Gegenzug freut man sich bei analogen Verstärkern schon über unlineare Verzerrungen von unter 0,1%. Also 10 Bit Auflösung umgerechnet.

In der Digitaltechnik gehts komplett andersrum. Zeitdiskrete Schritte und irrwitzige Auflösungen.

Viele Grüße

Wolfgang

[HaWe]

wozu brauche ich Attosekunden Auflösung in neuronalen Netzen?
Ich vermute: überhaupt nicht - wo ist also der Vorteil von analogen Rechnern vs. digitalen cpus z.B. auch + fpus (ESP32, SAMD51, ARM Cortex A57)?

PS,
64bit double hat 16 Stellen im Dezimalsystem - das sind auch schon 100 atto Genauigkeit!

[Rumgucker]

Hallo Helmut,

ach komm. Erzähl mir nicht, dass die genannten Controller immer gleich zur Stelle sind, wenn ein Lichtblitz am Eingang vorbeihuscht. Oftmals tingeln die irgendwo im Subsystem herum und es kann schon mal ein paar Millisekunden dauern, bis sie sich den Port anschauen können.

Natürlich kann man auch dagegen gegenan programmieren. Mit Port-change-Interrupts und ähnlichen Dingen. Aber die Systemstabilität, Belastung und Testbarkeit wird durch sowas nicht besser. Ein vergessener Semaphor und die Bombe tickt.

Wie elegant ist im Vergleich dazu eine analoge Schaltung, die von morgens bis abends nichts anderes tut, als nur auf Lichtblitze zu lauern. Das macht sie völlig gleichzeitig zu allen anderen sonstigen analogen Schaltungen.

Diese Parallelität ist ein potentieller Vorteil. Wie eben beim FPAA-Chip.

Und nicht ganz unerheblich in den heutigen Zeiten ist die Energieeffizienz des System. Das analoge Gehirn versorgst Du mit ner verdreckten Solarzelle. Versuch das mal mit einer GPU.

Es gibt keien pauschale Antwort auf Deine Frage. Es ist einfach die Frage nach den gestellten Anforderungen. Analogtechnik kann vielfach effektiver, schneller und zielführender sein. Ein PID-Regler setz ich in 5 Minuten zusammen und hab ihn in 10 Minuten parametriert. Da hast Du kaum das Projektverzeichnis angelegt.

Viele Grüße

Wolfgang

[HaWe]

da kommt es auf die Detektoren an: wenn es ein i2c-Detektor ist, dauert es zweifellos immer ein paar Millisekunden. SPI ist schon um den Faktor 100 schneller.
Wenn es aber z.B. um digitale GPIOs geht, dann lese ich die beim Raspi mit 10-100ns Genauigkeit/Schnelligkeit (wenn ich muss oder will), und wenn ich in Multithreading-Environments arbeite, dann locker in < 1 µs Auflösung, per pthread timeslice-Scheduler.

[stochri]

Wenn man es genau nimmt arbeitet jede Digitalschaltung analog, da sie aus Bauteilen besteht,deren Kennlinien analog sind.

Und wenn man es genau nimmt, arbeiten die Neuronen gemischt: Sowohl analog als auch digital. Das Zellpotential wird analog integriert, das Aktionspotential ( der Puls ) ist digital. Entweder das Neuron erzeugt einen Ausgangspuls oder keinen. In der Art und Weise hat sich hier an der Uni auch vor kurzem mal einer der Gastprofessoren geäußert.

DER Analog-Guru Prof. Bernd Ulmann beobachtet das Gebiet analog + KI sehr genau.

Er ist auf jeden Fall ein begeisteter Analogelektroniker:
https://www.youtube.com/watch?v=UnKCCpRFrrk

Man könnte einwenden, dass die große Zeit der Analogcomputer vorbei ist, aber wer weiß, vielleicht lassen sich einige der Prinzipien wieder verwenden.

[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