quote:Iedere maand wordt er op het forum van phpfreakz.nl een nieuwe opgave gepost.Beste PHP-ers,
--[ Wat is PHP Golf?
De bedoeling is een PHP script te maken met zo min mogelijk karakters.
Dus zo min mogelijk letters, nummers, spaties, newlines en dergelijke.
Met het script moet je een doelstelling bereiken.
We gaan ervan uit dat je de recenste PHP 4.x, op het moment 4.4,
versie hebt en standaard php.ini configuratie. Tenzij anders vermeld.
(Standaard: register_globals = off)
Het script moet op UNIX-gebaseerde en Windows systemen werken.
--[ Voor wie is PHP Golf?
De competitie is voor iedereen toegankelijk.
--[ Inzendingen
Je kunt je oplossing sturen naar:
phpgolf [at] gmail [dot] com
(Disclaimer: je e-mail zal niet worden gebruikt voor
spam of worden doorgegeven aan derden)
Discussieer hier over mogelijke oplossingen (en andere shit zodat t php voor dummies topic schoon blijft
)Eerdere opgaves :
Golf #1
Golf #2
Golf #3
Golf #4
Golf #5
Huidige opgave :
Golf #6
quote:--[ Doelstelling
Het script moet de volgende output genereren:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
BCDEFGHIJKLMNOPQRSTUVWXYZA
CDEFGHIJKLMNOPQRSTUVWXYZAB
DEFGHIJKLMNOPQRSTUVWXYZABC
EFGHIJKLMNOPQRSTUVWXYZABCD
FGHIJKLMNOPQRSTUVWXYZABCDE
GHIJKLMNOPQRSTUVWXYZABCDEF
HIJKLMNOPQRSTUVWXYZABCDEFG
IJKLMNOPQRSTUVWXYZABCDEFGH
JKLMNOPQRSTUVWXYZABCDEFGHI
KLMNOPQRSTUVWXYZABCDEFGHIJ
LMNOPQRSTUVWXYZABCDEFGHIJK
MNOPQRSTUVWXYZABCDEFGHIJKL
NOPQRSTUVWXYZABCDEFGHIJKLM
OPQRSTUVWXYZABCDEFGHIJKLMN
PQRSTUVWXYZABCDEFGHIJKLMNO
QRSTUVWXYZABCDEFGHIJKLMNOP
RSTUVWXYZABCDEFGHIJKLMNOPQ
STUVWXYZABCDEFGHIJKLMNOPQR
TUVWXYZABCDEFGHIJKLMNOPQRS
UVWXYZABCDEFGHIJKLMNOPQRST
VWXYZABCDEFGHIJKLMNOPQRSTU
WXYZABCDEFGHIJKLMNOPQRSTUV
XYZABCDEFGHIJKLMNOPQRSTUVW
YZABCDEFGHIJKLMNOPQRSTUVWX
ZABCDEFGHIJKLMNOPQRSTUVWXY
Nu mag jij het script programmeren en liefst zo kort mogelijk.
--[ Deadline:
De deadline is over 8 dagen.
Vrijdag 19:00 4 november 2005
-----
quote:Post in dit topic vragen/suggesties.
GEEN OPLOSSINGEN!
het lijkt mij dat een \n korter is en in een terminal levert dat toch echt dezelfde output op 
Dan zit ik weer op 52 tekens
[ Bericht 9% gewijzigd door crisp op 30-10-2005 00:06:28 ]
is dat incl <br> en ?> ?Het weglaten van ?> geeft namelijk een notice, en dat mag nog.
Het weglaten van ?> geeft geen notice. Mijn scriptje werkt zelfs helemaal zonder notices
quote:Warnings en notices mogen, want die worden niet getoond.Op zondag 30 oktober 2005 09:54 schreef Chandler het volgende:
ah... dus het hoeft code technisch dus niet perfect te zijn
quote:Ik zie het jaOp zondag 30 oktober 2005 10:06 schreef SuperRembo het volgende:
Als je de ?> weglaat dan moet je wel afsluiten met een ;, dus het scheelt maat 1 teken.
Het weglaten van ?> geeft geen notice. Mijn scriptje werkt zelfs helemaal zonder notices
heb namelijk alle notice etc aan staan quote:Dan heb je vast nog geen 50 tekens.Op zondag 30 oktober 2005 10:17 schreef Chandler het volgende:
hier echt wel
quote:Op zondag 30 oktober 2005 10:54 schreef Swetsenegger het volgende:
He light, heb je je ZCE gehaald?
Het staat al een ruime week in m'n sig, maar dat valt niemand op
quote:Gefeliciteert!Op zondag 30 oktober 2005 10:58 schreef Light het volgende:
[..]
Het staat al een ruime week in m'n sig, maar dat valt niemand op
Je moet 'm ook klikbaar maken naar je certificaat he
quote:DankOp zondag 30 oktober 2005 11:03 schreef Swetsenegger het volgende:
[..]
Gefeliciteert!
Je moet 'm ook klikbaar maken naar je certificaat he
En klikbaar maken kan altijd nog
quote:Textonly heeft geen sigsOp zondag 30 oktober 2005 10:58 schreef Light het volgende:
[..]
Het staat al een ruime week in m'n sig, maar dat valt niemand op
Gefeliciteerd. Welke ben je? (yellow pages)
quote:Dank. Dit ben ik.Op maandag 31 oktober 2005 11:38 schreef Roonaan het volgende:
[..]
Textonly heeft geen sigs
Gefeliciteerd. Welke ben je? (yellow pages)
Heeft iemand nog een briljante oplossing (onder de 50 tekens)?
De oplossing van crisp:
| 1 |
Mijn oplossing:
| 1 |
De complete uitslag
Het zat er dik in dat onze oplossingen nagenoeg identiek zouden zijn. Dit zou ook nog kunnen - dan print je alleen geen <br> op het eind:
| 1 |
| 1 |
Maar ik heb niets ingestuurd, omdat ik het flauw vond om een oplossing in te sturen die afgeleid was van een (grotere) oplossing die al eerder hier gepost was. snap nog steeds niet hoe dat met die chr precies in elkaar zat maar ok!? was niet bijster lastig deze quote:53 vind ik ook wel leuk eigenlijkOp zaterdag 3 december 2005 23:10 schreef SuperRembo het volgende:
Ok 56 en dan hou je nu op he.
quote:En volledig functioneel? Zou tof zijn
quote:Ja, uiteraard
quote:Er staat in de opdracht dat je de functie eval() niet mag gebruiken.Op zondag 4 december 2005 23:53 schreef Ro�a� het volgende:
een preg met /e valt onder eval toch?
quote:Nee, maar ik vind eigenlijk van wel. Weet niet hoe de source code van preg_replace() eruit ziet maar ik gok er heel erg op dat het in feite een interne eval()-aanroep is.Op zondag 4 december 2005 23:53 schreef Ro�a� het volgende:
een preg met /e valt onder eval toch?
quote:Ik ookOp maandag 5 december 2005 01:14 schreef Ro�a� het volgende:
52.
quote:zag het net idd @ phpfz
Roonan, heb je je 52 tekens inzending getest op juiste output met de in de opdracht gegeven sommetjes?
quote:Was toch gewoon een vraag?Op maandag 5 december 2005 01:18 schreef Wifibro het volgende:
He jongens, we hadden gevraagd om geen oplossingen te geven, nou zie ik toch weer een heel duidelijke aanwijzing!
Voor hetzelfde geld had ik gevraagd of je antwoord wel of niet crossbrowser compatible moest zijn..
quote:jups.Roonan, heb je je 52 tekens inzending getest op juiste output met de in de opdracht gegeven sommetjes?
quote:Alsof op phpfreakz geen aanwijzingen worden gegeven zeker.Op maandag 5 december 2005 01:18 schreef Wifibro het volgende:
He jongens, we hadden gevraagd om geen oplossingen te geven, nou zie ik toch weer een heel duidelijke aanwijzing!
quote:Ik heb de oplossing van Roonaan niet gezien, maar ik denk dat zijn oplossing dezelfde is als die van mij, en die is getest met de gegeven sommen.Roonan, heb je je 52 tekens inzending getest op juiste output met de in de opdracht gegeven sommetjes?
quote:Op PFZ is geen functie genoemd.Light:
Alsof op phpfreakz geen aanwijzingen worden gegeven zeker.
quote:Tjee, wat goed....Ik heb de oplossing van Roonaan niet gezien, maar ik denk dat zijn oplossing dezelfde is als die van mij, en die is getest met de gegeven sommen.
quote:Ik heb hier ook geen volledige functie genoemd zien worden eigenlijk. Ja, eval(), met als opmerking dat die niet gebruikt mag worden.Op maandag 5 december 2005 01:32 schreef Wifibro het volgende:
[..]
Op PFZ is geen functie genoemd.
[..]
quote:Zoveel keuze is er niet bij heel weinig tekens hoorTjee, wat goed....
quote:Roönaän had het over een functie met een bepaalde modifier die alleen bij één functie kan voorkomenOp maandag 5 december 2005 01:39 schreef Light het volgende:
[..]
Ik heb hier ook geen volledige functie genoemd zien worden eigenlijk. Ja, eval(), met als opmerking dat die niet gebruikt mag worden.
quote:DetailOp maandag 5 december 2005 01:42 schreef JeRa het volgende:
[..]
Roönaän had het over een functie met een bepaalde modifier die alleen bij één functie kan voorkomen
-r-
Ik wacht nog op een briljante zet van SUperRembo
Even kijken op phpfreakz, ik had 'm gemist. En 52 tekens ga ik sowieso niet halen vrees ik.
quote:Roonaan geeft toch geen oplossing? Dit soort opmerkingen zie je ook op phpfreakz staan in de diverse golven. De mensen welke weten wat /e doet, komen er zelf ook wel opOp maandag 5 december 2005 01:18 schreef Wifibro het volgende:
He jongens, we hadden gevraagd om geen oplossingen te geven, nou zie ik toch weer een heel duidelijke aanwijzing!
quote:Ik ook niet. Meestal komt het toch op een reguliere expressie uit, maar ik probeer de uislagen altijd wel te begrijpen. Je leert er heel veel van.Op maandag 5 december 2005 08:30 schreef Chandler het volgende:
Ik wacht rustig af... ken het zelf toch niet...
Ik wil dan ook voorstellen dat de Fokkers (welke trouwens weer bovenaan staan en kortere inzendingen hebben dan de PHPfreakz) hun oplossingen hier in detail uitleggen als ze dat willen. Voor ons mindere geesten is dat best handig
. Het enige dat ik kwijt wil ik dat ik geen enkele ruimte meer zie om het nog korter te maken.quote:UiteraardOp maandag 5 december 2005 08:45 schreef Light het volgende:
Uitleggen komt pas nadat de wedstrijd is afgesloten
quote:Is er eigenlijk een system function die dit kan? of zou dat niet mogenOp maandag 5 december 2005 08:45 schreef Light het volgende:
Uitleggen komt pas nadat de wedstrijd is afgesloten
quote:Ik zou er zo geen weten. De logische namen kan ik hier iig niet vindenOp maandag 5 december 2005 09:03 schreef Ro�a� het volgende:
[..]
Is er eigenlijk een system function die dit kan? of zou dat niet mogen
quote:ik ook niet, maar ik ben ook niet zo'n dosfreak.Op maandag 5 december 2005 09:13 schreef Light het volgende:
[..]
Ik zou er zo geen weten. De logische namen kan ik hier iig niet vinden
Overigens is dat een externe binary en geen system function, met die laatste ga je het sowieso niet redden gezien de grote verschillen tussen elk OS
quote:Nou voorlopig zit ik nog op de 57 en zie ik nog steeds geen ruimte voor verbeteringOp maandag 5 december 2005 08:26 schreef Swetsenegger het volgende:
Ik wacht nog op een briljante zet van SUperRembo
quote:Tja, als ik een scriptje op mijn server host en simpelweg remote de inhoud van het resultaat opvraag kan ik ook alles oplossen, en het zal ook niet mogen, maar het staat niet in de regels!
Ik krijg 'm maar niet korter dan 54. Elke ingeving die ik nu nog krijg leidt steevast tot een paar extra tekens. Of een Parse Error. Ik ben weer heel benieuwd!
minder had gekunt als de submit-button geen name-attribuut had gehad
quote:Nee hoorOp dinsdag 6 december 2005 22:08 schreef crisp het volgende:
minder had gekunt als de submit-button geen name-attribuut had gehad
maakt weinig uit of die submit-button er is.quote:Ook wel *tak tik*Op vrijdag 9 december 2005 22:03 schreef Ro�a� het volgende:
*tik tak* ;-)
quote:niet per ongeluk get ipv post gebruikt?
*naarstig op zoek is naar kortere oplossing*
crosspost:
Voor een volgende Golf zou ik wel eens iets echt spannends willen zien, bijvoorbeeld het schrijven van een eigen compressie-algorithme. Je zou dan een standaard tekst van zeg zo'n 2000 karakters losless moeten compressen en de output base64_encoded moeten outputten.
Je score kan dan berekent worden door <bytes originele tekst> - <bytes output> - <bytes van je code>
Dus stel je weet 2000 bytes terug te brengen naar 1300 (base64_encoded) met een 300 byte script dan heb je 400 punten. Uiteraard moet je ook een script leveren die de output weer kan omzetten naar de originele tekst.
Ene Peter zegt dat dat veel meer tijd zou kosten voor deelnemers, maar stiekum denk ik dat het minder deelnemers zou trekken omdat het simpelweg te moeilijk is voor de meesten
quote:Ik heb even gekeken, maar op basis van mijn oplossing van 52 tekens zie ik echt niet waar er nog een teken te besparen is.Op vrijdag 9 december 2005 23:51 schreef Ro�a� het volgende:
[..]
niet per ongeluk get ipv post gebruikt?
*naarstig op zoek is naar kortere oplossing*
quote:Dat klopt, het is zelfs een functie in PHP. Het is echter noodzakelijk om je output 'toonbaar' te maken aangezien compressie meestal binaire data oplevert. Daarbij is het verlies door base64 (33%) juist weer een extra uitdaging om je compressie zo optimaal mogelijk te maken (standaard LZW doet al gauw zo'n 50%)Op zaterdag 10 december 2005 00:01 schreef Light het volgende:
Voor base64 encoden is volgens mij al een standaardalgoritme. En je kunt vooraf zeggen hoeveel bytes een resultaat wordt (overigens is een base64 resultaat groter dan het origineel). Maar een optie voor het verkleinen van een standaarddocument (tekst ofzo) zou op zich wel een uitdaging zijn
quote:Dat zouden ze eigenlijk opnieuw moeten proberen, nu doet Fok! mee en iedereen weet dat je voor PHP-vraagstellingen hier moet zijn en niet bij PHPFreakzOp zaterdag 10 december 2005 11:05 schreef SuperRembo het volgende:
Zo'n soort opgave is er al geweest: PHP Golf 3. Die opgave heeft geen inzendingen opgeleverd.
quote:Overigens was dit bedoeld als waarschijnlijk veel te ver gezochte hint
| 1 |
Ik heb er dus echt geen moment aan gedacht om de parameters om te wisselen (ondanks de hint van Light).
Maar hij kan nog korter
| 1 |
49 tekens. bcadd() rondt trouwens naar beneden af.
[ Bericht 19% gewijzigd door SuperRembo op 11-12-2005 22:11:10 ]
het voorbeeld '3+4*5/3' zal dus 9.66 geven ipv 9.67 - daarmee voldoet het dus al niet aan de regels...
quote:Die hint van mij was misschien ook niet echt duidelijkOp zondag 11 december 2005 22:03 schreef SuperRembo het volgende:
Het winnende scriptje van crisp:
[ code verwijderd ]
Ik heb er dus echt geen moment aan gedacht om de parameters om te wisselen (ondanks de hint van Light).
Maar hij kan nog korter
[ code verwijderd ]
49 tekens. bcadd() rondt trouwens naar beneden af.
| 1 |
Zo dan, 48 tekens
quote:Ja, door afkappen ipv afronden.
quote:Hoe apart, waarom daar niet?Op zondag 11 december 2005 22:34 schreef SuperRembo het volgende:
Die truck met de X werkt in dit geval niet
| 1 |
Kan optellen, aftrekken EN vermenigvuldigen
de formatted string is me sowieso niet erg duidelijk
En die preg_replace is wat flauw natuurlijk. De constante X evalueert naar een lege string (omdat de constante X niet bestaat) en op die string wordt een lege expressie losgelaten. NOrmaal gesproken gebruik je delen van de expressie weer in de tweede variabele (met $0 of $1 bijvoorbeeld), maar hier dus niet. De /e modifier bij de expressie geeft aan dat de resultaatsting (de tweede parameter van de functie preg_replace dus) moet worden geevalueerd als php code.
End ten slotte levert het laatste element van de array op. De volgorde van de elementen in het formulier was met opzet gekozen.
quote:Ik ben wel benieuwd naar je oplossing, volgens mij wordt ie niet genoemd op phpfreakz.Op maandag 5 december 2005 01:46 schreef Ro�a� het volgende:
Is er ook een prijs voor meest originele inzending. Heb nog een leuke gevonden, die is echter wel 60 tekens, dus niet helemaal optimaal.
quote:Roonaan wordt daar helemaal niet genoemd, vreemd genoeg.Op zondag 11 december 2005 23:05 schreef SuperRembo het volgende:
[..]
Ik ben wel benieuwd naar je oplossing, volgens mij wordt ie niet genoemd op phpfreakz.
quote:Ja...Op zondag 11 december 2005 23:02 schreef Light het volgende:
printf verwacht een string met format specifiers, en een bijpassend aantal variabelen. Zie sprintf voor de mogelijkheden. %.2f geeft iig aan dat de parameter een floating point variabele met een precisie van twee decimalen is. Da's precies wat de bedoeling is
En die preg_replace is wat flauw natuurlijk. De constante X evalueert naar een lege string (omdat de constante X niet bestaat) en op die string wordt een lege expressie losgelaten. NOrmaal gesproken gebruik je delen van de expressie weer in de tweede variabele (met $0 of $1 bijvoorbeeld), maar hier dus niet. De /e modifier bij de expressie geeft aan dat de resultaatsting (de tweede parameter van de functie preg_replace dus) moet worden geevalueerd als php code.
End ten slotte levert het laatste element van de array op. De volgorde van de elementen in het formulier was met opzet gekozen.
Ik begrijp er nu nog geen ruk van. Ik zie dus een regelcode welke feitelijk niets doet, maar wel de juiste output geeft
Geef eens een voorbeeldje met input.
wacht even, je gaat de input dus gewoon behandelen als php code, welke dus gewoon 2*3/4 uit zal voeren en de printf geeft die uitkomst als float met 2 decimalen.
Klopt dit?
quote:Zo werkt het niet.Op zondag 11 december 2005 23:02 schreef Light het volgende:
En die preg_replace is wat flauw natuurlijk. De constante X evalueert naar een lege string (omdat de constante X niet bestaat) en op die string wordt een lege expressie losgelaten.
X is onbekend en wordt daarom gezien als constante string 'X'.
De // regexp matcht het begin en eind van de string 'X' (denk ik
).Het begin en eind wordt gereplaced door de uitkomst van de eval van de input ('3+4*5/3' => 9.6666666666667). Dit levert de string '9.6666666666667X9.6666666666667'.
Printf verwacht een float, en converteert daarom de string naar een float, dat levert 9.6666666666667. Dat getal wordt afgerond op 2 decimalen en geconverteerd naar een string: '9.67'.
quote:Nee, X wordt gezien als een constante die leeg is. Als het als een string zou worden gezien zou de regexp niet meer werken. Maar dan snap ik nog steeds niet waarom het niet werkt in de code van LightOp zondag 11 december 2005 23:16 schreef SuperRembo het volgende:
[..]
Zo werkt het niet.
X is onbekend en wordt daarom gezien als constante string 'X'.
De // regexp matcht het begin en eind van de string 'X' (denk ik
quote:CorrectOp zondag 11 december 2005 23:16 schreef Swetsenegger het volgende:
wacht even, je gaat de input dus gewoon behandelen als php code, welke dus gewoon 2*3/4 uit zal voeren en de printf geeft die uitkomst als float met 2 decimalen.
Klopt dit?
quote:Owja, als ik printf weghaal uit de functie en gewoon 2+3 als invoer geef dan krijg ik 5X5 als uitvoer. En X is natuurlijk geen nummer, dus bij de convertering naar een getal verdwijnt die.Op zondag 11 december 2005 23:16 schreef SuperRembo het volgende:
[..]
Zo werkt het niet.
X is onbekend en wordt daarom gezien als constante string 'X'.
De // regexp matcht het begin en eind van de string 'X' (denk ik
Het begin en eind wordt gereplaced door de uitkomst van de eval van de input ('3+4*5/3' => 9.6666666666667). Dit levert de string '9.6666666666667X9.6666666666667'.
Printf verwacht een float, en converteert daarom de string naar een float, dat levert 9.6666666666667. Dat getal wordt afgerond op 2 decimalen en geconverteerd naar een string: '9.67'.
quote:Op zondag 11 december 2005 23:05 schreef SuperRembo het volgende:
[..]
Ik ben wel benieuwd naar je oplossing, volgens mij wordt ie niet genoemd op phpfreakz.
| 1 |
Maar die is ongeldig, aangezien je geen round mocht gebruiken.
[ Bericht 7% gewijzigd door Roonaan op 11-12-2005 23:34:42 ]
quote:Round levert bij 2+8 de uitkomst 10, niet 10.00.Op zondag 11 december 2005 23:47 schreef SuperRembo het volgende:
Wel creatief, maar die gebruikt dus intern ook eval. Ik zie nergens dat je round niet mocht gebruiken.
quote:het schijnt dat er áltijd twee cijfers achter de komma moest hebben, round doet dat niet, die geeft gewoon 2.5 voor 5/2, ipv 2.50.Op zondag 11 december 2005 23:47 schreef SuperRembo het volgende:
Wel creatief, maar die gebruikt dus intern ook eval. Ik zie nergens dat je round niet mocht gebruiken.
Anders is er ook een 45 character oplossing met
| 1 |
quote:jups. mijn fout. misread de opdracht klaarblijkelijk.Op zondag 11 december 2005 23:47 schreef Light het volgende:
En je oplossing van 52 tekens, was dat ook met een round?
quote:Dat round() iets anders doet dan de %.2f van printf() betekent niet dat je round() niet mag gebruiken.Op zondag 11 december 2005 23:48 schreef Light het volgende:
[..]
Round levert bij 2+8 de uitkomst 10, niet 10.00.
Men neme dit formulier:
| 1 2 3 4 5 | <form method="POST" action="base64.php"> <input type="text" name="input"> <input type="submit" value="base64"> </form> |
Schrijf nu base64.php zo kort mogelijk; de output moet hetzelfde zijn als de output van base64_encode() maar deze functie mag je uiteraard niet gebruiken
Verder dezelfde regels als voor reguliere Golfs, oplossingen mogen naar crisp@xs4all.nl (privacy gewaarborgt). Einddatum is Zondag 18 december 18:00 uur.
Om het scherp te zetten: ik heb zelf een oplossing van 228 karakters
quote:In dit geval wel. Uit de opdracht:Op zondag 11 december 2005 23:49 schreef JeRa het volgende:
[..]
Dat round() iets anders doet dan de %.2f van printf() betekent niet dat je round() niet mag gebruiken.
quote:Output moet bestaan uit twee decimalen en de punt wordt als scheidingsteken gebruikt.
quote:Dus volgens jou mag deze oplossing niet?Op zondag 11 december 2005 23:52 schreef Light het volgende:
[..]
In dit geval wel. Uit de opdracht:
[..]
<?=printf('%.2f',round(preg_replace('//e',end($_POST),''),2));
(naast het feit dat het dubbelop is)
quote:Op maandag 12 december 2005 00:01 schreef JeRa het volgende:
[..]
Dus volgens jou mag deze oplossing niet?
<?=printf('%.2f',round(preg_replace('//e',end($_POST),''),2));
(naast het feit dat het dubbelop is)
quote:Als kortste oplossing komt die niet in aanmerkingOp maandag 12 december 2005 00:01 schreef JeRa het volgende:
[..]
Dus volgens jou mag deze oplossing niet?
<?=printf('%.2f',round(preg_replace('//e',end($_POST),''),2));
(naast het feit dat het dubbelop is)
quote:Ik heb 'm nu in 283 karakters. 228 is wel erg weinig zegOp zondag 11 december 2005 23:51 schreef crisp het volgende:
Iemand zin in een tussendoortje?
Men neme dit formulier:
[ code verwijderd ]
Schrijf nu base64.php zo kort mogelijk; de output moet hetzelfde zijn als de output van base64_encode() maar deze functie mag je uiteraard niet gebruiken
Verder dezelfde regels als voor reguliere Golfs, oplossingen mogen naar crisp@xs4all.nl (privacy gewaarborgt). Einddatum is Zondag 18 december 18:00 uur.
Om het scherp te zetten: ik heb zelf een oplossing van 228 karakters
quote:De functie die je dan moet hebben heet wel printf, maar de argumenten zijn iets anders (en bieden ook meer mogelijkheden).Op maandag 12 december 2005 22:51 schreef Chandler het volgende:
in basic ofzo kon je altijd printen met printf "##.##", getal maar dat werkt blijkbaar niet in PHP
quote:zó ingewikkeld om php.net/printf is het toch niet?Op maandag 12 december 2005 22:51 schreef Chandler het volgende:
in basic ofzo kon je altijd printen met printf "##.##", getal maar dat werkt blijkbaar niet in PHP
quote:Dat vind ik al een aardige prestatieOp maandag 12 december 2005 22:06 schreef SuperRembo het volgende:
[..]
Ik heb 'm nu in 283 karakters. 228 is wel erg weinig zeg
Zelf had ik uiteraard al een JS implementatie liggen die vrij ver doorontwikkeld was; heerlijk bitshifting enzo
quote:Nee, dat is een implementatie van base64 en niet zozeer het algoritme zelf. Zo is het uitsplitsen naar lijnen van max 76 karakters geen karakteristiek van base64 zelf, dus ook niet nodig (base64_encode() doet dat ook niet).Op dinsdag 13 december 2005 00:46 schreef JeRa het volgende:
Ik neem aan dat base64.php zich volledig aan het RFC 2045 moet houden?
De padding-karakters daarentegen zijn wel onderdeel van het algoritme.
ben ermee bezig.edit: niet dus, hij hield geen rekening met één bepaalde character
edit2: Foutje eruit gewerkt, nu op 243 tekens.
edit3:
nog een béétje verder...[ Bericht 23% gewijzigd door JeRa op 13-12-2005 15:58:43 ]
Het is er niet netter op geworden though..
quote:Zat ik net eentje onder je vorige schepsel, kom je met dit nieuwsOp dinsdag 13 december 2005 16:30 schreef crisp het volgende:
Ik zit zelf inmiddels op 208
Het is er niet netter op geworden though..
nog even verder prutsen Het was voor mij ook weer een inpuls om goed naar mijn eigen implementatie te kijken en die nog wat verder te optimaliseren.
Verwacht in elk geval ook uitgebreide uitleg van mij na afloop; dat wordt een leuk lesje bitwise rekenen
Met een kleine aanpassing zit ik nu op 279.
quote:Ik neem aan dat zo'n beetje iedereen dezelfde bitwise operaties uitvoert om dit een beetje compact te kunnen uitvoeren. Dan kom ik nóg met geen mogelijkheid aan de 230-Op dinsdag 13 december 2005 23:29 schreef crisp het volgende:
dat wordt een leuk lesje bitwise rekenen
quote:Mwa, ik kan daar nog wel wat variaties op bedenken hoor.Op dinsdag 13 december 2005 23:43 schreef JeRa het volgende:
[..]
Ik neem aan dat zo'n beetje iedereen dezelfde bitwise operaties uitvoert om dit een beetje compact te kunnen uitvoeren. Dan kom ik nóg met geen mogelijkheid aan de 230-
Een groot deel van mijn code zit in het initialiseren van de geldige karakters (57 bytes). Daarna volgt het daarwerkelijke algoritme (78 bytes) en het verwerken van de 'rest' en padding (45 bytes). Input en output verwerking en nog wat verplichte overhead zit dan nog op 28 bytes...
quote:Je geeft me een geweldig idee *uitwerkt*Op dinsdag 13 december 2005 23:48 schreef crisp het volgende:
[..]
Mwa, ik kan daar nog wel wat variaties op bedenken hoor.
Een groot deel van mijn code zit in het initialiseren van de geldige karakters (57 bytes). Daarna volgt het daarwerkelijke algoritme (78 bytes) en het verwerken van de 'rest' en padding (45 bytes). Input en output verwerking en nog wat verplichte overhead zit dan nog op 28 bytes...
er zit wel degelijk verschil in ja, aangezien ik het daadwerkeiljke algoritme en het verwerken van rest/padding in één stuk heb beschreven Ik stel mijn aantal bij trouwens, zit weer op 272
dit omdat ik het niet vond kunnen om een hoop niet-ascii tekens in m'n script te gooien. En dat waren er een heleboel. mét de niet-ascii tekens zit ik nu op 213.[ Bericht 9% gewijzigd door JeRa op 14-12-2005 00:18:14 ]
quote:Ben erg benieuwd naar de resultaten straksOp woensdag 14 december 2005 00:52 schreef crisp het volgende:
Er zijn 2 algemene approaches voor dit probleem. De meest voorkomende is dat je 3 bytes gelijktijdig omzet naar base64 (4 bytes); ik doe echter een byte-naar-bit approach waarbij ik een remainder bijhou
ik zit nu op 262 en 206 tekens. En nu ga ik slapen. 
quote:Enig idee hoeveel tekens een return-statement inneemt?Op woensdag 14 december 2005 08:46 schreef SuperRembo het volgende:
Misschien is het een idee om de opdracht iets aan te passen. Maak de body van een functie, in plaats van een heel script dat een form verwerkt. Dan hou je dingen als pos($_POST) er buiten, die kent iedereen toch wel.
Ik kan wel raden welke approach je hebt genomen dan; omzetten naar base128 (7 bits naar een byte) zou wel lastiger zijn dan denk ik?
Tsja, voor de input/output zal iedereen wel zo'n beetje hetzelfde gebruiken, dus of we het omzetten naar een functie boeit dan ook niet zo...
quote:Nou nee, ik zit op 262 maar bij dat aantal is het nog goed mogelijk om de boel leeg te laten lopenOp woensdag 14 december 2005 09:57 schreef crisp het volgende:
Oeh, 206
Ik kan wel raden welke approach je hebt genomen dan; omzetten naar base128 (7 bits naar een byte) zou wel lastiger zijn dan denk ik?
edit: 254 tekens
edit2: 245 tekens
maar het wordt krap.[ Bericht 7% gewijzigd door JeRa op 14-12-2005 18:53:08 ]
ord(chr(0)) === ord('')
Oftewel, de waarde van een binary null is hetzelfde als de waarde van een lege string.
Op 221 tekens nu trouwens. De riem wordt strak aangetrokken
[ Bericht 12% gewijzigd door JeRa op 14-12-2005 19:41:24 ]
quote:Na de einddatum wellicht?
Ik zit nu op
[ Bericht 8% gewijzigd door JeRa op 14-12-2005 22:53:38 ]
Ik ben erg benieuwd, ik denk dat hier best wel wat leuke dingen uit gaan komen
quote:Heb je eigenlijk al een idee op welke strings je de inzendingen gaat testen? Het zou namelijk best wel eens zo kunnen zijn dat een scriptje schrikt van een lege string, eentje met niet-ascii tekens, etcOp woensdag 14 december 2005 23:39 schreef crisp het volgende:
JeRa is goed bezig zo te horen
Ik ben erg benieuwd, ik denk dat hier best wel wat leuke dingen uit gaan komen
(tot nu toe zit ik nog safe, gelukkig heb ik een kortere workaround gevonden voor het probleem met ord() zoals ik een paar posts hierboven had beschreven).edit: handige eigenschap van de taal die PHP heet brengt mijn aantal nu naar 217. En nou stop ik voor vandaag
de kleine versie van m'n script staat op 202 tekens.edit2: spontane ingeving brengt me naar 214. Ooit moet ik leren stoppen.
[ Bericht 8% gewijzigd door JeRa op 14-12-2005 23:56:25 ]
quote:Mja, ik zat vooral met dat formulier in gedachten ja. De drempel is dan wat lager om het alleen met user(/ascii)input te proberen ipv ook binaire dataOp donderdag 15 december 2005 00:10 schreef crisp het volgende:
base64_encode is natuurlijk primair juist bedoelt om binaire data te transporteren, dus daar zal het zeker mee overweg moeten kunnen (hoewel dat via een form wat lastiger te testen is). Een lege string zou gewoon ook een lege string terug moeten geven
zit nu trouwens op [ Bericht 2% gewijzigd door JeRa op 15-12-2005 11:57:54 ]
quote:Oh die van mij zit prima in elkaarOp donderdag 15 december 2005 11:59 schreef crisp het volgende:
als je algoritme goed in elkaar zit zou binaire input geen probleem mogen zijn
maar af en toe erger ik me dus aan het gedrag van PHP die ord() altijd iets laat teruggeven waardoor een lege string gelijk wordt gesteld aan chr(0). Dat hebben ze bij strpos() toch beter gedaan nu heb ik dat nu niet meer nodig, dus ik ga maar eens verder met het verkleinen van m'n script. hij kon niet overweg met chr(48), ik denk dat een aantal mensen wel weet waarom. Weg 208 tekens Aangezien ik natuurlijk nu inspiratie op zou kunnen doen daaruit hou ik het bij mijn 195-er, hoewel het een heel andere approach is dan degene die ik heb genomen
quote:Zeg eens, je hebt de wedstrijd verzonnen terwijl je al een vrij geoptimaliseerde versie had liggen, en dan doe je nog mee ook?Op vrijdag 16 december 2005 18:10 schreef crisp het volgende:
En de eerste inzending is binnen
Aangezien ik natuurlijk nu inspiratie op zou kunnen doen daaruit hou ik het bij mijn 195-er, hoewel het een heel andere approach is dan degene die ik heb genomen
quote:Ik weet zeker dat jij er wel onder komtOp zaterdag 17 december 2005 00:45 schreef JeRa het volgende:
[..]
Zeg eens, je hebt de wedstrijd verzonnen terwijl je al een vrij geoptimaliseerde versie had liggen, en dan doe je nog mee ook?
quote:I'll try, maar ik moet nog eerst het probleem oplossen dat ie gvd één tekentje uit een subset van 256 tekentjes niet piktOp zaterdag 17 december 2005 01:08 schreef crisp het volgende:
[..]
Ik weet zeker dat jij er wel onder komt
Puur uit nieuwsgierigheid; ik test mijn methode door vele malen een random input string van willekeurige lengte en willekeurige inhoud (bytes van 0 t/m 255) te genereren en de output van mijn methode te vergelijken met de output van base64_encode(). Heb jij ook iets dergelijks gedaan of bewijs je je code? (ik deed het eerst met het laatste totdat ik erachter kwam dat PHP eigenlijk niet zo heel consequent is)
De JS versie van mijn algoritme gebruik ik echter voor binaire strings en die heb ik meermalen met base64_encode() vergeleken.
quote:Ik had dus ook eerst een werkende versie die ik vervolgens ging optimaliserenOp zaterdag 17 december 2005 13:49 schreef crisp het volgende:
Ik heb tot nog toe enkel getest met wat random strings - niet echt uitputtend yet.
De JS versie van mijn algoritme gebruik ik echter voor binaire strings en die heb ik meermalen met base64_encode() vergeleken.
waarna bleek dat bepaalde optimalisaties ervoor zorgden dat het in het geheel niet meer werkten als ie een bepaald teken tegenkwam. Ben benieuwd naar de oplossingen morgen Ik zit nu op 214 tekens.
[ Bericht 3% gewijzigd door JeRa op 17-12-2005 14:28:59 ]
Een aantal dingen heb je korter opgelost dan ik; als ik dat in mijn script zou integreren kom ik op 182
(maar ik doe uiteraard voor spek en bonen mee)quote:Tja, maar ik doe in essentie iets verkeerd.Op zaterdag 17 december 2005 21:31 schreef crisp het volgende:
Ziet er goed uit JeRa
Een aantal dingen heb je korter opgelost dan ik; als ik dat in mijn script zou integreren kom ik op 182
heb me vannacht dood lopen staren op substituties, extracties, transponaties en deleties, maar ik zag niets meer | 1 2 3 4 5 | echo eval($code); //ik verwacht 2 - klopt echo preg_replace('//e', $code, ''); //ik verwacht 2 - maar krijg 1! |
Het blijkt dat intern preg_replace() zend_string_eval() aanroept, die kennelijk de eerste de beste evaluatie retourneert. Dit in tegenstelling tot eval(), die de code écht als PHP code uitvoert. Een 'echo' kun je bij de preg_replace()-versie dan ook niet uitvoeren.
En dit:
| 1 2 3 4 5 6 7 8 9 10 | $b = "0"; if ($a) { echo '$a is!'; } if ($b) { echo '$b is!'; } |
Een "0", dat is toch hartstikke logisch, die wordt gecast naar de integer 0 en vervolgens ziet PHP dat als de conditie 'false'
en dat terwijl een wérkelijke nul-waarde (chr(0)) gewoon wél wordt gepikt!Oh, en nog die ene waar ik het al eerder over had:
| 1 2 3 | echo 'just great!'; } |
Oftewel, genoeg valkuilen.
[ Bericht 13% gewijzigd door JeRa op 17-12-2005 23:43:31 ]
Dat wordt morgen een flinke lap uitleg schrijven
quote:Leuk idee, ik heb alleen geen tijd om zoiets helemaal op te zetten en te ontwerpen. Ik kan wel een subdomein van gmta.nl leveren (golf.gmta.nl bijvoorbeeld) en alles wat je nodig zou kunnen hebben op een webserverOp zondag 18 december 2005 11:44 schreef Chandler het volgende:
Waarom begint GOLF of jullie niet een globale website voor wedstrijden die een maand duren, dan heb je er wel 12 per jaar en kun je echt zien hoe divers mensen programmeren... (scripten).
quote:Dat valt ook weer mee, denk ik zo. De ingrediënten:Op zondag 18 december 2005 15:12 schreef SuperRembo het volgende:
Het is een hoop werk om te maken en om te onderhouden, terwijl een topic ook prima voldoet.
- een layout
- een gebruikerssysteem met minimale rechten (user/admin) + registreersysteem
- een topicsysteem (om nieuwe wedstrijden te starten)
- een reageersysteem (zodat mensen kunnen reageren)
Voila
ik heb medelijden met Crisp en de onbegrijpelijke stukken code waar hij lappen tekst over moet schrijven quote:Dat valt wel mee hoor, ik begrijp de code primaOp zondag 18 december 2005 19:12 schreef JeRa het volgende:
Zondag 18:00! Geweest
Ik ben al begonnen en zal het in de loop van de avond af proberen te maken
quote:Tof.Op zondag 18 december 2005 19:13 schreef crisp het volgende:
[..]
Dat valt wel mee hoor, ik begrijp de code prima
Ik ben al begonnen en zal het in de loop van de avond af proberen te maken
Wat vind je van het idee van Chandler trouwens? en dat code werk wil ik ook wel doen... alleen de opgaven ben ik zekers NIET goed in quote:Zo, nog even wat dingen geregeld voor de aankomst van onze zoon overmorgen maar nu zit ik er echt voorOp zondag 18 december 2005 19:19 schreef JeRa het volgende:
[..]
Tof.
Ik vind het idee van Chandler wel aardig, maar ben zelf bang dat op een gegeven moment de aandacht van een dergelijke opzet toch wel zal gaan verslappen. Ik heb nu een paar keer meegedaan met de Golfs en in het verleden ook wel aan een aantal andere contests meegedaan, maar ik zie aan mezelf dat ik het op een gegeven moment ook wel weer gezien heb en er dan weer een tijd niet naar omkijk...
Verwacht van mij voorlopig ook niet teveel input aangezien ik de komende tijd druk ben met andere zaken
Golf Intermezzo: Base64 encoding
Base 64 is letterlijk een numerings systeem met een basis van 64, de hoogste macht van 2 die met standaard ASCII karakters kan worden weergegeven. Base64-encoding wordt daarom voornamelijk gebruikt om binaire data te encoden voor gebruik in transport-formaten die enkel ASCII-karakters kunnen bevatten zoals bijvoorbeeld e-mail.
De gebruikte karakters zijn A t/m Z, a t/m z, 0 t/m 9 aangevuld met, in standaard base64 encoding, het + en / symbool.
Het algoritme om data om te zetten naar base64-encoded data is vrij eenvoudig. Neem bijvoorbeeld de string 'FOK!'. Elke letter in deze string heeft een karakter-code, respectievelijk 70, 79, 75 en 33. Binair met 8 bits per byte ziet dat er zo uit:
| 1 |
Bij het encoden worden telkens 6 bits uit deze reeks bytes genomen, en vervangen door het symbool uit de base64-karaktersset dat staat op de index gevormd door het 6-bit getal:
| 1 |
| 1 |
| 1 |
In dit geval houden we nog 2 bits over; die worden aangevuld met 0-en, dus het laatste karakter wordt het karakter op index 010000, oftewel 16 = Q
Je ziet dus dat voor elke 3 bytes input er 4 bytes geoutput worden. Als er op het eind minder dan 4 bytes geoutput hoeven worden (zoals in dit geval) dan wordt de base64-encoded string aangevuld met een zogenaamd 'padding'-karakter, in dit geval het '='-teken. In totaal komt de encoded string er dus zo uit te zien:
| 1 |
Tot zover de theorie
De inzendingen
In totaal mocht ik 3 inzendingen ontvangen: van GlowMouse, JeRa en SuperRembo en voor zover ik heb kunnen beoordelen zijn 2 van deze inzendingen correct; die van SuperRembo gaat bij sommige stringlengtes de mist in, zo output hij bij de input 'FOK' 'Rk9=AA==' ipv 'Rk9L'.
Opvallend is wel dat elke inzending uniek is in de manier waarop het probleem is aangepakt
Ik begin even met de drie oplossingen, van groot naar klein:
SuperRembo, 248 tekens:
| 1 2 3 4 5 6 7 8 9 | $t.='+/='; for($l=strlen($s=pos($_POST)."\0\0");$j<$l;) { $a=ord($s{$j++}); $b=ord($s{$j++}); $c=ord($s{$j++}); echo$t{$a>>2}.$t{$a<<4&48|$b>>4&15}.$t{$l-$j>1?$b<<2&60|$c>>6:64}.$t{$l-$j>2?$c&63:64}; } |
GlowMouse, 228 tekens:
| 1 2 3 4 5 6 | $b.='0123456789+/'; $l=strlen($s=end($_POST)); while($i<$l)$x.=sprintf('%08b',ord($s{$i++})); while($j<8*$l)echo$b{bindec(sprintf('%0-6s',substr($x,-6+$j+=6,6)))}; while($l++%3>0)echo'='; |
JeRa, 214 tekens:
| 1 2 3 4 5 6 7 8 | for($s=pos($_POST);($a=$s{$p})!='';) { $b=$p++*2%6; $c=ord($a)>>$b+2|($b?$d:0); $d=ord($a)<<4-$b&63;echo$t{$c}.($b>3?$t{$d}:''); } if($p%3)echo$t{$d}.'='.($b?'':'='); |
(whitespace moet je even wegdenken en <? moet je ervoor denken
)De uitleg (leermomenten
)Over het algemeen kunnen we het probleem in 3-en hakken: ten eerste moet je een string of array samenstellen van de karakters die gebruikt mogen worden; de 'base' als het ware, dan volgt het daadwerkelijk encoden en als laatste het eventuele aanvullen met '='-tekens.
Het eerste punt is duidelijk te herkennen in de scripts en het is ook duidelijk dat JeRa daarvoor de kortste methode heeft gevonden; JeRa had slechts 52 tekens nodig om de base-string samen te stellen tegenover de 61 van SuperRembo en 62 van GlowMouse. Zelfs mijn eigen methode was met 56 duidelijk nog langer dan noodzakelijk
Dan komt het lastige stuk, namelijk de implementatie van het algoritme zelf
Zoals gezegd zie je duidelijk aan de drie inzendingen dat er ook 3 heel verschillende oplossingen gekozen zijn. Heel in het kort kan ik het als volgt samenvatten:
GlowMouse heeft ervoor gekozen om mbv de string formatting functie sprintf() eerst de input om te zetten naar een string-representatie van de individuele bits. Uiteindelijk krijg je dus een lange string met enkel enen en nullen die hij vervolgens vakkundig weer in stukjes van lengte 6 hakt, omzet naar een decimaal getal en het juiste base64-karakter output. Geen bitshifting dus en daarmee ook origineel, begrijpelijke code en vooral ook korte code
SuperRembo schuwt het bitshiften echter niet en gaat voor de aanpak waarbij hij telkens 3 bytes inleest en meteen 4 bytes output, samengesteld door te AND-en, te OR-en en te shiften (een oplossing die je overigens vaak tegenkomt voor dit probleem). Jammer dat het bij sommige stringlengtes fout gaat...
JeRa tenslotte komt met een oplossing die ook in de richting komt van mijn eigen idee hieromtrent: een loop waarin je telkens een karakter inleest, en 1 (of 2 - als je genoeg bits over hebt) encoded karakter output. Binnen de loop houdt hij de overtollige bits vast in een variabele voor de volgende iteratie.
JeRa en GlowMouse moeten na de encoding slag nog de padding regelen in een klein loopje; dat kan idd door slim gebruik te maken van de modulus van de input-counter
Ten slotte wil ik jullie mijn eigen 196-er (die na toepassing van enkele truuks uit o.a. JeRa's oplossing nog terug te brengen is tot 182 tekens) niet onthouden; ik heb hier door gebruik te maken van een 'end'-indicator $e de padding geintegreerd in de main-loop wat mij de nodige besparing opleverde.
Dit is zondermeer de slechts begrijpbare oplossing, en ik ga 'm ook niet volledig uitleggen
In plaats daarvan zal ik in de volgende post een (imho) nette oplossing presenteren met uitleg | 1 2 3 4 5 6 7 | $l=strlen($s=pos($_POST)),$d=array_merge(range(A,Z),range(a,z),range(0,9),'+','/','='); $i<$l||$b%8&&++$e; $o.=$d[$e>1?64:$r>>$b],$r&=(1<<$b)-1 ) $b+=$b<6?($r=$r<<8|ord($s[$i++]))?2:2:-6; echo$o; |
Ter afsluiting roep ik JeRa uit tot winnaar; hij komt imho het dichtst bij een 'ideale' oplossing en heeft op een aantal punten z'n code korter weten te schrijven dan ikzelf. Verder laat hij zien goed thuis te zijn in het werken met bits en is zijn code to-the-point en zelfs voor de ervaren bitneuker nog goed te volgen (wat van mijn eigen versie niet te zeggen is).
JeRa: gefeliciteerd!
je bent vaak zo erg met getallen aan het rekenen dat je soms niet inziet dat het ook verrekte kort kan met een simpele string-representatie Ook erg benieuwd naar Crisp's uitleg over zijn (gecleanede) methode
edit:
quote:Ik gebruik geen '=' in mijn base, en als je die bij jouw methode weglaat is het aantal tekens ook 52Zelfs mijn eigen methode was met 56 duidelijk nog langer dan noodzakelijk
edit2: $r=$r<<8; is hetzelfde als $r<<=8; mocht je dat nog niet in je kleinere versie hebben
[ Bericht 20% gewijzigd door JeRa op 19-12-2005 00:18:53 ]
Ik heb het even in een functie gegoten omdat je het meestal ook in die vorm zult gebruiken. De truuks met pos($_POST) kennen we allemaal wel, dus hier gewoon een 'nette' uitvoering:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | { $b64 = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'; $result = ''; $i = 0; $l = strlen($string); $bitpointer = 0; $remainder = 0; while ($i < $l) { if ($bitpointer < 6) { $remainder = $remainder << 8 | ord($string[$i++]); $bitpointer += 8; } $bitpointer -= 6; $result .= $b64[$remainder >> $bitpointer]; $remainder &= (1 << $bitpointer) - 1; } if ($bitpointer) { $result .= $b64[$remainder << 6 - $bitpointer]; $bitpointer -= 6; while ($bitpointer % 8) { $result .= '='; $bitpointer -= 6; } } return $result; } |
Wat het doet is simpel; ik hou een bitpointer en een 'remainder' bij. De bitpointer laat zien hoeveel bits er nog in mijn 'remainder' zitten.
De while-loop loopt door tot ik alle bytes van mijn input-string heb gehad. Als eerste check ik of ik genoeg bits in mijn 'remainder' heb zitten - zo niet, dan vul ik 'm aan met blokjes van 8 bits (1 byte) uit mijn inputstring tot ik genoeg heb.
Vervolgens pak ik zoveel bytes als ik nodig heb voor mijn encoding (6 in dit geval) en vul mijn result aan met het bijbehorende karakter uit mijn base-set. Die bits zet ik in mijn remainder vervolgens op 0 dmv de AND-constructie met een mask van $bitpointer 1-bits die ervoor zorgt dat enkel de niet-gebruikte bits (low-order) overblijven.
Als ik op deze manier door de hele inputstring heen ben gegaan kan het zijn dat ik nog iets in mijn remainder heb staan ($bitpointer is dan niet 0); ik moet dus nog een karakter outputten door die remainder te left-shiften met 6 - $bitpointer bits.
Als vervolgens na aftrek van het aantal te encoden bits de bitpointer nog niet 0 is moet ik gaan padden totdat de bitpointer modulus 8 de 0 bereikt.
Het grote voordeel van deze aanpak is dat het eenvoudig is om te zetten naar een andere macht-van-2-basis zoals base32 of base128 (dat laatste gebruik ik bijvoorbeeld voor een javascript-compressie algoritme).
De 196 van mij heb ik momenteel overigens terug weten te brengen tot 176:
| 1 2 3 4 5 6 | $s=pos($_POST),$d=join(range(A,Z)).join(range(a,z)).'0123456789+/='; $s[$i]!=''||$b%8&&++$e; print$d[$e>1?64:$r>>$b],$r&=(1<<$b)-1 ) $b+=$b<6?($r=$r<<8|ord($s[$i++]))?2:2:-6; |
[ Bericht 0% gewijzigd door crisp op 19-12-2005 00:47:59 ]
Ik heb er geen moment aan gedacht om range() te gebruiken.
Mijn aanpak was misschien wat te lomp, maar ik had ook geen zin meer om opnieuw te beginnen.
quote:Die ,'=' had ik al buiten beschouwing gelatenOp maandag 19 december 2005 00:06 schreef JeRa het volgende:
Ik gebruik geen '=' in mijn base, en als je die bij jouw methode weglaat is het aantal tekens ook 52
quote:Nee, samen met die OR gaat dat niet goed...edit2: $r=$r<<8; is hetzelfde als $r<<=8; mocht je dat nog niet in je kleinere versie hebben
Overigens mag iedereen zich wel een beetje winnaar noemen; ik had niet verwacht dat ik zulke goede inzendingen zou krijgen, en zelfs dat foutje van SuperRembo is nog te vergeven aangezien het volgens mij best wel eenvoudig te fixen is
quote:Shame on me...Op maandag 19 december 2005 00:43 schreef crisp het volgende:
Nee, samen met die OR gaat dat niet goed...
na zoveel uittesten zou operator precedence er nu toch wel in moeten zitten bij mij. quote:En jij bent ook zeker een winnaar, 176 tekens is wel schandalig kleinOverigens mag iedereen zich wel een beetje winnaar noemen; ik had niet verwacht dat ik zulke goede inzendingen zou krijgen, en zelfs dat foutje van SuperRembo is nog te vergeven aangezien het volgens mij best wel eenvoudig te fixen is
quote:Waar gebruik je die compressie voor? Is het ook ergens in actie te bewonderen?Op maandag 19 december 2005 00:32 schreef crisp het volgende:
Het grote voordeel van deze aanpak is dat het eenvoudig is om te zetten naar een andere macht-van-2-basis zoals base32 of base128 (dat laatste gebruik ik bijvoorbeeld voor een javascript-compressie algoritme).
quote:Een uitwerking van LZW/LZS met nog een aantal verbeteringen in javascript: http://therealcrisp.xs4all.nl/upload/jscompress.htmlOp maandag 19 december 2005 07:43 schreef SuperRembo het volgende:
[..]
Waar gebruik je die compressie voor? Is het ook ergens in actie te bewonderen?
Ik gebruik hier dus base128 encoding voor het resultaat (overhead van base64 is 33%, van base128 slechts 14%).
Ik gebruik hier phased-in binary coding om de compressie-ratio met zo'n 10% te verhogen tov standaard LZW en werk nog aan een manier om de dictionary sneller aan te vullen wat over het algemeen ook nog zo'n 10% winst op kan leveren. Standaard LZW geeft meestal een compressie-ratio van zo'n 50% bij gemiddelde teksten, dit algoritme zou 60-70% moeten halen zonder alteveel in te boeten op performance of complexiteit.
Phased-in binary coding is wel een aardige techniek; stel dat je dictionary 10 codes bevat. In normaal LZW zou je die codes dan outputten als 4-bit, maar met phased-in binary coding kan je voor de kleinere codes toch nog 3 bits gebruiken:
| 1 2 3 4 5 6 7 8 9 10 | 001 = 1 010 = 2 011 = 3 100 = 4 101 = 5 1100 = 6 1101 = 7 1110 = 8 1111 = 9 |
Heb je dit gemaakt als studie, voor de lol of heb je ook een echte toepassing?
geweldig... kan het helaas zelf niet maken want snap er de balle van maar goed! quote:Een beetje voor de lol eigenlijk. Ik had LZW al geimplementeerd in mijn javascript GIF generator (WIP) en wou eens kijken of het ook bruikbaar zou zijn voor een javascript compressor/obfuscatorOp maandag 19 december 2005 19:27 schreef SuperRembo het volgende:
Ziet er gaaf uit
Heb je dit gemaakt als studie, voor de lol of heb je ook een echte toepassing?
Ik heb namelijk een vrij nutteloze maar best uitdagende PHP-puzzel bedacht die we misschien als extra tussendoortje kunnen doen
quote:Kom maar op hoorOp vrijdag 6 januari 2006 17:45 schreef JeRa het volgende:
Wanneer komt eigenlijk de volgende PHP Golf?
Ik heb namelijk een vrij nutteloze maar best uitdagende PHP-puzzel bedacht die we misschien als extra tussendoortje kunnen doen
Deze keer een probleemstelling die niet zozeer heel erg nuttig is, maar behoorlijk veel inzicht kan opleveren. Een aantal hier kent vast wel het probleem van een programma dat de eigen code moet laten zien zonder simpelweg via een externe weg de broncode te laten zien. In PHP bestaat dat probleem ook, je kunt niet zomaar iets als dit gaan doen:
| 1 |
Er is dus een slimmere methode nodig om dat te doen. Deze golf gaat over het vinden van zo'n methode, in zo weinig mogelijk tekens uiteraard.
De opdracht
"Maak een zo'n kort mogelijk script dat, wanneer het door de PHP-parser wordt gehaald, het eigen script oplevert in de output. De output en het script zelf dienen dus identiek te zijn."
De voorwaarden
1. Het script mag geen warnings opleveren, PHP draait niet in strict mode.
2. Het script moet platformonafhankelijk werken (m.a.w., geen commands).
3. Het script moet een daadwerkelijk PHP-script zijn en niet zomaar een leeg (of tekst-)bestand.
4. De output van het script dient tot in de bits identiek te zijn als het script zelf.
5. Er wordt uitgegaan van niet-HTML output, dus no need for <br>
6. Het script mag het eigen script niet openen (helaas, geen echo file_get_contents()).
7. Alle zwakke oplossingen zoals het opvragen van externe bronnen leiden tot groot eerverlies en uitsluiting van deelname.
De deelname
Mocht je een oplossing hebben bedacht, dan kan dat worden gestuurd naar golf@gmta.nl. Het punt van sluiting is zaterdag 14 januari om 18:00.
[ Bericht 3% gewijzigd door JeRa op 07-01-2006 02:22:21 ]
Tis wel heel erg simpeltjes hoor, hoe ik het heb gedaan
quote:Ja, dat staat er welOp zaterdag 7 januari 2006 17:35 schreef Chandler het volgende:
Dus ff ter vertaling, je de output van het script moet het zelfde zijn als de broncode van het script?
quote:Op zaterdag 7 januari 2006 02:14 schreef JeRa het volgende:
De opdracht
"... De output en het script zelf dienen dus identiek te zijn."
quote:Ja inderdaad. Maargoed dan kom je nog maar op 65 tekens uit.Op zaterdag 7 januari 2006 15:24 schreef SuperRembo het volgende:
Er staat er zelfs een in de comments bij de functiexxxxxxop php.net
Mijne zit nu trouwens op 116 tekens, dom dingetje over het hoofd gezien
. maakt niet uit of het de kortste is, ik wil alleen wel wat meer variatie zien dan alleen de 2 die ik nu binnen heb anders is het typen ook zo gauw gedaan. quote:Heb er maar één ontvangenOp zaterdag 14 januari 2006 17:33 schreef SuperRembo het volgende:
Crisp had toch 3 versies?
quote:Ik heb je later nog een mail gestuurd met daarin 3 alternatieven - welliswaar allemaal gebaseerd op voorbeelden die je ook op het web vind, maar toch...
quote:Daar heb je helemaal gelijk in.Op zaterdag 14 januari 2006 17:54 schreef crisp het volgende:
[..]
Ik heb je later nog een mail gestuurd met daarin 3 alternatieven - welliswaar allemaal gebaseerd op voorbeelden die je ook op het web vind, maar toch...
Ik heb er nu
[ Bericht 2% gewijzigd door JeRa op 14-01-2006 18:36:39 ]
Anyway, ik weet niet of het posten van het zoekwoord 'quine' nu debit is geweest aan de respons. Ik had gehoopt dat het makkelijk kunnen vinden van voorbeelden juist zou bijdragen...
De meeste PHP-gerelateerde voorbeelden zijn echter nogal 'lang' op het voorbeeld in de usercomments voor de printf() functie na...
PHP Golf Intermezzo #2 - de uitslagenDe opdracht van deze tussen-golf was het maken van een PHP-script dat als output het eigen script omvatte. Al snel werd het keyword 'quine' genoemd waardoor het niet zo moeilijk was om een codevoorbeeld te vinden, maar zoveel korte voorbeeldquines in PHP zijn er helaas niet... Gruwelijk veel mensen zijn hier mee bezig geweest maar uiteindelijk wisten slechts twee mensen de mailknop te vinden om toch nog binnen de tijd hun brouwsels op te sturen. We beginnen met de oplossing met het meest aantal tekens;
Crisp - 131 tekens:| 1 |
Dit is een klassieker in de quine-wereld. De variabele $a bevat een base64 geëncoded stukje code die na een base64_decode() er zo uit ziet:
| 1 |
chr(42) is de benoeming voor de asterisk ('*') en dit tekentje wordt dan ook na de base64_decode() vervangen door de inhoud van variabele $a, de geëncodeerde code. Hierdoor kom je op exact dezelfde code uit als hetgeen je mee begint.
SuperRembo - 113 tekens:| 1 |
SuperRembo maakt slim gebruik van de pack() functie die PHP heeft overgeërfd vanuit Perl. Het resultaat van de pack() functie zoals hij hierboven staat is dit:
| 1 |
Dit zorgt ervoor dat na uitvoering net zoals bij de base64_decode() variant van Crisp de output exact hetzelfde is als het script.
Crisp - 63 tekens:| 1 |
Een aanzienlijk kortere quine met een duidelijk andere aanpak. Crisp maakt gebruik van het feit dat een toewijzing aan een variabele ($c=...) de inhoud van de toewijzing zelf terug geeft en dus gebruikt kan worden als parameter van eval(). De inhoud van $c is echter een PHP-scriptje met een echo welke de inhoud van het script toont. Dit werkt doordat éérst $c wordt toegewezen tijdens het verwerken van de parameter van eval(), waarna vervolgens de eval daadwerkelijk wordt uitgevoerd. Een slimme aanpak die we straks nog terug zullen zien.
Crisp - ongeldig:| 1 |
Het idee is goed, alleen vergeet Crisp hier dat printf() de lengte van de geoutputte string teruggeeft en dat de output in dit geval niet gelijk is aan het PHP-script zelf.
SuperRembo - 54 tekens:| 1 |
Nu wordt het serieus, SuperRembo heeft in principe dezelfde quine als de voorgaande met het verschil dat deze foutloos is en dus geen '<?=' bevat. printf() kan worden gebruikt om een string te 'formatten' met variabelen. Dit houdt in dat je in de string zelf bepaalde codes opgeeft die je later laat vervangen door de inhoud van variabelen. printf() neemt als eerste argument de string die geformat dient te worden, en als volgende argumenten de variabelen die in die string geplaatst dienen te worden. De code '%c' staat voor 'character' en geeft in principe de waarde terug van chr($n). De code '%s' staat voor 'string' en plaatst op die plek het argument als een string.
Code 39 staat voor de apostrofe (') en $x wordt in de string geplaatst waardoor de output verdacht veel op het script zelf lijkt
hier is dit ook weer mogelijk aangezien in PHP de argumenten van links naar rechts worden verwerkt en $x dus éérst gevuld wordt voordat het in de string wordt gezet. Crisp - 44 tekens:| 1 |
Crisp laat duidelijk zien waar hij toe in staat is en verbetert zijn eval()-quine door slim gebruik te maken van escaped characters in dubbel quoted strings. De '\x27' is een speciale manier om in dubbel quoted strings de apostrofe weer te geven waardoor er nu geen apostrofes meer hoeven te worden ge-escaped. Een addslashes() neemt vrij veel tekens in en dit is dan ook een slimme manier om aan de geweldige 44 tekens te komen.
Crisp, gefeliciteerd!
Het wordt tijd voor een php sectie op The Quine Page.
quote:GEEN OPLOSSINGEN POSTENDoelstelling
Je ontmoet wel eens leuke meiden waarvan jij je nummer wilt geven. Alleen is het veel cooler als jij je nummer in woorden kan geven. Op meeste telefoons zitten de letters op deze nummers:
0 => 0
1 => 1
2 => abc
3 => def
4 => ghi
5 => jkl
6 => mno
7 => pqrs
8 => tuv
9 => wxyz
Dus 0900-8844 (nummer van politie) kan 0Z00-TUIG worden en 09008844 wordt 0Z00TUIG. Nu is de bedoeling dat jij een script schrijft die alle mogelijkheden geeft wanneer je een telefoonnummer ingeeft. Elk mogelijke uitkomst moet worden weergeven op haar eigen regel.
Voorbeelden van geldige telefoonnummers:
06-12345678
0612345678
0900-8844
09008844
000-1234567
0001234567
Je mag er vanuit gaan dat de nummer uit $_GET komt met key 'nr' en dat deze altijd set is.
Deadline
De deadline is over 8 dagen.
Dinsdag 18:00 20 juni 2006
De volledige opgave staat in het topic bij phpfreakz.nl.
Maar ik moet en zal iets inleveren voor dinsdag quote:Op woensdag 14 juni 2006 16:04 schreef JeRa het volgende:
Ook maar eens een poging gewaagd met 229 tekens
[ Bericht 3% gewijzigd door JeRa op 14-06-2006 17:45:02 ]
Warnings niet toegestaan, notices wel:
error_reporting = E_ALL & ~E_NOTICE
Geen globals vanuit $_GET, $_POST etc:
register_globals = Off
Het is toegestaan om <? te gebruiken:
short_open_tag = On
[ Bericht 1% gewijzigd door JeRa op 15-06-2006 07:25:11 ]
quote:Je zat er op te wachten hèOp donderdag 15 juni 2006 09:02 schreef Roönaän het volgende:
Okee, dan is het 197 met zero warnings.
edit: ah, ik zie het. de timing kwam netjes uit.
zijn we mooi klaar mee. Iemand iets lagers?196 tekens
quote:Er staat dus niét dat er op elke regel een uitkomst moet staan. Misschien helpt dit mensen als ze een loopje met een echo "\n" willen combinerenElk mogelijke uitkomst moet worden weergeven op haar eigen regel.
Oh, en 193 tekens zonder fatal omgwtf core dumps!
[ Bericht 8% gewijzigd door JeRa op 15-06-2006 10:23:03 ]
quote:Oh god had ik nou maar niks gezegdOp donderdag 15 juni 2006 10:23 schreef Roönaän het volgende:
het moet toch sowieso <br>'s worden?
het staat nergens dus nee, PHP gaat verder dan HTML[ Bericht 8% gewijzigd door JeRa op 15-06-2006 10:59:58 ]
Zit nu op 296 chars
Zou niet weten hoe ik dit korter kan maken
quote:Kijk vooral bij de oplossingen van de vorige puzzels; staan een hoop truukjes bij die je gegarandeerd later weer wilt vergeten (maar die wel helpen om de boel korter te krijgen)Op donderdag 15 juni 2006 11:20 schreef _Flash_ het volgende:
mijn eerste keer dat ik zo'n puzzel maak.
Zit nu op 296 chars
quote:substr_replace() is alleen handig als je meerdere tekens in één keer wilt wijzigen, is dit bij jou het geval? Zo niet, dan kun je nog altijd de string als een array beschouwen of de string accessors ($string{$pos}) gebruiken. Die accessors zijn wel obsolete vanaf PHP6 dacht ik.Op donderdag 15 juni 2006 14:25 schreef _Flash_ het volgende:
Gebruikt iemand ook substr_replace als kern? Of andere tips?
wie gebruikt er ook een function of juist niet?
edit: 225
| 1 2 3 4 5 6 7 | ?> <?php $lines = file(__FILE__); $line = $lines[0]; // <-- de regel in het bestand waar je oplossing staat. echo '<br/>Mijn oplossing is '.strlen($lines[$line]).' tekens lang'; ?> |
-r-
quote:Ehm...wat is er mis met de bestandsgrootte?Op donderdag 15 juni 2006 17:15 schreef Roönaän het volgende:
Als je hele oplossing op 1 regel staat (lijkt me wel) kan je simpelweg het statement tellen met:
[ code verwijderd ]
-r-
quote:ik heb error_reporting E_ALL op de eerste regel staanOp donderdag 15 juni 2006 22:17 schreef SuperRembo het volgende:
[..]
Ehm...wat is er mis met de bestandsgrootte?
En meerdere oplossingen in één file.
De deadline was gistermiddag.
(maar dat lag vast aan de methode).Ik heb er ook een stuk of 4 ingestuurd. Ben alleen nog niet geregistreerd op dat forum dus ik weet niet of ze geplaatst worden. Kortste was 211 karakters. Maar hij werkt wel met telefoonnummers van alle lengtes en met zoveel streepjes als je wil
Mijn oplossing werkt met een array met de 0, 1, abc, etcetera en een function die zichzelf weer aanroept en iedere combinatie op het scherm print. De termen 'function', 'global' en de declaraties van een aantal variabelen nemen veel karakters in.
en verder een loop in een loop en een hoop ranzigheden
en _Flash_, je weet dat je $GLOBALS kunt gebruiken als je een variabele in de rootscope wilt aanspreken? (scheelt wat tekens t.o.v. global $a; als je de variabele maar één keer nodig hebt)quote:Ging niet bij mij zonder een warning helaasOp donderdag 22 juni 2006 00:44 schreef crisp het volgende:
Ik heb maar 1 echo, ik doe aan het begin al $g=$_GET[nr]."\n";
Werkt dit ook? Het scheelt een puntje.
| 1 2 | "; |
Ik heb overigens niet getest in PHP 5 omdat ik dat nog niet heb draaien hier, dus de mogelijkheid bestaat dat mijn inzending uiteindelijk toch niet voldoet aan de criteria, maar da's dan jammer
http://www.phpfreakz.nl/forum.php?forum=5&iid=836601
Verder mooie oplossingen! Gefeliciteerd crisp
mooie oplossing!quote:Ja, maar die had ik nog niet ingestuurd omdat ik dacht dat als ik nog even tijd had hem nog iets kon bijslijpen. Alleen vergeten dat er ook een deadline wasOp donderdag 22 juni 2006 14:44 schreef JeRa het volgende:
Roönaän had toch een veel kortere oplossing dan 197 tekens? Of is het een typo?
Verder mooie oplossingen! Gefeliciteerd crisp
185:
| 1 |
[ Bericht 2% gewijzigd door Roonaan op 22-06-2006 23:39:56 ]
(plus hij kan nog een stukje korter door de accolades bij de laatste for weg te laten en de increment in de substr te doen ipv los in de for - dan kom je op 181)edit: met wat tweaks is je bug verholpen en kom je uit op 177:
| 1 |
[ Bericht 50% gewijzigd door crisp op 23-06-2006 00:21:19 ]
quote:Nou, enerzijds is $k natuurlijk korter dan $p[$i] en anderszijds is het een smerige manier om m'n pointerarray te initializeren - ik gebruik immers een iteratieve approach itt een recursieve.Op vrijdag 23 juni 2006 00:17 schreef SuperRembo het volgende:
Crisp, wat doet die reference nou precies in $a{$k=&$p[$i]}?
It boils down to this:
| 1 2 3 4 | $k =& $p[$i]; $k = 10; print_r($p); |
geeft Array ( [0] => 10 ), dus ik heb van $p een array gemaakt en daar een item aan toegevoegd zonder enige initialisatie. Vziw is PHP ook de enige taal waarin dat kan - het levert zelfs geen notice of warning op
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | //Notice: Undefined variable: b // $b is nog steeds undefined $c = & $d; // levert $d = NULL $e = & $f[0]; // levert $f = array(1) { [0]=> &NULL } $g = & $h{0}; // levert $h = array(1) { [0]=> &NULL } $i = & $j->k; // levert $j = object(stdClass)(1) { ["k"]=> &NULL } |