GI = Guckis Intelligenz

[Rumgucker]

Hallo stochri,

ich wusste nicht, dass Du "arduinifizieren" wolltest. Die Freitags-Version war noch sehr krank. Hier die aktuelle Sonntags-Version:

gi.txt

----

Zu Deinen "Arduinifizierungen":

FALSE ist bei mir 0
TRUE ist bei mir 1

Der FSR, INDF-Mechanismus ist ein PIC-Feature und zentral. Ich denke an den Konstrukt:

static unsigned char* FSR;
#define INDF (*FSR)

Du solltest auch keinesfalls mit 16-Bit-Werten arbeiten. Dann scheitern Schleifen, Offsets und Bit-Dröseleien.

Ich rechne damit, dass die Anzahl meiner Links eh nicht reichen wird, um Dekoder zu errichten. Dann muss ich sowieso auf Tiny85 umsteigen. Dann gibts naturgemäß kein "Arduinifizierungs"-Problem mehr.

Ich hatte den PIC lediglich genommen, weil er mich gleich zum sparsamen Umgang mit allen Ressourcen anhalten sollte. Mal gucken, wie weit ich damit noch komme....

Ich wäre dafür, dass wir weiterhin gemütlich bleiben. In der Ruhe liegt die Kraft. Zum Nachbauen oder gar zum Konvertieren auf andere Plattformen ist es m.E. noch zu früh. Ich kümmere mich noch nicht um Versionenpflege und Administration und will das zur Zeit auch keinesfalls im Hinterkopf haben. Auch die Anzahl meiner "Links" und Zellen ist beschränkt...

Viele Grüße

Wolfgang

[Rumgucker]

Hallo Forum,

ich falle mal wieder in meine kleinen Schrittchen zurück.

Über den in der hochgeladenen Sonntags-Software enthaltenen "pattern"-Mechanismus hab ich die drei Sensor-Zellen mit vier Bitmustern geladen, die dann nacheinander im Netzwerk abgearbeitet wurden.

switch(zell_ind) {
case SENS_0: WR_FIRE_REQ(pattern == 1); break;
case SENS_1: WR_FIRE_REQ(pattern == 2); break;
case SENS_2: WR_FIRE_REQ(pattern == 3); break;

Es wird pro Netzwerkdurchlauf also immer ein Bit gesetzt. Oder auch keins.

000 - Ergebnis: alle Ausgänge low
100 - Ergebnis: OUT_0 high
010 - Ergebnis: OUT_1 high
001 - Ergebnis: OUT_2 high

Ohne weiteres Zutun kann Klatschi also drei serielle Bits auseinanderhalten und eindeutig dekodieren.

Ein "zeitloses" Perzeptron-Netz zur Mustererkennung hätte dagegen eher so geanwortet:

000 - Ergebnis: alle Ausgänge low
100 - Ergebnis: OUT_0 high (= ein Input-Bit ist gesetzt)
010 - Ergebnis: OUT_0 high (= ein Input-Bit ist gesetzt)
001 - Ergebnis: OUT_0 high (= ein Input-Bit ist gesetzt)

Ich muss also bei zukünftigen Diskussionen höllisch aufpassen, dass ich mir die Kernidee der 20 Zeilen bewahre und nicht verwässern lasse.

Wenn ein gestelltes Problem nicht auf Anhieb von Klatschi gelöst werden kann, dann muss das nicht unbedingt an Klatschi liegen. Es kann auch am Problem liegen. Da kann schon eine simple Übersetzung des Problems von "Perceptronisch" auf Klatschis Sprache helfen.

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

Zur Zeit kann Klatschi ohne "Einlernen" zeitliche Ereignisse dekodieren. Nicht mehr und nicht weniger. Unter "zeitlichem Ereignis" verstehe ich das Setzen eines FIRE_REQ-Bits in einer Sensorzelle. Das kann durch eine high-low- oder durch eine low-high-Flanke des serialisierenden patterns entstehen.

Man muss sich jetzt fragen, ob damit die Aufgabe der "Dekodierung" schon hinreichend gelöst ist, denn ich sollte die 8 möglichen Muster von drei Eingangsbits damit vollständig in 8 eindeutige Ausgangssignale wandeln können (wenn ich genug Ausgänge hätte).

Für vier Eingangsmuster konnte ich das gestern Abend ja schon zeigen.

-------

Klatschi ist tatsächlich ein "wenig anders". Es muss anders gedacht werden. Für Klatschi besteht eine "Information" aus Ereignis und dem Zeitpunkt des Ereignisses. Ein klassisches Perzeptron kennt nur Ereignisse und es macht Mühe, ihm ein Zeitgefühl beizubringen.

Mein pattern-Generator "versteckt" sozusagen die Anweisung zur richtigen Dekodierung im Zeitpunkt der Information. Das ist das Geheimnis, warum Klatschi keinen besonderen Lehrer braucht. Der pattern-Generator IST der Lehrer.

Ich werde diese Klatschi-Informationseinheit zukünftig "Ereigniszeit" nennen.

Viele Grüße

Wolfgang

[stochri]

ich wusste nicht, dass Du "arduinifizieren" wolltest. Die Freitags-Version war noch sehr krank. Hier die aktuelle Sonntags-Version:

gi.txt

Das wollte ich eigentlich gar nicht unbedingt. Aber um deinen Code nachzuvollziehen schien es mir am besten, etwas lauffähiges auf dem Tisch zu haben.
Den Arduino-Uno habe ich gewählt, weil hier wahrscheinlich jeder einen zu Haus rumliegen hat und die niedrige Leistungsklasse ganz im Sinne deiner PIC-Wahl zur Demonstrationszwecken ist, sonst hätte ich einen ESP32 genommen.

Ich wäre dafür, dass wir weiterhin gemütlich bleiben. In der Ruhe liegt die Kraft. Zum Nachbauen oder gar zum Konvertieren auf andere Plattformen ist es m.E. noch zu früh. Ich kümmere mich noch nicht um Versionenpflege und Administration und will das zur Zeit auch keinesfalls im Hinterkopf haben. Auch die Anzahl meiner "Links" und Zellen ist beschränkt...

Es ging mir keineswegs darum vorzugreifen oder dir davon eilen zu wollen. Ich finde es nur schön, wenn ich etwas Lauffähiges auf dem Tisch liegen habe, das irgendwas tut. Das ist besser als abstrakter Code.

[Rumgucker]

Moin stochri,

ich kann Dich verstehen. Mir würds genauso gehen. Dann nimm aber bitte die Sonntags-Version.

Und ich werde - wenn sich was erhebliches gändert hat - immer gleich die aktuelle Version hochladen.

Wir müssen einfach nur unsere Ereigniszeiten besser synchronisieren. Klatschi ist da vorbildhaft...

Viele Grüße

Wolfgang

[Rumgucker]

Hallo Forum,

Klatschi entdeckt das Auftreten oder Fehlen von Ereignissen zu autonom gelernten Zeitpunkten. Es kann diese Zeitpunkte an langsame Änderungen anpassen. Das ist schon mal gut.

Ein brauchbarer Dekoder muss aber noch mehr können! Klatschi müsste von Natur aus auch kombinieren können (obwohl ich das noch nie beobachtet/nachvollzogen hab).

Zur Erlangung einer vorgegebenen Kombinationsfähigkeit muss es eine Steuerung geben, die mehrere Ereigniszeiten einspeist und den ersten aus deren Kombination resultierenden Feuerimpuls mit einem gewünschten Ausgang verbindet. Der Lernvorgang ist beendet, wenn alle gewünschten Ausgänge verlinkt wurden.

So sollte ich dann auch x-beliebige Dekodierungen hinbekommen können.

Das bau ich (ab) heute.

Viele Grüße

Wolfgang

[Rumgucker]

Hallo,

Dekoder klappt bestens:

10 -> OUT_0
01 -> OUT_1
11 -> OUT_2

Mikrominimale Erweiterung an der Source. Neue Links werden im "learn"-Mode auf die gewünschte Ausgangszelle gelenkt:

gi.txt


Es werden nun genau vier Links angelegt und keinerlei Neuronen belegt. Links mit "FF" am Anfang sind noch leer:



Das sich ergebende Netzwerk ist anscheinend goldrichtig:



Der Nutzen aller Links ist noch "00", weil sie halt erst gelernt und noch nicht benutzt wurden.

So wurde das Programm aufgerufen:

  FOREVER {
    switch(loop) {
      case 0: pattern = 0x01; learn = AKT_0; break;
      case 1: pattern = 0x02; learn = AKT_1; break;
      case 2: pattern = 0x03; learn = AKT_2; break;
      default: FOREVER;
    }
    gi_lerne();
    loop++;
  }

Es wurde also für jedes pattern ein zuzuweisender Ausgangsport festgesetzt.

Damit sind also Dekoder mit logischen Verknüpfungen realisierbar.

Ich bin mir noch nicht sicher, ob out_2 wirklich bei "11" kommt oder schon bei einem der beiden Bits. Zu dem Test müsste ich in die RAM-Zellen gucken können, damit ich sehe, wann die feuern. Kann ich aber nicht.

Da muss ich mir noch was zum Test einfallen lassen. Da kann ich noch ne kleine Leiche im Logik-Keller haben.

Viele Grüße

Wolfgang

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

So würde ich ODER "einlernen" (schreckliches Wort):
pattern=0x10 learn=AKT_2
pattern=0x01 learn=AKT_2

und so UND:
pattern=0x11 learn=OUT_2

Ich bin mir aber noch nicht sicher, ob das Klatschi auch so siieht.

[Rumgucker]

Moin Forum,

gestern wurde mir bewusst, dass ich mich mal genauer mit der Frage der "Link"-Neubildung befassen muss.

Wenn ich die Neubildung zu großzügig erlaube, wuchert das Netz. Ich kann zwischen Stagnation und Wucherung alles einstellen.

Wuchernde Netze sind unvorhersehbarer und erscheinen intelligenter. Sie scheitern aber schnell bei einfachsten Dekodern, weil ihnen vor lauter Wucherung die Links und Zellen ausgehen.

Wachstumsgebremste Netze sind ideal für Dekoder iund können sich auch an veränderliche Umwelten anpassen. Sie kommen aber keinesfalls in den Verdacht, intelligent zu sein.

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

Ich halte es für sinnvoll, das Netz in mehreren Phasen wachsen zu lassen.

Zuerst mal müssen die Reflexe wachsen. Die kann man auch Dekoder nennen. "Etwas kommt von rechts - reiße das Lenrad nach links" wäre so ein Dekoder, bei dem ich auch vorgeben muss, was das System genau tun soll. Dazu reicht mein gestriger pattern/learn-Mechnismus vom Prinzip her erstmal aus. Bei diesem Vorgang stelle ich die Wucherneigung sehr gering ein, wodurch auch nur wenige Ressourcen an Links und Zellen verbraucht werden.

Danach könnte ein weiterer Durchlauf stattfinden, in dem ich die Wucher-Bremsen lockere. In den höheren Schichten wird dann abstrahiert und findet Intelligenz statt.

**************

Weiterhin muss ich mich mit dem Nützlichkeits-Mechanismus befassen. Meine gestrige Software konnte leider nicht "undieren", weil ich die Nützlichkeit ("Gewichtung") eines Links stets nur erhöht hatte, wenn erer folgreich war.

Es dauerte nicht lange, bis es nicht mehr zweier Links bedurfte, um eine Zelle zum Feuern zu bewegen (= UND-Funktion) sondern ein einziger der beiden Links ausreichte (= ODER). Der Dekoder mutierte also vom erwünschten UND zum unerwünschten ODER.

Das sind also die beiden momentanen Baustellen. Schichtenweise Wachstumsstrategie und liebevollere Ausgestaltung der Lernregel.

Viele Grüße

Wolfgang