DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Die hint van mij was misschien ook niet echt duidelijkquote:Op 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
Ja, door afkappen ipv afronden.quote:Op zondag 11 december 2005 22:29 schreef crisp het volgende:
Light: still invalid
Die truck met de X werkt in dit geval niet
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
Hoe apart, waarom daar niet?quote:Op zondag 11 december 2005 22:34 schreef SuperRembo het volgende:
Die truck met de X werkt in dit geval niet
Kan iemand 'm even uitleggen want ik begrijp werkelijk niet hoe dit
Kan optellen, aftrekken EN vermenigvuldigen
de formatted string is me sowieso niet erg duidelijk
| 1 |
Kan optellen, aftrekken EN vermenigvuldigen
de formatted string is me sowieso niet erg duidelijk
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.
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 ben wel benieuwd naar je oplossing, volgens mij wordt ie niet genoemd op phpfreakz.quote: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.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
Roonaan wordt daar helemaal niet genoemd, vreemd genoeg.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.
Ja...quote: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?
Zo werkt het niet.quote: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'.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
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 Lightquote: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 ).
Correctquote:Op 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?
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.quote: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 ]
Wel creatief, maar die gebruikt dus intern ook eval. Ik zie nergens dat je round niet mocht gebruiken.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
Round levert bij 2+8 de uitkomst 10, niet 10.00.quote: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.
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.quote: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 |
jups. mijn fout. misread de opdracht klaarblijkelijk.quote:Op zondag 11 december 2005 23:47 schreef Light het volgende:
En je oplossing van 52 tekens, was dat ook met een round?
Dat round() iets anders doet dan de %.2f van printf() betekent niet dat je round() niet mag gebruiken.quote:Op zondag 11 december 2005 23:48 schreef Light het volgende:
[..]
Round levert bij 2+8 de uitkomst 10, niet 10.00.
Iemand zin in een tussendoortje?
Men neme dit formulier:
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
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
this space for rent
In dit geval wel. Uit de opdracht:quote: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.
Dus volgens jou mag deze oplossing niet?quote: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)
Als kortste oplossing komt die niet in aanmerkingquote: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)
Ik heb 'm nu in 283 karakters. 228 is wel erg weinig zegquote:Op 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
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
in basic ofzo kon je altijd printen met printf "##.##", getal maar dat werkt blijkbaar niet in PHP
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
De functie die je dan moet hebben heet wel printf, maar de argumenten zijn iets anders (en bieden ook meer mogelijkheden).quote: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
zó ingewikkeld om php.net/printf is het toch niet?quote: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
Dat vind ik al een aardige prestatiequote:Op 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
this space for rent
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).quote: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.
this space for rent
Grmbl...zit op 248 tekens voor volledig functionele base64_encoder...moet...kleiner...kunnen!
edit: niet dus, hij hield geen rekening met één bepaalde character
edit2: Foutje eruit gewerkt, nu op 243 tekens.
edit3: 234 232 tekens nog een béétje verder...
[ Bericht 23% gewijzigd door JeRa op 13-12-2005 15:58:43 ]
edit: niet dus, hij hield geen rekening met één bepaalde character
edit2: Foutje eruit gewerkt, nu op 243 tekens.
edit3: 234 232 tekens nog een béétje verder...
nog een béétje verder...[ Bericht 23% gewijzigd door JeRa op 13-12-2005 15:58:43 ]
Zat ik net eentje onder je vorige schepsel, kom je met dit nieuws nog even verder prutsenquote:Op 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
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Leuk overigens dat er toch een aantal mensen de uitdaging aangaan
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
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
this space for rent
Het lastige is dat je van te voren niet weet of de aanpak die je kiest goed te optimaliseren is. Als je de code eenmaal compact opgeschreven hebt dan is geen doen meer om dingen om te gooien.
Met een kleine aanpassing zit ik nu op 279.
Met een kleine aanpassing zit ik nu op 279.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
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-quote:Op dinsdag 13 december 2005 23:29 schreef crisp het volgende:
dat wordt een leuk lesje bitwise rekenen
Mwa, ik kan daar nog wel wat variaties op bedenken hoor.quote: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...
this space for rent
Je geeft me een geweldig idee *uitwerkt* er zit wel degelijk verschil in ja, aangezien ik het daadwerkeiljke algoritme en het verwerken van rest/padding in één stuk heb beschrevenquote: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...
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 ]
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
this space for rent
Ben erg benieuwd naar de resultaten straks ik zit nu op 262 en 206 tekens. En nu ga ik slapen.quote:Op 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
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.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
Enig idee hoeveel tekens een return-statement inneemt?quote: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.
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?
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...
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...
this space for rent
Nou nee, ik zit op 262 maar bij dat aantal is het nog goed mogelijk om de boel leeg te laten lopenquote:Op 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.
maar het wordt krap.[ Bericht 7% gewijzigd door JeRa op 14-12-2005 18:53:08 ]
|
|
