GI = Guckis Intelligenz

[HaWe]

Er und ich haben unseren Eingängen Zahlenwerte zugeordnet. Eine Zelle mit zwei Eingängen A und B kann zum Beispiel für jeden Eingang den Zahlenwert "5" zugeordnet haben. Die Zelle soll beim Summenzähler "10" feuern.

nein, habe ich nicht.

Mit dem Quatschkram haben sich erwachsene Männer fast zwei Jahrzehnte lang gegenseitig die Rüben eingeschlagen, Vorträge gehalten, Bücher geschrieben, Flugreisen gemacht. Forschungsgelder verballert und letztlich nur dummes Zeug geredet.

Und hör doch mal bitte auf, die bestehenden Ansätze immer mit derart abwertenden Attributen zu diskreditieren - sie funktionieren, aber bei dir sehe ich noch keinen funktionierenen Code, der per Überwachtem Lernen beliebig trainiert werden kann.

Puh.... hab ich das halbwegs verständlich rüberbringen können?

nein, da muss ich leider passen. Aber vlt sind ja andere hier klüger und können das nachprogrammieren.

[Rumgucker]

Hallo Helmut,

Du hast doch Deinen Eingängen doch ebenso Zahlenwerte zugeordnet. Bei Dir ist es eben "0.5" oder was auch immer. Nun verwirr die anderen doch nicht sinnlos.

Vielleicht kannst Du das XOR-Problem besser darstellen?

Viele Grüße

Wolfgang

[HaWe]

nein, ich habe überhaupt nichts "zugeordnet". Wie ein Perzeptron funktioniet, muss ich aber wirklch nicht mehr erklären, und auch nicht, wie das XOR Problem nach Papert et al. gelöst werden konnte. Das tut aber auch hier nichts zur Sache, denn ich verwende zwar Perzeptronen und BP-Netze nach Paperts Ansatz, du aber nicht. Verwirrend sind eher deine Vergleiche zwischen den BP-Netzen und deiner Konstruktion, denn die haben wirklich nicht viel gemeinsam - und ob und wie sie funktionieren sollen, kann ich noch nicht erkennen.

[Rumgucker]

Hallo Helmut,

meine Doku hast Du.

Was sollen dieser dauernden Wiederholungen, dass Du meine Software nicht nachvollziehen kannst? Empfindest Du Dich als Ober-Gutachter meines Projektes?

Ich hab mich gerade umentschieden. Tiny85-Code gibts nur auf Anfrage per Mail.

Viele Grüße

Wolfgang

[HaWe]

Es heißt genau das, was ich schreibe, weil du fragst, ob es verständlich sei und ob ich etwas erklären könnte:
ich sehe keinen kompilierbaren Code, den ich verstehen, selber kompilieren und auch varieren und testen kann. Solange sehe ich nur vage Diskussionen um Ideen, aber nichts Verständliches und Substanzielles leider.

- - - Aktualisiert - - -

PS,
@stochri: hast DU kompilierbaren Code für ein lernfähiges Netz zum testen?

[Rumgucker]

Hallo Helmut,

wieso willst Du das GI-System testen? Du bist doch glücklich mit Deinen Systemen.

Und wieso kannst Du den Code nicht testen?

Gehts um FSR und INDF? Das ist ein eingebauter Pointer-Mechanismus des PICs. Dafür kannst Du schreiben:

char *FSR;
#define INDF (*FSR)

Oder gehts um den FIRE_REQ-Makro

#define FIRE_REQ (INDF.7) // zelle will feuern

Der PIC kann einzelne Bits lesen und kippen. Das wird natürlich genutzt. Du kannst dafür schreiben:

#define FIRE_REQ (INDF & _BV(7)) // zelle will feuern


Dann gelten noch meine Lieblings-Defines

#define BOOL bit // da kannst Du klein "bool" einsetzen
#define TRUE 1
#define FALSE 0
#define FOREVER while(1)
#define _BV(a) (1 << (a))

Und statt "uns8" kannst Du schreiben "unsigned char".

Fertig ist die Laube. Der ganze Rest ist K&R-Standard-C und der Aufruf des eeprom-Speichers.

Wo siehst Du Schwierigkeiten in der Portierung?


Ich habe unverändert Null Bock, Fehler in fremden Portierungen zu suchen. Das ging hier im Thread schon einmal gehörig schief. Getestete Portierungen gibts nur von mir. Und auch nur auf Anfrage ab Mitte nächster Woche, wie schon erklärt.


Viele Grüße

Wolfgang


Hier die aktuelle Doku mit selbstgesteuertem Lernen:

gi.pdf

[Moppi]

Hallo,

wieso willst Du das GI-System testen? Du bist doch glücklich mit Deinen Systemen.

Warum will er das testen? Vermutlich um es, mindestens extern, zu verifizieren. U.U. selbst dann, wenn er es nicht "gut" findet.

Was den Rest anbelangt, wüsste ich jetzt aus dem Stand auch nicht, ob ich der Darbietung ein "Mangelhaft" oder "Ungenügend" geben sollte.
siehe:

char *FSR;
#define INDF (*FSR)

Oder gehts um den FIRE_REQ-Makro

#define FIRE_REQ (INDF.7) // zelle will feuern

Der PIC kann einzelne Bits lesen und kippen.

Wegen der Frage nach dem Warum:

Dies ist ja ein öffentliches Thema, somit also für die Breite Masse zugänglich. Der Forumsbetreiber hatte dazu geschrieben: Denkt bitte auch an Einsteiger!
Wenn ich es wirklich ernst meine, würde ich meine Gedanken ordnen und versuchen, alles so darzubieten, dass es jeder versteht. Je nach Hintergrundwissen versteht es der eine besser, der andere schlechter und einer gar nicht. Dazu muss ich noch nicht einmal einen Source Code darbieten, wenn zuvor allgemeinverständliche Erklärungen vorlagen, die jeder lückenlos nachvollziehen kann. Das bedeutet aber auch eine Menge Arbeit im Detail. Source Codes für Arduino-IDE, Assembler- oder PIC-Programmierung, oder auch für Pascal, Fortran, MS Visual Basic, Borland C++ Compiler Version X, Java oder ECMA-Script V5 runden die Sache sicher ab, sind aber nicht unbedingt notwendig. Dafür gibt es allgemeingültigen Pseudocode, der auch in Schulen gelehrt wird und für so etwas besser geeignet wäre. Aber es gibt auch gut verständliche PAP-Formen, die verwendet werden können. Dafür gibt es ganz brauchbare Tools, wie diesen PAP-Designer.

Ich habe unverändert Null Bock, Fehler in fremden Portierungen zu suchen.

Ist durchaus verständlich. Aber genau so wenig haben Leute hier unverändert Bock, sich durch fremde Programmiersprachen zu quälen und/oder stapelweise Dokus zu lesen, die in den Erklärfaden eingestreut sind, wenn die übrige Erklärung drumherum mangelhaft ist. Für solche Art der Darbietung halte ich die Blog-Seiten für geeigneter, die jeder User hier für sich anlegen kann. Dort findet die Wissensdarbeitung dann so statt, wie es jeder für notwendig hält, der seinen Blog fortführt. Dagegen gibt es nichts einzuwenden. Ich will hier niemanden reglementieren, is nur ein Vorschlag und meine Meinung.



MfG