Es ist vollbracht!

Nach 45 Minuten bekam der Schachzwerg die erste Energie angeboten ... und er blieb dunkel

Ein paar Schreckminuten später war schon der schuldige gefunden; die Batterie war nicht korrekt in der Halterung gewesen.

Und schon leuchtet mir "shah" entgegen. Zusammenfassend möchte ich nur sagen dass es nicht die erste Lötarbeit sein sollte die man macht. Nicht schwer aber ein bischen Fingerspitzengefühl und eine rühige Hand sind kein Fehler!

Und während ich das schreibe muss er sich natürlich sofort in einer Partie gegen den 2Robot beweisen.

Mein erster Eindruck ist einfach nur "Nett"!

__________________
Grüße ... Helmut
______________
Es gibt genau 10 Arten von Menschen. Die, die binär verstehen, und die, die es nicht verstehen.

Ein Zwerg trumpft auf!

Was soll ich mehr sagen als dass der Schachzwerg den 2Robot (ca. 1500 Elo) in der ersten Partie besiegt hat. Der 2Robot hatte nie eine Chance; der Zwerg hat zwar nicht immer die besten Züge gespielt aber klar gewonnen.

Der Zwerg spielte auf Level 5 und 2Robot auf E7. (also jeweils 30 sekunden pro Zug)

Vielleicht war es ja ein Zufall ... aber der Einstand des Zwerges war auf jeden Fall sehr gut!

__________________
Grüße ... Helmut
______________
Es gibt genau 10 Arten von Menschen. Die, die binär verstehen, und die, die es nicht verstehen.

Diese Partie hinterlässt natürlich einen etwas zwiespältigen Eindruck; zum einen hat der Zwerg zu Beginn schon nicht schlecht gespielt. Wenn er diese Leistung bestätigen könnte, wäre er für die U1300 deutlich zu stark (immerhin ist der 2Robot ja Vize-Champion im U1500-Turnier geworden)

Andererseits hat der 2Robot ja höchstwahrscheinlich im 65.Zug das Remis durch 3fache Stellungswiederholung verpasst (was du offensichtlich mit den "??" ausdrücken willst) Und wenn der Zwerg öfter auf diese Weise gewonnene Stellungen "verschenkt", wird ihn das sicher einige ELO kosten...


Gruß,
Robert

Stimmt.
Warum der Robot da kein Remis wollte ist mir ein Rätzel!

Eine sehr große Schwäche des Zwergs ist sicherlich dass er die 3 Züge Remis Regel nicht kennt und alleine dadurch wird er viele gewonnene Partien nicht gewinnen!

Nach den ersten Gehversuchen fällt mir aber als dringend nötige Verbesserung(en) folgendes ein:

1) Zurückname von zumindest 2 Halbzügen (wenn man sich vertippt hat man derzeit keine Chance das wieder gut zu machen)

Stufe ich als relativ einfaches erstes Übungsbeispiel der Programmierung ein.

2) Stellungseingabe

Müsste auch relativ einfach gehen, aber .... reicht der Speicher?

3) 3 Züge Remis: ist aber vermutlich aufwendig (bzw. kostet viel Speicher), oder?

__________________
Grüße ... Helmut
______________
Es gibt genau 10 Arten von Menschen. Die, die binär verstehen, und die, die es nicht verstehen.

Vielleicht in der Form zu realisieren, dass man bei Bestätigung des eigenen Zuges zunächst die -noch- aktuelle Position kopiert und dann erst die Änderung in das Array schreiben lässt. Beim Aufruf der Rücknahme würde die Kopie zurückgeschrieben und beide Halbzüge wären zurückgenommen. Den Zugzähler muss man freilich auch noch zurücksetzen...Der sollte reichen! Man schreibt doch "nur" eine kleine Routine, die jede Zelle des Brett-Arrays mit einem der jeweiligen Figur entsprechenden Wert überschreibt. Oder sehe ich da was falsch? Im Netz gibt es sicher Minimax-basierende Sourcen, die sich vom Ursprungsprogramm nur um genau diese kleine Erweiterung unterscheiden - da könnte man ggf. "abkupfern"...Ich meine irgendwo (mag evtl. hinter einem Link von Ed Schröder's Prorammierseite gestanden sein) gelesen zu haben, dass dies in der Tat recht aufwändig ist. Aber auch da kann man auf bereits vorhandene Sourcen zurückgreifen - und wenn es nur dazu gut ist um zu sehen wie das funktioniert. Der Programmplatz sollte aber auch hierfür ausreichend sein. Mir stellt sich eher die Frage, inwiefern der Programmablauf durch eine solch' umfangreiche Prüfroutine ausgebremst wird - weil zu langsam wäre ja wieder kontraproduktiv...

Sorry für meine vielen Spekulationen - mit Schachprogrammierung hatte ich auch noch nix zu tun. Das wird sich hoffentlich bald ändern...

Gruß, Willi

Du packst da aber schon die Holzhammermethode aus die sicher funktioniert aber in Bezug auf Programmerweiterungen solle man (würde ich) schon versuchen Speicher zu sparen wo es geht!

Und einen (internen) Zugzähler hat das gerät nicht .... glaube ich!

Theoretisch einfach ... aber das möglichst platzsparend zu programmieren ...

Dies stell ich mir auch am Schwersten vor ... würde aber vermutlich einen sofortigen Spielstärkeschub bringen da dann das Gerät gewonnene Partien nicht mehr so leicht Remis geben kann!

Hast du auch einen Zwerg?

Zuerst bleibt für mich einmal die Software zu übersetzten (nur eine Kleinigkeit zu ändern z.Bsp einen Text) und erfolgreich auf den Zwerg zu bringen.

Und alleine das ist für einen Newcomer nicht die einfachste Aufgabe!
Besonders wo man ja auch anderes zu tun hat. Mal sehen!

Als allererstes bekommt der Robot aber die Gelegenheit sich für den verlust zu revanchieren!

__________________
Grüße ... Helmut
______________
Es gibt genau 10 Arten von Menschen. Die, die binär verstehen, und die, die es nicht verstehen.

ja, stimmt schon ... man kann auch hergehen und die Eingabe kopieren. Im Falle eines Takeback muss man dem Ding dann sagen, dass es genau rückwärts ziehen soll (das natürlich ohne Prüfung auf legale Züge). Was jetzt für einen einfachen 2-zügigen Takeback platzsparender ist weiss ich nicht. Mit einer ganzen Tabelle gespeicherter Eingaben lassen sich aber noch mehr Züge zurücknehmen - das dürfte dann gewiss kleiner sein.

Apropos "Holzhammer": Mir wurde heute schon mal gesagt, ich wäre wohl für's eher Grobe zuständig - also in dem Sinne... Das Gerät selbst hat sowieso nix - steckt alles in der Software. Wenn nicht: Reinbasteln! Irgendwie muss ja bei mehrfacher Rücknahme die Tabelle angesprochen werden (Zähler dekrementieren) und ab dem 51ten Zug wird ohnehin noch die 50-Züge-Regel relevant. Ohne Zähler wird das nix, denke ich.Wäre ich frech, würde ich sagen: "Dann schreib' das Ei doch gleich direkt in Assembler!" - bin ich aber nicht!
Ich glaube jetzt aber nicht, dass das soooo speicheraufwändig würde - Versuch macht kluch...Das schon, aber wenn das Ding mit dieser Prüfung so langsam wird dass ihm sagen wir 2 HZ an Rechentiefe geklaut werden, würde sich dadurch die Spielstärke wieder vermindern und am Ende würde die ohne Prüfung vielleicht Remis ausgehende Partie mangels Durchblick noch verloren. Das meinte ich mit Kontraproduktiv. Ich habe allerdings auch keinen Schnüff, wie Umfangreich diese Prüfung nun wirklich ist. Kommt halt auf den Versuch an. Aber es gilt ohnehin: Immer eins nach dem anderen!Nö, noch nicht - ist auch noch nicht bestellt, da ich so sehr unter akutem Zeitmangel leide. Könnte glatt passieren, ich besorge mir das Teil noch diesen Monat und friemel es erst Weihnachten zusammen. Na ok, so schlimm würde es nicht werden - aber das Basteln am Programm könnte sehr zeitkritisch werden. Käme drauf an, wie ich künftig meine Wochenenden -vor allem die Sonntage- gestalten würde. Ich fürchte, ich würde dann "Gefangener meines Hobby's" - oder ... bin ich das nicht längst? In die Sprache (irgendein "C"-Derivat, oder?) müsste ich mich auch erst einarbeiten. Ich kenne diverse BASIC-Dialekte, PASCAL und ein winziges bisschen C# und dieses Wissen ist nicht gerade ganz taufrisch. Helfen den Sourcecode zu verstehen wird es mir sicher, aber trotzdem muss auch ich erst einmal wieder lernen. Da für die Programmgeschwindigkeit auch der Compiler verantwortlich zeichnet, würde ich mich über kurz oder lang nach was schnellerem umsehen. Ich habe diverse Minimax-Versionen mal am PC getestet. Die unter Delphi entwickelte binary war mit Abstand die schnellste. Allerdings war das auch die Version mit den meisten Erweiterungen, was ja auch was ausmacht. Ach, wir werden sehen was kommt. Erst mal anfangen...Genau - die sollen sich kloppen!

Gruß, Willi

Noch ein paar Bemerkungen zu Punkt 3 - Stellungswiederholung

ich habe inzwischen den Sourcecode auf der Orginalseite des Entwicklers weiter studiert und entdeckt dass die verwendete Version das eigentlich unterstützt.

Auch Hash-Tables waren Teil dieser Micromax Version. Aus Speichergründen würde jedoch bei der Konvertierung für den Microcontroller (man hat ja nur 1 Kb; 32 byte werden je Suchtiefe verbraucht und der Rest grossteils für die Speicherung des Brettes) der Hash entfernt. Die dreimalige Stellungswiederholung fiel somit auch raus da der Hashtable dazu verwendet wurde.

Sieht so aus als ob der Speicher das Hauptproblem unseres Controllers ist der viele Verbesserungen/Erweiterungen blockiert.

Vielleicht gibt es pinkompatible Microcontroller mit mehr RAM !?
Müsste man mal überprüfen.
Ansonsten kann aus dem Zwerg schwer ein Riese werden.

__________________
Grüße ... Helmut
______________
Es gibt genau 10 Arten von Menschen. Die, die binär verstehen, und die, die es nicht verstehen.

Da hatten wir beide ja die gleiche Idee!
Auch ich habe mir heute die Sourcen angesehen und selbige Feststellung getroffen.Yep, da liegt der Hase im Pfeffer!
Ich meine aber bei der Durchsicht der älteren Sourcen auch gesehen zu haben, dass die dreifache anfangs nicht über den Hash abgefangen wurde. Wenn ich mich da jetzt nicht vertue, kamen die Hashtables (wenn man das so nennen will) erst später hinzu. Ich müsste da noch einmal nachlesen - jetzt aber schmerzen erst mal die Augen... Es gibt noch den 644, der hat 64k ROM und 4k RAM - nicht gerade viel Speicher für Hashtables, aber wenn dadurch die dreifache leichter abgefangen werden kann trotzdem eine Überlegung wert. Das Mehr an ROM eignet sich über kurz oder lang für 'ne anständige Bibi und vielleicht sogar für einfache Endings. Ob der nun Pinkompatibel ist weiss ich jedoch nicht. Notfalls müsste man das Platinenlayout ändern.
Unter Umständen ist es aber auch möglich, externen Speicher anzusprechen? Ich denke, der Controller verfügt angeblich über ach so viele Ports? Da sollte das doch auch irgendwie möglich sein?

Gruß, Willi

PS: Wenn ich ehrlich bin wäre mir ein 8-bit-Controller lieb, der neben 64k ROM auch selbiges an RAM bietet. Dann kann man bei Programmaufruf den ganzen Quatsch vom ROM ins RAM kopieren und gewinnt wieder was an Geschwindigkeit. Man könnte es dann so hinbiegen, dass nach verlassen der Bibi diese aus dem RAM gelöscht und der nun freie Speicher für Hashzwecke genutzt wird.
Damit wäre eine externe Speichererweiterung vom Tisch, weil ein 8-bitter ohne Hilfsmittel sowieso nicht auf mehr als 64k zugreifen kann.

Der Atmega 644(40 pin) ist nicht pinkompatibel mit dem Atmega88p (28 pin).
Man könnte die freien IOs dazu mißbrauchen externen SRAM anzusteuern,
die Zugriffe würden aber sehr langsam sein und damit wäre der Zwerg ziemlich schwach.
Es gibt leider auch keine 8Bit Mikrocontroller mit 64 KB SRAM.
Es gibt schöne Prototypen Boards mit 32 Bit Mikrocontroller(AT91SAM7S256) 256 KB Flash ROM und 64 KB RAM. Damit ließe sich etwas anfangen. Man muß zwar auch noch basteln um Tasten und 7 Segment LEDs anzuschließen, hätte dann aber eine Basis für Schachprogramm Experimente.