** Brainfuck Interpreter Contest ** [abgeschlossen]

Optimierst Du wirklich schrittweise oder hast Du einen Topcode von anfang an?

Ich finds einfach so krass, dass Du jede meiner mühsam erkämpften Ideen direkt wieder alt aussehen lässt.

hustbaer

µ schrieb:

Optimierst Du wirklich schrittweise oder hast Du einen Topcode von anfang an?

Ich betreibe kein Understatement, falls du das meinst, also ich schreib nicht was schlechteres hin als ich schon habe, damit ich dann bei Bedarf schnell nachziehen kann.

Ich hab allerdings erst 1x "alles umgeworfen". Die restlichen Dinge sind sukzessive Änderungen.

Ich finds einfach so krass, dass Du jede meiner mühsam erkämpften Ideen direkt wieder alt aussehen lässt.

Hihi

Ich bin sauneugierig auf deine Entwicklungsschritte und es würde mich nicht wundern, wenn wir fast identischen Code hätten.

Du hörst von mir

hustbaer schrieb:

okok...

~~228~~ 227
Wobei der Code echt anfängt unleserlich zu werden.

Bin dabei: 227

volkard

Kleineres Beispiel für verschachtelte Schleifen.

RunTest("Sieben","++>++++<[->[[>+>+<<-]>[<+>-]<-]>>[-<<+>>]<<<]>.","","7");

hustbaer

@µ
Du vergisst auch die diversen Anforderungen nicht die (noch) nicht vom Testsystem geprüft werden, oder?

Also dass sämtliche Zeichen die in ein .NET "char" passen, aber nicht im "Brainfuck-Alphabet" vorkommen ignoriert werden müssen. Dass Zellenwerte negativ werden dürfen. Dass es keine explizite Beschränkung für verschachtelte Schleifen gibt (nur implizit über das 1<<20 Limit für die Programmlänge).
Diese Sachen halt.

Meine 227 Variante muss ich nämlich noch dagegen checken, und es würde mich fast wundern wenn du ohne Tricks auskommst, die diesbezüglich total unkritisch sind

hustbaer schrieb:

Also dass sämtliche Zeichen die in ein .NET "char" passen, aber nicht im "Brainfuck-Alphabet" vorkommen ignoriert werden müssen.

hustbaer schrieb:

Dass Zellenwerte negativ werden dürfen.

EDIT: Muss ich nochmal überdenken.

hustbaer schrieb:

Dass es keine explizite Beschränkung für verschachtelte Schleifen gibt (nur implizit über das 1<<20 Limit für die Programmlänge).

Ich werde vor Abgabe nochmal intensiv über Beschränkungen nachdenken, bin mir zur Zeit aber relativ sicher, dass alle Anforderungen erfüllt sind. Ein Band mit 2^16 Feldern reicht, ja?

Maximales Programm 2^20. Macht höchstens 524288 Klammerpaare. Mein Code kriegt erst ab 2^30 Paaren Schwierigkeiten.

Die Programmlänge ist sonst egal da keine Rekursion (StackOverflowException).

Alles außer dem Bf-Befehlssatz wird ignoriert.

Nee, ich weiß nicht was ich noch prüfen müsste. Hast Du noch ne Idee?

µ schrieb:

hustbaer schrieb:

Dass Zellenwerte negativ werden dürfen.

EDIT: Muss ich nochmal überdenken.

Jetzt. Ein Zeichen mehr und damit nur noch 228

Stellst Du noch ein Testsystem für die Rahmenbedingungen zur Verfügung?

TyRoXx

Möchte vielleicht jemand von den Führenden (edit mod) kritisieren? Es würde mich wirklich interessieren, ob ich etwas völlig falsch gemacht habe. Hat übrigens 273 Zeichen, also habe ich mit der Veröffentlichung nichts zu verlieren oder so.
Alle 13+1 Tests besteht es.

Dravere

Keine Lösungen jetzt schon zeigen! Habe es rauseditiert und nicht angeschaut. Auch wenn du nicht den 1. Platz hast, verrate noch nichts!

Grüssli

Bashar

TyRoXx schrieb:

also habe ich mit der Veröffentlichung nichts zu verlieren oder so.

Naja, man kann Tricks klauen ...

@TyRoXx
Das Spiel läuft noch über eine Woche. Wenn Du wirklich nicht mehr daran arbeiten willst kannst Du es ja hier posten. Aber was erwartest Du von der Kritik? Seine Tricks kann zur Zeit niemand Preis geben.

EDIT: Vergiss es. Hab Draveres Nachtrag zu spät gelesen.

TyRoXx

Na, dann poste ich es hier eben nicht.
Ich dachte, so ein Austausch würde die Sache interessanter machen.

Programmiere zwar kein C#, aber das ist interessant zu lesen, bin gespannt!

Dravere

TyRoXx schrieb:

Na, dann poste ich es hier eben nicht.
Ich dachte, so ein Austausch würde die Sache interessanter machen.

Austausch kann man am Schluss machen. Du nimmst den Leuten doch die ganze Spannung. Ich will selber auf diese Tricks kommen. Das ist hier aktuell ein Wettbewerb und keine Teamarbeit! Sonst kann man es ja gleich vergessen.

Wieso soll man einen Wettbewerb machen, wenn alle am Ende dieselbe Lösung einreichen?

Grüssli

hustbaer

Genau.

Wenn es Interesse gibt kann ein Austausch gerne nach Ende des Contest hier stattfinden.

Wäre auch interessant ob wir aus den abgegebenen Lösungen was noch kürzeres gebastelt bekommen.

Auch kann jeder der will dann gerne die ganzen Tricks erklären die verwendet wurden, sofern sie nicht offensichtlich sind.

hustbaer

µ schrieb:

Ein Band mit 2^16 Feldern reicht, ja?

Japp, steht so in den Vorgaben.

µ schrieb:

Stellst Du noch ein Testsystem für die Rahmenbedingungen zur Verfügung?

Falls ich Zeit habe.
Ist aber schwierig auch nur ne halbwegs gute Testabdeckung zusammenzubekommen. Je nach Code könnte es vorkommen dass nur eine bestimmte Kombination aus Faktoren das Fehlverhalten triggert. Und alle Kombinationen aus Bandposition/Programmposition/Schleifen-Schachteltiefe/Zellenwert abzudecken ist so-gut-wie unmöglich (und auf jeden Fall unpraktikabel).

Falls jemand von euch Zeit & Lust hat weitere Test-Cases zu schreiben, z.B. auch welche die gezielt auf bestimmte Rahmenbedingungen checken, wäre ich sehr froh.

Idealerweise so posten wie volkard es vorgezeigt hier hat, damit es jeder schnell ausprobieren kann, und ich es schnell integrieren kann:
http://www.c-plusplus.net/forum/p2116659#2116659
(Danke @volkard BTW!)

volkard

Der Interpreter kann Programme bis einschliesslich 2^20 Zeichen verarbeiten.
Der Speicher der Brainfuck-Maschine ("das Band") hat 2^16 oder mehr Zellen.
Jede Zelle kann eine vorzeichenbehaftete Zahl speichern, Wertebereich mindestens 16 Bit (-32768 ... 32767).

Soweit ok.
Aber daraus eine Verschachtelungstiefe von 2^19 abzuleiten, ist übertrieben. Das macht man in anderen Programmiersprachen auch nicht.
Sie muß ausreichend sein für alle einigermaßenh sinnvoll zu erwartenden Programme. Das heißt 99 reicht. Und 9 reicht nicht.

hustbaer

volkard schrieb:

Aber daraus eine Verschachtelungstiefe von 2^19 abzuleiten, ist übertrieben. Das macht man in anderen Programmiersprachen auch nicht.
Sie muß ausreichend sein für alle einigermaßenh sinnvoll zu erwartenden Programme. Das heißt 99 reicht. Und 9 reicht nicht.

Da in den Regeln nix zum Thema Verschachtelungstiefe steht, aber steht ein Interpreter muss jedes korrekte BF-Programm verarbeiten können, kann man die Regeln IMO nur so auslegen, dass auch eine Verschachtelungstiefe von bis zu 2^19 verarbeitet werden muss.

Ich hätte nichts dagegen die Regeln dahingehend anzupassen. Obwohl ich als Limit dann eher 255 oder besser gleich 1023 vorschalgen würde - 99 kommt mir ein wenig wenig vor. Nicht dass ich ernsthaft mit BF Programmen rechne die tiefer als 99 schachteln. Man könnte vielleicht sagen, es ist mir "aus Prinzip zu wenig"

@all:
Falls sich genügend Leute für eine dahingehende Änderung aussprechen, hab ich kein Problem damit die Regeln nachträglich in diesem Punkt anzupassen.