Bitové operace ve vyšších jazycích

[gamer]

Zhodou to vyslo a zistil si, ze typy v jave su signed, gratulujem

Takže co v javě použiješ, když potřebuješ spočítat 2^x ? Shift, pow, něco jiného, nebo je to podle tebe jedno, jak si někteří myslí?

[Reklama]

[balki]

Ano, to je samozřejmě další důvod, proč nejde zaměňovat pow a shift... Nicméně tady není problém s double ani s přesností:
pow(63): 9.223372036854776E18
shift(63): -9.223372036854776E18

Tak tohle je čistě problém Javy. V Pythonu mají integery nekonečnou přesnost. Při posunu se nic neztrácí.

Nejde o to, ze by sa nieco stracalo, ale long v jave je signed a pouziva dvojkovy doplnok.

[balki]

Zhodou to vyslo a zistil si, ze typy v jave su signed, gratulujem

Takže co v javě použiješ, když potřebuješ spočítat 2^x ? Shift, pow, něco jiného, nebo je to podle tebe jedno, jak si někteří myslí?

Zavisi pripad od pripadu. Treba vediet, kde je zrada a podla toho sa zariadit.

[Kit]

Tak tohle je čistě problém Javy. V Pythonu mají integery nekonečnou přesnost. Při posunu se nic neztrácí.

Nejde o to, ze by sa nieco stracalo, ale long v jave je signed a pouziva dvojkovy doplnok.

Java přece jen není tak univerzální, jak by si mnozí přáli. Některé záležitosti se v ní dělat nedají a jiné se v ní dělají blbě.

[gamer]

Zavisi pripad od pripadu. Treba vediet, kde je zrada a podla toho sa zariadit.

No výborně, začínáme se dostávat k jádru věci. Záleží to na kontextu. Nejde slepě používat násobení nebo umocňování místo bitových operací. O tom je celý tento thread, někteří to ale bohužel ještě nepochopili.

[Reklama]

[balki]

Tak tohle je čistě problém Javy. V Pythonu mají integery nekonečnou přesnost. Při posunu se nic neztrácí.

Nejde o to, ze by sa nieco stracalo, ale long v jave je signed a pouziva dvojkovy doplnok.

Java přece jen není tak univerzální, jak by si mnozí přáli. Některé záležitosti se v ní dělat nedají a jiné se v ní dělají blbě.

Pre lopaty a javamana mame v jave typ BigInteger.

[gl]

Zavisi pripad od pripadu. Treba vediet, kde je zrada a podla toho sa zariadit.

No výborně, začínáme se dostávat k jádru věci. Záleží to na kontextu. Nejde slepě používat násobení nebo umocňování místo bitových operací. O tom je celý tento thread, někteří to ale bohužel ještě nepochopili.

Tenhle thread byl původně o Pythonu a tam je to úplně jedno. Můžeš posunovat a umocňovat kolik ti výkon počítače dovolí.

[gamer]

Tenhle thread byl původně o Pythonu a tam je to úplně jedno. Můžeš posunovat a umocňovat kolik ti výkon počítače dovolí.

Není to jedno:

Kód: [Vybrat]

>>> 2 ** 4.1
17.148375400580687
>>> 1 << 4.1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for <<: 'int' and 'float'
Pokud nechápeš rozdíl, je to tvůj problém.

[Kit]

Java přece jen není tak univerzální, jak by si mnozí přáli. Některé záležitosti se v ní dělat nedají a jiné se v ní dělají blbě.

Pre lopaty a javamana mame v jave typ BigInteger.

Poněkud nepraktické, když Python, Lisp a hromada dalších jazyků s tím pracuje nativně. Podobně bychom dopadli třeba i s komplexními čísly, racionálními čísly, případně s finančními částkami.

[gl]

Tenhle thread byl původně o Pythonu a tam je to úplně jedno. Můžeš posunovat a umocňovat kolik ti výkon počítače dovolí.

Není to jedno:

Kód: [Vybrat]

>>> 2 ** 4.1
17.148375400580687
>>> 1 << 4.1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for <<: 'int' and 'float'
Pokud nechápeš rozdíl, je to tvůj problém.

Samozřejmě pokud umocňuješ a posouváš celým číslem. Pro reálný exponent to nemá smysl porovnávat.

[tisnik]

Ano, to je samozřejmě další důvod, proč nejde zaměňovat pow a shift... Nicméně tady není problém s double ani s přesností:
pow(63): 9.223372036854776E18
shift(63): -9.223372036854776E18

Tak tohle je čistě problém Javy. V Pythonu mají integery nekonečnou přesnost. Při posunu se nic neztrácí.

Nejde o to, ze by sa nieco stracalo, ale long v jave je signed a pouziva dvojkovy doplnok.

Navic 63 je int a u toho je konstanta pro posun nejdrive maskovana 0x1f, tedy napriklad 1<<64 == 1>>64 == 1

(omlouvam se, ze pouzivam hexadecimalni cisla, to je asi dneska taky uz prezitek?

[balki]

Java přece jen není tak univerzální, jak by si mnozí přáli. Některé záležitosti se v ní dělat nedají a jiné se v ní dělají blbě.

Pre lopaty a javamana mame v jave typ BigInteger.

Poněkud nepraktické, když Python, Lisp a hromada dalších jazyků s tím pracuje nativně. Podobně bychom dopadli třeba i s komplexními čísly, racionálními čísly, případně s finančními částkami.

Java pracuje default s 32bit signed integermi. Komu sa nelubi, ten nech si zatrubi. Je to prakticke aj neprakticke. Zalezi od ulohy. Ked prijde sef a spyta sa "kolko pamati to zaberie" a ja mu poviem - "huh neviem" moc nadseny z toho nebyva.

[gamer]

Navic 63 je int a u toho je konstanta pro posun nejdrive maskovana 0x1f, tedy napriklad 1<<64 == 1>>64 == 1

Při shiftu longu (64-bit) je konstanta pro posun maskována 0x3F.

[gl]

(omlouvam se, ze pouzivam hexadecimalni cisla, to je asi dneska taky uz prezitek?

Nic se neděje. Mám po ruce kalkulačku.

Navic 63 je int a u toho je konstanta pro posun nejdrive maskovana 0x1f, tedy napriklad 1<<64 == 1>>64 == 1

Takže posun o 31 je to stejné  co posun o 63?

[gl]

Java přece jen není tak univerzální, jak by si mnozí přáli. Některé záležitosti se v ní dělat nedají a jiné se v ní dělají blbě.

Pre lopaty a javamana mame v jave typ BigInteger.

Poněkud nepraktické, když Python, Lisp a hromada dalších jazyků s tím pracuje nativně. Podobně bychom dopadli třeba i s komplexními čísly, racionálními čísly, případně s finančními částkami.

Java pracuje default s 32bit signed integermi. Komu sa nelubi, ten nech si zatrubi. Je to prakticke aj neprakticke. Zalezi od ulohy. Ked prijde sef a spyta sa "kolko pamati to zaberie" a ja mu poviem - "huh neviem" moc nadseny z toho nebyva.

Nikdo ti nebrání používat numpy.