Hány bites vagy? (Hexadecimális számrendszerben mekkora szám ábrázolása számodra a legkényelmesebb? )

Egyéb

8 bites vagyis 0x00 ... 0xFF
28% (71 szavazat)
16 bites vagyis 0x0000 ... 0xFFFF
20% (52 szavazat)
32 bites vagyis 0x00000000 ... 0xFFFFFFFF
13% (34 szavazat)
64 bites vagyis 0x0000000000000000 ... 0xFFFFFFFFFFFFFFFF
2% (5 szavazat)
128 bites vagy ennél nagyobb
2% (4 szavazat)
Nem tudom mi az a hexadecimális számrendszer
3% (7 szavazat)
Csak az eredmény érdekel
33% (84 szavazat)
Összes szavazat: 257

( hzsolt94 v | 2016. 08. 19., p – 22:45 )

24 bites? (Megártott a sok CSS színkód)

( sza2king v | 2016. 08. 19., p – 22:58 )

Elnezes, ha mindenki erti, csak en nem.

Mit jelent az, hogy legkenyelmesebb? En azt hasznalom ami eppen kell - mondjuk egy 32 bites szamot nem nagyon tudnek abrazolni 16 biten.

/sza2

Szerintem az a kérdés, miben tudsz könnyen gondolkodni. Mivel gyakran használok 8 bites mikrokontrollereket, hozzám a 8 és 16 bit áll közel. Attól még lehet nagy számokat kezelni, de vagy pointerezni kell, vagy több utasításból összerakni. Na jó, mindenképpen több utasítás. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hát én is eléggé elgondolkodtam, h vajon mit jelent a kérdés, mert nekem a legkényelmesebb az 1-bites számábrázolás, hisz 0 vagy 1 oszt kész. Minden ami ennél nagyobb szám, ahhoz többet kell írni/gépelni -> kényelmetlenebb ennél. Szóval akkor én egybites vagyok?

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"Hexadecimális számrendszerben mekkora szám ábrázolása számodra a legkényelmesebb?"

0123456789ABCDEF

ezek az egy számjegyűek. (Ami 2- v 3- vagy több számjegyű, ahhoz több energia kell, kevésbé kényelmes.) Ezek közül még mindig az 1 (egy szál kb egyenes vonal) vagy a 0 (egy szál vonal kb tojás alakban) leírása a legkényelmesebb számomra ;-) Az összes többi több mozdulatot, nagyobb odafigyelést igényel, azaz megerőltetőbb, tehát ebből a kettőből lesz valami a nyerő. Mivel a 0 leírásánál azért arra illik odafigyelni, hogy oda vissza is érjek, ahol elkezdtem, következésképp még mindig az 1 a legkényelmesebb.

Kicsit komolyra fordítva, 00-ff között kb értelmes tempóban tudok decimális és hexa között konvertálni fejben, míg e fölött már túlságosan lelassul a dolog.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

No, igen, amit a végén írtál az például egy jó érv. Ezen felül 8 bitig magam előtt látom binárisan is a hexadecimális számot. Ez nagyobb szóhossz esetén sem nehezebb, csak annyi bitet nem tudok fejben tartani. Tehát olyasmire gondolok, hogy olvasom a katalóguslapot, nézem, hogy ez a bit 1, ha ezt akarom, 0, ha azt, a következő 2 bit megint csak jelent valamit, stb., s ezt összerakom fejben egy byte-tá, de hosszabb szóhosszúság esetén az az érzésem, tollat kellene ragadnom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( uid_19334 | 2016. 08. 20., szo – 00:41 )

Nem értem.
Mindegy, a legnagyobb vagyok, az a jó, nem?

szerk: Hiena, írnál pár szót a kérdésedről?

Ugyanezt a 12 szót és 101 karaktert fel lehet tenni úgy is, hogy több, különböző dologra vagy hiváncsi (3 biztos vam, bár, igazság szerint 1-et sem sagyon találtam).

Szakmákon belül szokás a kérdések szó szerinti és pontos értelmezése, ezen most nem segít hogy a 2, szerinted egyenértékű kérdés és magyarázata, a "Hány bites vagy?" és a "Hexadecimális számrendszerben mekkora szám ábrázolása számodra a legkényelmesebb?" nem kimondottan egyeznek jelentésileg.

Szakmák között meg célszerű rákérdezni hogy WTF ha az illető több dolgot is akarhat (+ szó nélkül átlépni az olyan típusú porblémákon hogy a kérdésben böngésző helyett internet vagy PC helyett windows szerepel).

Remélem előrébb mozdítottam a kutatásod.

Ugye az megvan, hogy az autizmus egy olyan rendellenesség, mely érinti az adott személyt a külvilágtól érő behatások interpretációs készségét? Ez jelentkezhet írásbeli, szóbeli utasítások, vagy épp érzelmi jelzések feldolgozásának zavarában. Egy autista személynek sokszor problémát okoz egy elvont fogalom és, mondjuk, egy érzelem közötti kapcsolat feldolgozása. Az ilyen személy az efféle kérdésfeltevést vagy utasítást hibásként értelmezi, meg kell neki magyarázni.
Jelen esetben mindkét kérdés asszociatív fogalomzavart tartalmaz. Az átlag ember képes efelett továbbhaladni, asszociálni és bebökni egy választ.

Természetesen segítettél, hiszen minden komment segítség.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( Elbandi v | 2016. 08. 20., szo – 02:20 )

32bites hexa, abban me'g nem golyoznak a szemeim ha egymas mellett sok hasonlo szam van. 64bites hexanal mar kijelolessel segitek magamon.
pl. 0xf0f00ffffffff0f most 6, 7 vagy 8 db f van kozepen...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( tneilc | 2016. 08. 20., szo – 08:53 )

16 bitre szavaztam, de spec a 0xCAFEBABE egy nevezetes szam. :)
A masik kedvencem: 0xF00FC7C8

Ha még mindig szeretnénk a realitás talaján állni, akkor max a 80DDB00B az, ami létezhet - igaz, többségében már az is iparos munka, hogy valakinek DD-s kosara van. De hogy 600 cm-es mell alatti kerülete (ez ugye 6 méter), az azért nem valószínű - míg az általam javasolt 80 azért nem teljesen szokatlan látvány. Persze mit tudom én, te mire gondoltál (már nyilván a p-n kívül).

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( Jason v | 2016. 08. 20., szo – 09:33 )

egybites: I see boobs, I press like.

( answ | 2016. 08. 20., szo – 10:05 )

8 biten legalabb nem kell szorakozni a bajtsorrenddel (endianness)..

( bucko | 2016. 08. 20., szo – 13:24 )

Elsőként az x nem hexadecimális számjegy.
Másodszor meg mi az, hogy mi legkényelmesebb?
- Kérek 5 zsömlét.
- Kérek 0x00000005 zsemlét.
?
A számokat legtöbbször a legrövidebb alakban érdemes leírni. Mondjuk egy aes-256 kulcsot 64 karakter hosszon.

"A számokat legtöbbször a legrövidebb alakban érdemes leírni. Mondjuk egy aes-256 kulcsot 64 karakter hosszon."
Egy 256 bites számot miért 64 karakterek akarnál leírni?
256 bit az kérlek szépen, 32 byte. Akkor tessék 32 byte-on leírni. Az a legrövidebb alak.
Vagy írd le úgy, hogy a 32 byteot szépen belepakolod 16 Unicode karakterbe UTF-16 kódolásban.
16 karakter.

Ez nem egy AES-256 kulcs, hanem egy AES-256 kulcs egyfajta reprezentációja, méghozzá úgy, hogy a 256 bites kulcsot octetekre osztod, az octeteket hexadecimális stringgé alakítod, majd ezen stringeket összefűzöd.

Ez nem maga a kulcs. A kulcs az egy 256 bites egész szám, amelyet reprezentálhatsz nagyon sokféleképpen. Például Base64 kódolással is akár. Vagy kiírhatod decimálisan is, úgy legfeljebb 78 karakter lesz (256 * log10(2) = 77.0636)

A topic (ott fönn, a lap tetején) a HEXADECIMÁLIS számokról szól. Nem hiszem el, hogy azért nem érted, mert a 0x C csökevény hiányzik az elejéről. Ezért meglepő, hogy meglepődsz a hexadecimális reprezentáción.
Továbbra is fenntartom: így írom.
Ráadásul ez annyira aes-256 kulcs, hogy egy éles adatbázisból másoltam ki és így használjuk: 

openssl enc -aes-256-cbc -nosalt -nopad -K 6c20e59ea3e53b432ed020e3ab079ab21ab239c374fb4204c3fffa197f86e6ae ...

Tehát az openssl szerint ez egy aes-256 kulcs, szerinted meg nem. Sebaj.
Természetesen ugyanez a 8 bites adatokkal dolgozó processzor memóriájában 32 bájton jelenik meg, de pakolt bcd-ben ábrázolva meg pont 39 bájt. (Volt olyan processzor, ami ilyennel is tudott dolgozni.) És?

Ha ilyen jól számolsz, akkor a 256 bitet UTF-16 kódolással hány karakteren tudod leírni?
Nekem kb.66+kb.5..8) jött ki. ;)
Neked?

( wachag | 2016. 08. 20., szo – 13:31 )

Mindegy, mert kulturált nyelvekben tetszőleges bitszámú érték ábrázolható (többféle számrendszerben), és az _ karakterrel el is lehet választani az olvashatóság kedvéért.

Jó, csak van, amit a hardware determinál. Próbáltál már 8 bites regiszterbe 16 bites számot gyömöszölni? :) Hasonlóképp, ha 32 bitesek a regisztereid, akkor ekképpen is kell gondolnod rájuk. Teszem azt, a -2 az 0xfffffffe lesz, míg 8 biten 0xfe.

Még valami. Az assembly egy kulturált nyelv.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az meglepne. Szerintem a gyártó teszi ezt. Gondolom, arra célzol, hogy magas szinten elfedésre kerül ez, az adatstruktúrát te alakítod ki, regiszterrel meg nem is találkozol, mert a kernel dolga. De erre meg azt mondom, magas szintű nyelvben ez nem is igazán kérsés, hiszen olyan adattípust választasz, ami az adatok reprezentálására a legalkalmasabb, neked a legkényelmesebb. A kérdés alacsony szinten válik érdekessé, mert 8 bites kontrollerre is írhatsz akár float aritmetikát, de az nem egyetlen gépi utasítás lesz...

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez hogy is van? Áramkör leíró nyelvet hasonlítasz össze egy hardveren futó szoftverrel?

A magas szintet meg definiálni kellene!
A tapasztlatom egyelőre csak annyi, hogy kellő hozzánemértés esetén tetszőlegesen lassú programok készülnek. Ez a mikrokontrollertől az adatbáziskezelőkig igaznak bizonyult. Sőt, pont az adatábrázolás helytelen megválasztása rontja le legegyszerűbben a sebességet. (Kedvencem: JoelOnSoftware)

Valami bajod van a mikrokontrollerrel? (Pillcsike! Mindjárt elmagyarázom.)
Mivel én mondom meg a regiszter hosszát, hullára nem érdekel.
Ez marhaság, de semmiség ehhez képest:
Mindegy, mert kulturált nyelvekben tetszőleges bitszámú érték ábrázolható...
Ezt a kettőt így együtt véve - bár az utóbbi ugyan igaz - alapja az érthetetlenül lassú programok keletkezésének.

A locsemege féle mikrokontroller példa azért gyengécske, mert az tényleg alapszint.
Magas szinten meg általában senkit sem kell, hogy érdekeljen különösebben az alatta levő architektúra.
Sajnos ez abszolút nem így van. A mikrokontroller a bájt szervezésével borzasztóan egyszerű és áttekinthető. Magas szinten rögtön van cache, a diszknél fizikai blokkméret, a drivernél meg buffer méret. Persze a regiszter mérete is lényeges, amit ugye C esetén int-ként jelölnek, hogy tudjad mi az optimális adatméret. Ez csak az int, míg a lebegőpontos egységekben a különböző adathosszakra általában külön végrehajtóegységet építenek. A 8x256bit altivec mellett is használhatsz tetszőleges adatméretet, csak akkor lemodhatsz az altivec kihasználásáról, ami lényegesen lassab végrehajtást eredményez.
Tehát az állításodban van némi igazság, de az achitektúra elrejtése általánosságban sikertelen. Ezért a hányaveti adatábrázolást a magasszintű rendszer nem tudja ellensúlyozni.
Konkrét példák:
- Nem optimálisan foglalt tömb rendszeres cache invalidálást eredményez lecsökkentve a memória sávszélességét.
- Karakteres feldolgozás esetén a 32->64 bites program 5% lassulást okoz.
- Rossz (egyébként triviálisnak és jónak tűnő) adatábrázolás kb. harmadára lassítja a feldolgozást. Ilyet már optimalizáltam néhányszor "alacsony szinten". Az optimalizálás után visszarakhatod "magas szintre", az előny megmarad.
Ilyen apróságokat általában nem old meg a "magas szint".

>>Mivel én mondom meg a regiszter hosszát, hullára nem érdekel.
>Ez marhaság, de semmiség ehhez képest:
>>Mindegy, mert kulturált nyelvekben tetszőleges bitszámú érték ábrázolható...
>Ezt a kettőt így együtt véve - bár az utóbbi ugyan igaz - alapja az érthetetlenül lassú programok keletkezésének.

Látszik, hogy teljesen fogalom nélkül vagy azzal kapcsolatban, hogy miről van szó.

Az eredeti szavazáshoz szóló hozzászólásom arra utal, hogy mivel én tetvezem a hardvert, hóttmindegy, mekkora hosszú a konstans. Pl. kell egy 37 bites regiszter, akkor lesz.

Szerk: tetvezem helyett tervezem, de a tetvezés is igaz néha :-)

1. Hexadecimális konstans (eredeti téma) nem csak processzornál fordul elő.
2. A regiszter nem szükségszerűen processzorhoz kell, ez egy funkcionális elem adat tárolására.
3. RiscV, OpenRISC, MiniRISC, BPF in FPGA, NES-on-FPGA projektek szeretik ezt a véleményedet (és magasról megmosolyogják :-) )

Mindegy, mert kulturált nyelvekben tetszőleges bitszámú érték ábrázolható (többféle számrendszerben), és az _ karakterrel el is lehet választani az olvashatóság kedvéért.==Az eredeti szavazáshoz szóló hozzászólásom arra utal, hogy mivel én tervezem a hardvert, hóttmindegy, mekkora hosszú a konstans. Pl. kell egy 37 bites regiszter, akkor lesz.

Bocsi, hülye vagyok és még olvasni sem tudok. :(

Tényleg fogalom nélkül vagyok. Nem tudtam, hogy a "magas szint" == Én tervezem a hardvert. :(

Azért a fogalomnélküliséghez kissé hozzájárult az is, hogy nem definiáltad a "magas szintet", pedig felszólító módban volt a mondat. Az áramkör leíró nyelvvel kapcsolatban meg a Amúgy nem csak áramkörleíró nyelv. válasz alapján honnan lenne fogalmam, hogy == Igen, áramkörtervezéssel foglalkozok. Nem véletlen, hogy locsemege is úgy értelmezte gőzöd sincs a hardverről, nem hogy még tervezed is. :)

De ezentúl más világ lesz ám! Mivel én is hardvertervezéssel foglalkozok - zsenge koromat is beleszámolva - több mint 40 éve, de még nem jutott eszmbe: Ezen túl magas szintnek fogom hívni! ;)

Persze azért a fogalomnélküliség talán enyhe túlzás. Az első bitslice processzort úgy 1984-ben teszteltem - bár nem én terveztem, amely 8 bites volt, 16 bites adatúttal és 22 bites utasításhosszal. Ekkorára volt szükség.

( laja | 2016. 08. 21., v – 10:40 )

Szamomra semmilyen szam abrazolasa nem kenyelmes hexaban, dehat ezert vannak ezek a szamitogepek, hogy megoldjak helyettunk?