Siehe hier: http://www.phpgolf.org/stuff „Tips & Tricks“ dort ist ein Link. Und ja, klappt nicht, wenn der Code in UTF-8 vorliegt. Oder bringt keinen Gewinn, weil multibyte encoding? Vielleicht beides.
Ankündigung
Einklappen
Keine Ankündigung bisher.
phpgolf :)
Einklappen
Neue Werbung 2019
Einklappen
X
-
progger77
-
Zitat von mermshaus Beitrag anzeigenSiehe hier: http://www.phpgolf.org/stuff „Tips & Tricks“ dort ist ein Link. Und ja, klappt nicht, wenn der Code in UTF-8 vorliegt. Oder bringt keinen Gewinn, weil multibyte encoding? Vielleicht beides.
Kommentar
-
Habe es nicht noch mal nachgesehen, aber die Idee dahinter ist glaube ich, bei Strings mit Leerzeichen die Anführungszeichen zu sparen (zwei Zeichen). Dazu muss zwar ein "~" hinzugefügt werden, aber das ist eben nur ein Zeichen, sodass unter dem Strich ein Gewinn von einem Zeichen steht.
PHP hat grundsätzlich diese Mechanik eingebaut:
PHP-Code:<?php
$s = bla;
echo $s;
// PHP Notice: Use of undefined constant bla - assumed 'bla'
//
// Ausgabe: bla
Das klappt aber wegen des Leerzeichens nicht mit einem String wie "hallo welt".
Man dreht das also binär um, damit der String kein Leerzeichen mehr enthält (sondern das binär invertierte Zeichen) und deshalb ohne Anführungszeichen geschrieben werden kann, weil PHP jedes Byte als Teil des Strings wertet außer denen für Whitespace, Punktuation und so.
Allerdings muss dann eben die Tilde für die Ruckinvertierung hinzugefügt werden. http://php.net/manual/en/language.operators.bitwise.php
Hat jemand das Skript da verstanden, dass HELLO als ASCII-art ausgibt?
Weil die Ausgabe zudem nur aus zwei verschiedenen Zeichen besteht, kannst du etwa pro Byte in den ersten vier Bit die Anzahl an Zeichen 1, in den zweiten vier Bit die Anzahl an Zeichen 2 ablegen.
Die Eingabe 'xxxxxxAAAAxxxA' dann zum Beispiel „gepackt“ als 0110 0100 0011 0001 (6x + 4A + 3x + 1A)
(Das erlaubt eben nur ein Maximum von 15 (oder meinetwegen 16) gleichartigen Zeichen hintereinander. Aber für das Golfen reicht das.)
Dann noch schnell 0000 als Zeilenumbruch definiert (oder so) und fertig ist das Pack-Format.
Ich vermute, dass es der, der es auf 133 Byte gebracht hat, nicht mit 4-Bit-Blöcken kodiert, sondern vielleicht mit 3-Bit-Blöcken, falls das machbar ist. Das macht das Lesen zwar komplizierter, aber reduziert eben die Speichermenge für die Daten um ein Viertel. Ist aber nur eine Vermutung.
Kommentar
-
der Jung mit den 133 scheint sich drauf spezialisiert zu haben - der hat ja so gut wie in jeder Challenge die 1000 Punkte bekommen ^^
nur haut das mit 3 bit- Encoding nicht hin - die maximale Lauflänge sind 10 (Leerzeichen) .. also doch 4 Bit ...
es sei denn natürlich er kodiert die Zeichen um - es gibt nirgends eine Lauflänge von 1 Zeichen - Minimum sind 2 Zeichen[Quote=nikosch]
So glatt kann doch wirklich keiner sein.[/quote] :roll:
Kommentar
-
ziemlich lustige Idee, ich blick nur leider echt wenig. Hab mir mal die tipps und tricks angeschaut. Dass man die Klammern und Leerzeichen teilweise weglassen kann, kapier ich ja noch, ist ja nicht so schwer, aber dann dieses ganze zeug, da muss man sich echt durchwühlen. Und dann das mit dem Encoding, da setzts bei mir echt aus. Und bitweise Operatoren auch...
Wenn ich mir das im Manual dazu anschaue, kapier ich einiges nicht. Da steht dannecho 12 ^ 9; // Ausgabe '5'
EDIT: Glaub ich habs kapiert: 9 ist 1001, 12 ist 1100 ergibt dann zusammen 0101, weil es mit dem XOR-Operator verglichen wird, also müssen beide Stellen unterschiedlich sein, damit 1 unten rauskommt, wenn sie gleich sind gibt das 0 unten. Ist hier ganz gut erklärt finde ich.
1100 ^ 1001 ergibt 0101, weil (von links nach rechts verglichen), 1 XOR 1 = 0, 1 XOR 0 = 1, 0 XOR 0 = 0, und 0 XOR 1 = 1, ich habs kapiert!! Nur leider noch nicht wie man das jetzt ausnutzen kann...
ROT-13 mit 52b leider knapp an den Top20 vorbei. Erster versuch hatte ich ein Zeichen vergessen, deshalb fehlgeschlagen"2 hours of trial and error can save 10 minutes of manual reading."
Kommentar
-
Hab die Tic-Tac-Toe probiert, bin aber leider nur auf über 700b gekommen , upload hat deshalb nicht funktioniert, man kann bei öffentlichen nur welche hochladen, die besser als die des 1. ist, in diesem fall 153B, hab ich keine chance...
Beitrag editiert:
Inzwischen auf 677b runtergedrückt, ich glaub viel besser wirds nicht, ich brauch nen besseren Ansatz
Beitrag editiert2:
Hab das ganze ein bisschen geändert, bin jetzt bei 509b"2 hours of trial and error can save 10 minutes of manual reading."
Kommentar
-
ich mein das, was z.B. soPHP-Code:<?for($b=BOARDS;$b[$n];$n+=19){for($s=~ÿùóÿýûÿûý÷ñù÷õ÷÷ûõïóñïïó;$c=$s[$i];${$i++%8}|=$b[$n+ord($c)])$$i=H;for(;--$i;)ereg($$i,OX,$c);echo$c[0]?:None,~õ;}
ich hab halt das, was ich versucht hab, immer anders gelöst, und mehr bytes gebraucht natürlich..."2 hours of trial and error can save 10 minutes of manual reading."
Kommentar
-
Zitat von mermshaus Beitrag anzeigenHat jemand das Skript da verstanden, dass HELLO als ASCII-art ausgibt?
Mein zweiter Versuch war mit Lauflängen-Codierung. Endergebniss: Rohdaten 68Byte (benötige aber ""), gesamt 151Byte. Verwendet hab ich eine for Schleife und 2 str_repeat. Jetzt fehlen mir aber auch die Ideen zur Optimierung.
Hatte schon überlegt die Spalten zu Speichern (es sind nur 12 verschiedene) und dazu ein mapping wo welche Spalte genutzt wird. Jedoch müsste man für das mapping 4Bit pro Spalte verwenden. Das wären dann 38Byte + 12Byte. Leider gestaltet sich das Auslesen sehr unschön.
Zitat von mermshaus Beitrag anzeigenIch vermute, dass es der, der es auf 133 Byte gebracht hat, nicht mit 4-Bit-Blöcken kodiert, sondern vielleicht mit 3-Bit-Blöcken, falls das machbar ist. Das macht das Lesen zwar komplizierter, aber reduziert eben die Speichermenge für die Daten um ein Viertel. Ist aber nur eine Vermutung.
Kommentar
-
Nein, in dem Beispiel wird das Bild als Bitmaske abgespeichert. ' ## # #' => '00110101'. Das ist auch mein erster Anlauf bei der PHPGolf Challengen gewessen. Auf 7Bit codiert waren es 76Byte, mit Code 162Byte. Verwendet hab ich eine for Schleife die die Bits gezählt hat. Die Zeilenumbrüche haben den Code "aufgebläht".
Ich habe den Ansatz vorhin auch mal versucht. Das war heute mein erster Versuch mit 150 Byte, der nicht durchging. Ich dachte, „full trim“ bedeutet, dass die Zeilen einzeln noch mal getrimt werden, was aber nicht der Fall ist. Der zweite Versuch mit 150 Byte, der klappte, ist dann die Fortführung des RLE-Ansatzes von vor zwei Jahren. Da konnte ich vom alten Stand von 153 inzwischen noch 6 Byte rausquetschen. Unter anderem mit dieser invertierten Stringgeschichte. Die kannte ich zwar schon vorher, aber war zu faul, das Script noch mal anzufassen.
Ich vermute er hat was gemacht, an das keiner von uns denkt.
Kommentar
-
Mhm. Ist jedenfalls deprimierend, bei all dem Zeiteinsatz noch immer um Welten abgezogen zu werden."2 hours of trial and error can save 10 minutes of manual reading."
Kommentar
-
Zitat von mermshaus Beitrag anzeigenMhm. Ist jedenfalls deprimierend, bei all dem Zeiteinsatz noch immer um Welten abgezogen zu werden. Ich muss mir mal pack und so genauer angucken, glaube ich.
Ich hatte auch noch die Idee den String einfach per Hand zu packen/komprimieren. Also keine Logik, sondern nur ein $a="## ";$k=" #####";echo "$a$k$a $b#..." usw. Da komm ich aber nicht unter 250Byte.
Kommentar
-
Gekotzt hab ich gestern aber als ich festgestellt hab das am Ende auch noch Zeilenumbrüche stehen dürfen und das auch ein einfaches \n geht.
Ich hatte auch noch die Idee den String einfach per Hand zu packen/komprimieren. Also keine Logik, sondern nur ein $a="## ";$k=" #####";echo "$a$k$a $b#..." usw. Da komm ich aber nicht unter 250Byte."2 hours of trial and error can save 10 minutes of manual reading."
Kommentar
Kommentar