Stukje java code.

[Bert F]

Ik heb geen idee wat je probeert te zeggen.

Dat ligt vast aan mij, te snel.

Stel dat we 0110 hebben oftwel 6. het éénmaal shiften geeft 1100 oftwel 12

Tweemaal shiften 11000 oftwel 24 enz.

En dus niet, na twee maal shift, 3 dus 0011. (dit dacht ik eerst)

Besluit als je een bestand inleest waarin een data blokje twee bytes lang is dan kan je door deze shift techniek gemakkelijk die tweede byte opwarderen in waarde (begrijp je?)

Gisteren dacht ik nog dat je gewoon de ééntjes moest verplaatsen en als je achter komt terug van voor bijvoegen dit is dus niet zo.

En daarom denk ik nu dat deze techniek ondermeer nuttig kan zijn in het inlezen van files waar bv een pixel word voorgesteld door 4 keer een byte.

Groeten.

[Cycloon]

Hoewel het wiskundig gezien hetzelfde is, wil ik toch wel enkele kanttekeningen plaatsen:

2^(-2) is niet een integer. Dat heeft tot gevolg dat of het geheel wordt omgezet naar een double, of de waarde wel in een integer wordt gestopt maar niet een zinnige waarde krijgt. Beide situaties leveren geheid problemen op.

De compiler compileert waarschijnlijk "/2" en ">> 1" naar dezelfde code. Dit is nog een reden om code simpel te houden (dan kan de compiler beter optimaliseren).

Wel, ik bekijk het enkel louter wiskundig, want natuurlijk ben je niet meer bezig met bitshiften als je gewoon gaat vermenigvuldigen met \(2^{-2}\), dan ben je gewoon aan het vermenigvuldigen zoals je 13 x 7 doet.

[EvilBro]

, want natuurlijk ben je niet meer bezig met bitshiften als je gewoon gaat vermenigvuldigen met \(2^{-2}\),

Zo natuurlijk is dat niet gezien het feit dat het topic over bitshiften gaat en zeker gezien het feit dat het met vermenigvuldigen met 2 wel goed gaat (alhoewel je in java volgens mij een overflow exception krijgt als je getal te groot is, maar dat even terzijde).