[php]Bitwise operators in PHP?

[PanMan]

Hoi!
Ik had het laatst al over een manier om getallen in minder bytes te encoden. na een discussie, Cijfers encoden in minder bytes?, had ik eigenlijk besloten om er vanaf te zien. Maar het blijkt dat de source die ik gebruik voor het oversturen van de gegevens ze al encode. Dus dan vind ik het zonde om het eruit te slopen. Het decoden lukt me echter niet: Ik heb een stuk java source dat de getallen zou moeten decoden, maar het lukt me niet om dat naar PHP om te zetten: ik heb te weinig ervaring met bitwise operators in PHP. Iemand tips hoe ik hier verder mee kan komen? De java source voor het decoden is:

code:

int latitude = 0x00ff0000 & (bytes[0] << 16);
latitude |= 0x0000ff00 & (bytes[1] << 8);
latitude |= 0x000000ff & bytes[2];
latitude |= (latitude & 0x00800000) != 0 ? 0xff000000 : 0;
out.write(new Float(latitude).Div(DEGREESTOINT).toString().getBytes());

In PHP heb ik daar (optimist als ik ben ) dit van gemaakt, maar dat doet niets:

PHP:

$latitude = 0x00ff0000 & ($first[0] << 16);
$latitude |= 0x0000ff00 & ($first[1] << 8);
$latitude |= 0x000000ff & $first[2];
$latitude |= ($latitude & 0x00800000) != 0 ? 0xff000000 : 0;

Iemand tips?

[DizzyWeb]

http://nl3.php.net/manual/en/language.operators.bitwise.php

Daar al naar gekeken?

[PanMan]

Daar staar ik me al een halve dag blind op . Ik snap het idee wel, en ook nog wel enigsinds wat dit stukje code doet, maar kom er niet uit...

[Grijze Vos]

Die |= operator is niet geldig in PHP. Moet je die misschien vervangen door .= ?
=

[ Voor 5% gewijzigd door Grijze Vos op 22-11-2006 16:07 ]

[B-Man]

Grijze Vos schreef op dinsdag 21 november 2006 @ 16:10:
Die |= operator is niet geldig in PHP. Moet je die misschien vervangen door .= ?

|= is gewoon een geldige operator in PHP hoor, gebruik ik al jaren.

Wat zit er precies in $first? Als daar een getal in zit, dan werken $first[0], $first[1] etc niet.
Zo aan je java code te zien krijg je daar een array van bytes door, en bitshift je die, zodat je een getal van 4 bytes samenstelt.

[PanMan]

Inderdaad. $first lees ik uit uit een file:

PHP:

$all=file_get_contents($filenaam);
$first=substr($all,0,3);

Volgens mij staat die file gewoon vol met steeds 3 bytes achter elkaar.
http://panman.nl/test.tr is een voorbeeldfile (en, als je er goed over nadenkt, privacy gevoelig ).

[Janoz]

Vandaar, weaktyping probleempje. $first is gewoon een string en wordt niet geinterpreteerd als een byte array. Je zult ze zelf nog handmatig om moeten zetten naar een getal.

[.oisyn]

En houdt er daarbij rekening mee dat Java big-endian is, terwijl PHP de endianness van z'n host aanneemt (en dat is waarschijnlijk little-endian als je op een doodgewone PC werkt)

[Soultaker]

Mja, die Java code klinkt heel ingewikkeld, maar wat er eigenlijk gebeurt is dat er een big-endian 24-bits signed integer ingelezen wordt. Al die bitmasks zijn nodig omdat Java signed bytes gebruikt (stompzinnig idee, en dat blijkt bij dit soort dingen). In PHP maak ik er zoiets van:

PHP:

$bytes=file_get_contents('test.tr');
for($n = 0; $n + 3 <= strlen($bytes); $n += 3)
{
        $x = (ord($bytes{$n})<<8) | (ord($bytes{$n + 1})<<16) | (ord($bytes{$n + 2})<<24);
        if($x&0x800000)
                $x = -(($x&0x7fffff) + 1);
        echo "$x\n";
}

De sign extentie heb ik wat anders gedaan dan in Java, omdat ik geen idee heb hoe PHP omgaat met signed/unsigned integers en of integers misschien 64 bits zijn op andere platforms. Geen idee of het klopt, want er staan geen negatieve getallen in je invoer voor zover ik kan zien.

Dit levert op:

2440253
226323
2440255
226319
2440256
226313
2440256
226308

Kan dat een beetje kloppen?

.oisyn schreef op dinsdag 21 november 2006 @ 16:38:
En houdt er daarbij rekening mee dat Java big-endian is, terwijl PHP de endianness van z'n host aanneemt (en dat is waarschijnlijk little-endian als je op een doodgewone PC werkt)

Wat heeft dat er mee te maken? De getallen staan big endian in het bestand, en voor de bit-operaties maakt de endianness van de machine niets uit.

[ Voor 23% gewijzigd door Soultaker op 21-11-2006 16:45 ]

[PanMan]

Ik ben er uit! Thanks voor de hulp!
had het ook naar iemand gemaild, en die kwam met deze functie:

PHP:

function shizzle($bytes) {
    $test  = 0x00ff0000 & ($bytes[0] << 16);
    $test |= 0x0000ff00 & ($bytes[1] << 8);
    $test |= 0x000000ff &  $bytes[2];
    $test |= ($test & 0x00800000) != 0 ? 0xff000000 : 0;
    return $test;
}

Echt een dag tegenaan zitten klooien...

[Genoil]

peoh wat een moeite! PHP zou PHP niet zijn als daar geen handige builtin crap voor was

PHP:

$f  = file_get_contents("test.tr");
$chunks = str_split($f, 3);
foreach($chunks as $c) {
    list(,$value) = unpack("N", chr(0).$c);
    echo $value."\n";
}

[Soultaker]

Op zich een goede suggestie, maar dat doet nog geen sign extension. Dan moet het zoiets worden:

PHP:

unpack("N", chr((ord($c{0})&0x80) ? 0xff : 0).$c);

[ Voor 44% gewijzigd door Soultaker op 21-11-2006 17:33 ]

[PanMan]

Ik had ook al andere code gezien, maar deze is wel heel compact.... .

[Genoil]

Soultaker schreef op dinsdag 21 november 2006 @ 17:31:
Op zich een goede suggestie, maar dat doet nog geen sign extension. Dan moet het zoiets worden:

PHP:

unpack("N", chr((ord($c{0})&0x80) ? 0xff : 0).$c);

Ja da's waar, zo ist nog beter. Is er trouwens een reden waarom je {} gebruikt voor een index in een byte-array (lees:string)?

[.oisyn]

Soultaker schreef op dinsdag 21 november 2006 @ 16:42:
Wat heeft dat er mee te maken? De getallen staan big endian in het bestand

Het heeft uiteraard alles te maken met hoe je die data uitleest. Byte-voor-byte uitlezen en zelf in de goede volgorde te zetten hoeft niet hetzelfde te zijn als in een keer 4 bytes naar het geheugen van een int kopiëren.

[Soultaker]

.oisyn schreef op dinsdag 21 november 2006 @ 18:04:
Het heeft uiteraard alles te maken met hoe je die data uitleest. Byte-voor-byte uitlezen en zelf in de goede volgorde te zetten hoeft niet hetzelfde te zijn als in een keer 4 bytes naar het geheugen van een int kopiëren.

Accoord, maar dat kan nu precies niet (noch in Java, noch in PHP). Als je het geheugen waarin getallen opgeslagen worden niet anders dan als geheel getal kunt benaderen, maakt het voor de programmeur niet uit hoe die getallen opgeslagen worden. Op zo'n platform is endianness dus geen issue, en een uitspraak als 'Java is big-endian' is i.m.o. onzin, of het betekent slechts dat een aantal serialization functies toevallig big-endian data lezen/schrijven.

Genoil schreef op dinsdag 21 november 2006 @ 18:04:
Ja da's waar, zo ist nog beter. Is er trouwens een reden waarom je {} gebruikt voor een index in een byte-array (lees:string)?

Ik vind het zelf iets duidelijker, omdat dan uit de context blijkt dat ik een element uit een string en niet uit een array haal. Je noemt het een byte-array, maar in PHP zijn strings en arrays toch hele verschillende dingen; geen van de array-functies werkt op strings (terwijl een heleboel wel zouden kunnen werken) bijvoorbeeld.

Inhoudelijk is het alleen een keuze in programmeerstijl; blokhaken doen precies hetzelfde.

[Genoil]

Soultaker schreef op dinsdag 21 november 2006 @ 18:49:

[...]

Ik vind het zelf iets duidelijker, omdat dan uit de context blijkt dat ik een element uit een string en niet uit een array haal. Je noemt het een byte-array, maar in PHP zijn strings en arrays toch hele verschillende dingen; geen van de array-functies werkt op strings (terwijl een heleboel wel zouden kunnen werken) bijvoorbeeld.

Inhoudelijk is het alleen een keuze in programmeerstijl; blokhaken doen precies hetzelfde.

Ok, helder. Ik vind het idd wel duidelijker . Ik heb gemerkt dat het gebruiken van strings op plaatsen waar normaalgesproken (in PHP) een array voor de hand ligt, een stuk sneller is. Ben nu bezig met een 8-bit realtime raycaster in PHP (CLI met php_sdl voor de video en i/o), en daar gebruik ik een string als framebuffer. Vroeg me af of {} nog sneller was maar dat leek me al een beetje onwaarschijnlijk...

[MBV]

dan ben ik toch ineens heel benieuwd waarom je een CLI-programma voor een rekenintensief iets in PHP doet. Waarom niet in willekeurig welke andere taal? PHP is zo ongeveer de langzaamste van allemaal, vziw...

[.oisyn]

Soultaker schreef op dinsdag 21 november 2006 @ 18:49:

Accoord, maar dat kan nu precies niet (noch in Java, noch in PHP).

DataInputStream.readInt()
En gezien de substr(getfilecontents(), 0, 3) in PHP vermoedde ik al een soortgelijke implementatie.

.edit: maar ik had niet goed gelezen, omdat ze overduidelijk gewoon met bytes werken die ze bij elkaar shiften en orren

[ Voor 17% gewijzigd door .oisyn op 21-11-2006 22:17 ]

[Genoil]

MBV schreef op dinsdag 21 november 2006 @ 21:20:
dan ben ik toch ineens heel benieuwd waarom je een CLI-programma voor een rekenintensief iets in PHP doet. Waarom niet in willekeurig welke andere taal? PHP is zo ongeveer de langzaamste van allemaal, vziw...

Nou eigenlijk gewoon om te kijken of het kan. Ik moet toegeven dat ik niet onder de indruk ben van de performance van PHP als het op dit soort dingen aankomt. Ik heb nu een Wolfenstein3D (die uit de jaren negentig)-stijl raycaster die in 320*240*8 zo'n 10 fps haalt op een voxel-resolutie van 160*120 op een Core Duo 1.66Ghz...dus dat houdt niet bepaald over . Maar het is wel erg leuk om dan te kijken waar je nog een extra 0.1 fps weg kunt slepen in een taal die je goed kent en waar snelheid doorgaans niet zo'n punt is

[MBV]

@Genoil: http://shootout.alioth.de...all&lang=php&lang2=python
Diverse 'web'-talen met elkaar vergeleken
Verrassende winnaar: Java
Oh ja, als je eens echt iets anders wilt: ga dan functioneel proggen met Haskell, meeste operaties beter dan PHP, en een heel ander concept

[ Voor 30% gewijzigd door MBV op 22-11-2006 15:31 ]

[djc]

MBV: hij zegt "in een taal die je goed kent en waar snelheid doorgaans niet zo'n punt is"...

[.oisyn]

Genoil schreef op woensdag 22 november 2006 @ 08:42:

Nou eigenlijk gewoon om te kijken of het kan. Ik moet toegeven dat ik niet onder de indruk ben van de performance van PHP als het op dit soort dingen aankomt. Ik heb nu een Wolfenstein3D (die uit de jaren negentig)-stijl raycaster die in 320*240*8 zo'n 10 fps haalt op een voxel-resolutie van 160*120 op een Core Duo 1.66Ghz...dus dat houdt niet bepaald over . Maar het is wel erg leuk om dan te kijken waar je nog een extra 0.1 fps weg kunt slepen in een taal die je goed kent en waar snelheid doorgaans niet zo'n punt is

Cast je je gewoon een weg door de voxels heen zonder enige datastructuur? Want dat is natuurlijk ook niet zo handig

[Genoil]

.oisyn schreef op woensdag 22 november 2006 @ 16:13:
[...]

Cast je je gewoon een weg door de voxels heen zonder enige datastructuur? Want dat is natuurlijk ook niet zo handig

Hangt er vanaf wat je onder datastructuur verstaat . Het is zeg maar Wolf3D-stijl, met een grid. Deuren en area's ben ik nog niet aan toe . Ik ben nu toevallig bezig de tracer om te bouwen van Euclidiaans naar DDA (Digital Differential Analysis). Non-textured geeft dat al weer een meer dan dubbel zo hoge fps. Textured ongeveer 1.5 keer sneller...

[edit] ik bedacht me later dat je door mijn waarschijnlijk foute gebruik van het woord 'voxelresolutie' die vraag stelt. ik bedoelde dat de framebuffer 160*120 karakters is, die ik opschaal naar 320*240. het level-grid is vooralsnog maar 16 * 16, maar het zou denk ik niet veel schelen als die veel groter is...

[ Voor 24% gewijzigd door Genoil op 23-11-2006 09:37 ]