Hogy működik a bitenkénti osztás?

> A bitenkénti művelet egy (R,R)->R leképzés

Hát nem teljesen. (Különben mégis mi a fene köze lenne a bit fogalmához, ha sem az operandusai, sem az eredménye nem bit? Mitől bitenkénti ez a művelet?)

A bitenkénti művelet alapvetően nem is matematikai, hanem informatikai fogalom. (Bár az informatika is a matematika része, de saját fogalomrendszerrel operál.) A processzorok, illetve a programnyelvek kvázi majd mindegyike a logikai értékeket bájtokon (szavakon, duplaszavakon stb…) tárolja. Ha számok között kell logikai műveletet végezni, akkor a 0-át felelteti meg a hamis, minden más nullától különböző értéket meg az igaznak feleltet meg.

Sőt a programnyelvek jelentős része rendelkezik azzal az optimalizálással, hogy a logikai műveletek sorát csak addig hajtja végre, amíg a végeredmény el nem dől. Pl. ha ez a kód:

if (1==2 && f(x)) …

ahol a && jelenti az ÉS műveletét, akkor mivel az ÉS művelet első operandusa hamis, így az eredmény sem lehet igaz, ezért a folytatás kiértékelése felesleges, tehát az f(x) függvény nem kerül meghívásra.

Szintén sajátossága sok programnyelvnek, hogy visszatérési értékként az utolsó lényeges operátor értékét adja vissza. Pl.:

7 && 12 = 12

12 && 7 = 7

Ez nagyon praktikus tud lenni. Pl.:

érdemjegy = pótvizsga_jegy || vizsgajegy || megajánlott_jegy || 1;

Rövidebb is, érthetőbb is, mint ez:

if (pótvizsga_jegy > 0) érdemjegy = pótvizsga_jegy

else if (vizsgajegy > 0) érdemjegy = vizsgajegy

else if (megajánlott_jegy > 0) érdemjegy = megajánlott jegy

else érdemjegy=1;

~ ~ ~ ~ ~ ~ ~

Ehhez képest a bitenkénti műveletek annyiban térnek el, hogy nem a szám (bájt) egészének feleltet meg logikai értéket és ezek között végez műveletet, hanem a két szám bitjeit veszi sorba és páronként végzi el rajtuk a műveletet. Ahány bitből állnak az operandusok, annyiszor hajtódik végre a művelet:

7 & 12 = 4

12 & 7 = 4

Értsd:

0111₍₂₎ = 7

1100₍₂₎ = 12

7 & 12 = (0 & 1)*8 + (1 & 1)*4 + (1 & 0)*2 + (1 & 0)*1 = 0 + 4 + 0 + 0 = 4 = 0100₍₂₎

Tehát a bitenkénti művelet definíció szerint azt jelenti, hogy két azonos számjegyű kettes számrendszerbeli szám esetén az eredmény n. bitjét úgy kapjuk meg, hogy a két operandus n. bitjén végezzük el a műveletet. Tehát definíció szerint a bitenként végzett műveletnek mind az operandusai, mind az eredménye bit, azaz kettes számrendszerbeli számjegy, azaz 0 vagy 1 kell, hogy legyen.

Szerintem itt álljunk meg. Te egy új műveletet akarsz bevezetni, egy olyan fogalommal ami már teljesen más jelentéstartalommal foglalt. Ez sosem szerencsés. Bár sajnos volt már pár példa a technikatörténelmében, hogy ugyanazt a fogalmat két eltérő dologra használtak. De manapság már mindenki törekszik arra, hogy ilyen ne legyen. Jelenleg a kérdésedben szereplő "bitenkénti" azt jelenti, hogy egy olyan műveletről beszélünk amelyet bitek (azaz két állapotú logikai értékek) között végzünk el, úgy, hogy az eredmény bit legyen. Hogy ehhez, hogy jön az, hogy természetes számra alkalmazzuk nem teljesen értem.

Ezt írod: "... és ez nem az én agymenésem: a legtöbb programozási nyelvbe már implementálták a (Z,Z)->Z bitenkénti műveleteket, mint az éselés, vagyolás és xorzás."

Ez irgalmatlan nagy tévedés! Olvasd el a megfelelő kézikönyveket, ahol ezeknek a működését részletesen ismertetik (meg ehhez nem árt egy kis informatika történetet is megismerni, egyébként csak nagyon zárójelesen jegyzem meg, hogy nem véletlenül tanítják ezt, mert rengeteg dolog az alapján érthető meg). Most sajnos nincs időm végigbogarászni, hogy mikor jelent meg a magas szintű nyelvekben a bitenkénti művelet, de az első C-ben már biztosan volt. Gépi szinten mindig is volt, mert ez az egyik alap művelete az ALU-nak. És a szerencsétlen ALU nem képes másra, mint két regiszterrel (amiben bitek vannak) olyan műveletet végezni aminek az eredményei bitek. (Néhány "modern" nyelvben már megjelent a bit string fogalom is). (Lásd ALU-ból az "L" betű...)

Ez a fogalom gyakorlatilag a C és a C jellegű nyelvekkel egyidőben terjedt el a magas szintű nyelveknél, így később a többi nyelvben is megjelent (pl. a Fortran 66-ban még nem volt bitenkénti művelet, a Fortran 77-ben már van, de az már bőven "C utáni nyelv"). A standard C-ben a mai napig nincs "bináris" (logikai) típus. Ez a művelet egy kényszer volt, mert a C-t eredetileg arra találták ki, hogy operációs rendszer írjanak rajta. Alacsonyszintű programozás elképzelhetetlen bitenkénti műveletek elvégzése nélkül (egyszerűen a processzor kezeléséhez szükséges). Az, hogy a C úgy lett megalkotva ahogy (az összes előnyével, hátrányával) az egy teljesen független dolog a kérdéstől. Szintén adott (és ez ha jól tudom már az első Cobolban és az első Fortranban is így volt), hogy a különböző igények miatt különböző szóhosszúságú változókat használnak. És ez kiemelten a bitenkénti műveletek esetén igaz.

Szintén értelmetlen amit írtál, két eltérő hosszúságú szón értelmezni a bitenkénti műveleteket. Definiálni kéne, hogy melyik oldalról egészítjük ki 0-kkal a két szót. Ez pl. abban az esetben kérdéses ha BCD-ben tároljuk a számokat (ld. pl. Z80 mikroproci és abban a korban elterjedt volt ez is).

Ami meg különösen érdekes és nagyon messzire vezetne amikor azt írod, hogy "R->R leképzés" (tetszőleges valós szám). Én úgy tanultam valamikor ezt a szakmát, hogy a számítógépben nincs valós szám. A számítógépben csak 0 és pozitív egész számok vannak (ld. Neumann-elvek). De még ez is erős kijelentés. Jelenleg elterjedten a 0-2-4-8-16 stb. súlyozott bináris alakot használjuk, de ez nem mindig volt így, nem kevés helyen találkozunk BCD (akár több jegyű) ábrázolással, illetve néhány helyen még mindig felbukkan a Gray kód.

A negatív és a nem egész számok ábrázolására ma is legalább két tucat alapvető eljárás létezik.

Amit írsz, hogy kilépsz a bináris térből, és bitvektorokról, és valós számokról beszélsz az fogalom zavar megint. Ha azt mondod "bitenkénti" akkor mindenki a bináris világra fog gondolni, és bit stringek jutnak az eszébe, amelyek ott kóricálnak a proci ALU-jában. Jelenlegi technikai fejlettségi szintünkön az ALU-knak két forrás operandus regisztere és egy eredmény és egy jelző regisztere van. Az eredmény regiszterbe kerül a két forrás operandus regiszter és a kijelölt művelet által meghatározott érték, a jelző regiszterbe (általában flag-nek szokták nevezni) pedig az eredmény alapján kerülnek be az egyes bitpozíciókra értékek (pl. az eredmény 0, az eredmény negatív, az eredményben van túlcsordulás, 0-val való osztás /ha tud az ALU osztani/ stb.). És itt is előjön, hogy pl. az ALU flag regiszterén nincs értelme más művletet végezni mint bitenkénti, mert ott nem a szokásos 0-2-4-8... súlyozást használjuk, hanem az egyes bitpozícióknak más és más jelentése van.

Amit te itt keversz az, hogy definiálni akarsz a valós számokon egy olyasmi műveletet mint az XOR. Akkor az már baromira nem bitenkénti művelet lesz.

A korábban említettek szerint az ALU jelenleg 2 forrás regiszterrel és egy eredmény regiszterrel bír, és ezért a bitenkénti műveletek is erre vannak "definiálva". Ezért továbbra is összesen 16 db. ilyen létezhet. Az, hogy mindenféle csűréssel csavarással ebből "végtelen számút"-t csinálsz az OK, de az már nem a bitenkénti művelet fogalma.

A matematika a fizikai világból képzett absztrakciókkal foglalkozik. Az, hogy 8, az a matematika szempontjából mindegy, hogy 8 alma, 8 körte, 8 cm, vagy 8 dimenzió. A lényeg, hogy van egy egzakt eljárás, amivel a fizikai világ létezőit megfeleltetjük a matematikai absztrakt fogalmakkal. Viszont a matematika a fogalmak jelentésével foglalkozik elsősorban. A matematika szempontjából a 8 az egy olyan fogalom, ami bizonyos relációban áll a 7-tel, mint absztrakt fogalommal (nagyobb nála), és bizonyos relációban áll a 9-cel, mint absztrakt fogalommal (kisebb nála).

A matematika szempontjából az, hogy a 8, mint absztrakt fogalom úgy van-e leírva, hogy "8", vagy úgy, hogy "0100b", vagy úgy, hogy "VIII" az nem számít. Ezek jelek, a matematika meg a jelentéssel és nem a jelekkel foglalkozni. Persze van a matematikának olyan ága, ami a jelekkel is foglalkozik – mondjuk beszél kétszámjegyű számokról –, de ilyen esetben is a jelekből egzakt módon képez valami absztrakt fogalmat, és ezzel a jelentéssel foglalkozik.

És itt van a probléma. Ugyanis a XOR logikai művelet. Kizárólag kétállapotú „objektumokkal” képes dolgozni. Az, hogy megfeleltetünk egy valós számnak egy bitsorozatot az egy dolog. De ez a jelről és nem a jelentésről szól. Így viszont kapunk egy bitsorozatot, aminél megint teljesen mindegy, hogy az mit reprezentál, természetes számot, pixelszínt, jogosultsági flageket. A bitsorozat elemein végezzük el aztán a XOR műveletét, mert azokon már el lehet.

De hogy egy természetes számot hogyan feleltetsz meg egy bitsorozatnak, az nem egy kizárólagos egyedüli módszer. Nyilván magától adódik az, hogy a szám kettes számrendszerbeli alakjával dolgozunk. Részben azért, mert ez eléggé hatékony bizonyos esetekben. Máskor meg máshogy feleltetünk meg számoknak bitsorozatokat, mert adott esetben meg az a hatékonyabb. Pl. a BIOS esetén szokás volt BCD kódolást használni. Megint más területen meg a Johnson-kódot használjuk, mert ott meg az a praktikusabb. De van vagy egy tucat módszer, amivel természetes számoknak bitsorozatokat lehet megfeleltetni. (9-es komplemens, Aiken-kód, Gray-kód stb…)

A negatív számoknál viszont már nincs annyira magától adódó megoldás. Van egyenes, komplementeres, többletes, meg negációs kódolás is. Mindegyiknek van logikája, előnye, meg hátránya is. Pl. a kettes komplementer azért vált általánossá, mert az így kapott bitsorozaton való műveletvégzés ugyanúgy működik, mind természetes számoknál. Cserébe a számok összehasonlítása az, ami problémásabb. A többletes kódolásnál az összehasonlítás is jó, az összeadás, kivonás szempontjából is jó, csak ott meg az a probléma, hogy a pozitív számokból kapott bitsorozat nem a kettes számrendszerbeli alaknak felel meg.

A gyakorlatban a kettes komplementer terjedt el leginkább, de nem azért, mert ez logikusabb, vagy bármilyen elvből következően lenne helyes választás, hanem praktikus okok miatt, számítási kapacitás szempontjából volt ezt választani előnyösebb. A matematikát meg nem határozhatják meg praktikus korlátok és lehetőségek.

Tehát esetleges, hogy egy negatív számhoz milyen bitsorozatot rendelünk hozzá. Viszont ha más a bitsorozat, akkor más a biteken végett művelet után kapott bitsorozat, és az lehet, hogy egészen más számnak felel meg.

Kettes számrendszerbeli helyiértékes számábrázolás esetén 37 XOR 11 = 46. Viszont BCD kódolás esetén meg 37 XOR 11 = 26. Sőt BCD esetén a 18 XOR 26 az nem is értelmezhető, vagy az értelmezése esetleges, önkényes.

De itt maga a jelölés is hazudik, mert a XOR műveletet nem a számokon, hanem az annak megfeleltetett bitsorozat bitjein végezzük el, amiből kapunk egy teljesen más műveletet, amit ugyanúgy XOR-nak nevezünk. Tulajdonképpen nem kiterjesztése ez a logikai XOR műveletnek más számhalmazra, hanem két különböző művelet, csak éppen azonos névvel.

És pont emiatt nem lehet kiterjeszteni a természetes számokon értelmezett un. „XOR” műveletet csak úgy negatív számokra, racionális számokra, valós számokra. Mert az nem egzakt és triviális, hogy számoknak hogyan feleltetünk meg bitsorozatokat.

~ ~ ~

Oké, mindezt tegyük zárójelbe. Definiálunk egy XOR nevű műveletet, ami (ℝ,ℝ)→ℝ leképezés. Lehet, hogy ez a természetes számok halmazán még értelmezhető bitenkénti műveletnek, de kiterjesztve már nem feltétlenül. De az sem kizárt, hogy kiterjesztve is még lefedi a bitenkénti művelet jelentéstartamát, ha megfelelően választjuk meg a számok – mint jelentések – és a bitsorozatok – mint jelek – közötti megfeleltetést.

De innentől kezdve már egy valós számok halmazán értelmezett műveletről van szó. Lehet ennek az iteráltját venni? Talán. Ehhez viszont két összefüggés kell:

i[0] = ı

i[n+1] = f(i(n))

A második nálad megvan, az első hiányzik.

De vegyük észre, hogy ezzel csak egy (ℝ,ℕ) →ℝ műveletet definiáltunk csak. Ennek egy (ℝ,ℝ) →ℝ műveletre való kiterjesztése már nem az iterációból következik, hanem permanenciaelvek segítségével történhet meg. Már ha megtörténhet, ahogy már írtam a tetrációnál törtkivevőkre már nem lehet egyértelműen kiterjeszteni a műveletet.

Viszont az borítékolható, hogy ha még sikerül is iterációval egy új műveletet definiálni, akkor az nem vezethető vissza bitenkénti műveletre, ha ugyanazokat a szám↔bitsorozat megfeleltetéseket használjuk. Tehát az így kapott művelet nem bitenkénti művelet lesz.

Továbbra sem érted. Az XOR nincs értelmezve [0;8] intervallumon. Sőt olyan, sincs hogy "8". Ahol az XOR (a kérdésedben szereplő "bitenkénti") definiálva van két állapot van, ezt a könnyebbség kedvéért jelöljük 1-el és 0-val. De pl. az angol nyelvű szakirodalmak következetesen L és H értékeket használnak (logikai alacsony és magas), pont a tévesztés esélye miatt.

Tehát van egy kétállapotú rendszerünk amiben van két állapot, és nem két mennyiség. Mert nem igaz az, hogy 1>0 de az sem igaz, hogy a 0>1 nincs relációs művelet. Ugyanígy nincs olyan, hogy az L>H vagy a H>L. Ez a kétállapotú logikai rendserek sajátossága. És itt nincs olyan, hogy 0-8 intervallum. Nincs számegyenes sem, és nincs intervallum fogalom sem. Például (most tekintsünk el a mindeféle genetikai /pl. down kór/ és pszichés eltérésektől) valaki vagy fiú vagy lány. Nincs olyan, hogy kicsit lány de már majdnem fiú. És nem mondhatjuk azt sem, hogy a lány > fiú vagy az egyik jobb mint a másik. Ez egy két állapotú rendszer. Ezen van értelmezve az XOR művelet (vagy függvény), nem máson. És nincs fűrészfog meg nincs semmi más. Egy jó nagy PONT van itt a mondat végén.

Az egy mellékszál, hogy a két állapotú rendszerek boole alegebrát alkonak (ugyanúgy mint pl. a halmazok).

Most ugorjunk az időben vissza kb. 80 évet. Nagyon komolyan megfoglamazódott a számítógépek iránti igény. A kezdetekben két módszer "versenyezett" az egyik a decimális gépek voltak (Mauchly és Eckert vezetésével) a másik módszer a bináris gépek voltak (Atanasof, Zuse, Kozma /bár ő kevésbé ismert/) gyakorlatilag mire a naptár 1939-ről 1940-re váltott jónéhány működő bináris gép volt. Eltelt pár év és 1945-re Macuhly és Eckert elkészítették az első programozható "elektronikus" számítógépet (ENIAC néven), előtte működő "általános célú, programozható" számítógépe gyakorlatilag csak Zuse-nak volt, néhány kezdetleges vázlatig és részegységig Kozma is eljutott, de az ő gépe csak később készülhetett el (II. vh.zsidó üldözés stb.). Az ENIAC decimális gép volt, az egyik lényeges eleme egy 10 értékű (néhány helyen 11 illetve 12 értékű) ún. gyűrűs számláló. A felépítése "soros" volt, azaz az ALU-ba először be lett küldve az első operandus 1. számjegye, majd a 2. majd a 3.és így tovább, majd jött a következő operandus 1.számjegye 2. 3. és így tovább, majd (hasonlóan mint az ún. fordított lengyel elvnél) ki lett jelölve a művelet (egyes műveleteket a betöltés előtt kellett kijelölni, nem volt olyan egyszerű, ezért nem volt teljesen forditott lengyel a gép).

Majd jött 1946. és komoly szerepet kapott a történetben Goldstine, aki már sejtette, hogy itt gáz van, és elakadás van. Macuhly és Eckert megbízást kaptak egy javított változat elkészítésére ez lett később az EDVAC nevű gép. Goldstine felkeresett egy Neumann János nevű matematikust és megkérte, hogy szakértőként ugyan segítsen már be a dologba, mert itt valami gáz van. Neumann és Goldstine (részben Eckert-tel, és Mauchlyval illetve az ő munkatársaival, de a fő szerep Neumanné és Goldstine-é) megnézték, hogy hol vannak az ENIAC gyengeségei és min kéne változtatni,és Neumann felvetetette, hogy szakítsanak a decimális művelet végző egységgel és legyen a gép bináris (mint Zuse és Atanasof gépei), ezekből a megbeszélesekből született Neumann feljegyzése (First draft of Edvac...) aminek az alapjait ma Neumann elvekként tanítanak az iskolában.

Azóta binárisak a számítógépek. És ekkor rögtön jött a kérdés, hogy hogyan írjuk át a decimális számokat bináris alakba. Azaz, egy bitstringben (Vagy más néven gépi szóban) az egyes bitpozíciókhoz milyen jelentést párosítsunk. Az EDVAC esetén még igazán szóról sem lehetett beszélni, mert ez egy soros gép volt, mert még csak soros memóriát tudtak csinálni, így a művelet végző egységes soros volt. Azaz az ENIAC-hoz hasonlóan az egy mennyiséghez tartozó bitek egymás után kerültek be a művelet végző egységbe (később ebből lett az ALU). Pár évvel később ahogy fejlődött a memória rájöttek, hogy jobbak a párhuzamos ALU-k és ma ezeket használjuk (azért párhuzamos, mert a gépi szó egyes bitjei egyszerre vannak az ALU bemeneti regiszterében). Ez egy kis történeti áttekintés volt. De ez nélkül a továbbiak nehezen érthetőek.

Szintén nagyjából ez a korszak volt (meg az azt megelőző kb. 100 év, fontos dátum még az 1840 a történetben) amikor kezdtek egyre hatékonyabb bináris kódokat kidolgozni. Az első ilyen ún. változó szóhosszúságú kód (bár nem teljesen bináris) a Morze kód (ez kapcsolódik 1840-hez). Valamikor az 1920-as évek elejére már nagyon hatékony kódrendszerek voltak (géptávíró, illetve automata telefonközpontok miatt). Ekkora már bőven egy tucat fölött volt az a módszer ahogyan egy decimális számot bináris kódra át lehetett írni. Mindegyiknek megvolt a maga jelentősége pl. volt 1-2-4-5 kód is illetve használták az 1-2-4-6 kódokat is (azaz ezek feleltek meg az egyes bitpozíciók helyi értékének). Ezt már korábban amúgy a kolléga is leírta. Ma (egy pár éve elkezdtem összeszedni, 80 körülig jutottum) közel 100 darab eljárás van csak arra, hogy természetes számokat átírjunk gépiszó alakba. És ebből csak egy az 1-2-4-8-(2^n) súlyozású kód. Ezek nagy részét valakik, valamilyen célból - sokat meglepően elterjedten használták pl. az 1-2-4-6 kódot a telefonközpontoknál. Ez egy látszólagos káosz. De ennek történelmi okai vannak (ld. fent). Neumann nagy ötlete az volt, ha a bináris a gép akkor a program kezelhető adatként is, és ugyanazok a tárolók felhasználhatók a program és az adat tárolására. Az ENIAC-nál ez különösen jól látszott, mert ott a program bináris volt (kapcsolókkal lehetett beállítani), míg az adat decimális. Ennek folyománya lett, hogy egy az ALU-ban lévő szóról senki nem tudja megmondani, hogy az most pontosan mi, van egy bitfolyam (sorosan, vagy párhuzamosan végülis ez is mindegy) amivel műveletet végez. Ha a kijelölt művelet "bitenkénti" akkor az ALU két forrás regiszterében lévő bitstringen bitenként (pozíció helyesen) hajtja végre a kijelölt műveletet ("L" betű az ALU-ból). Ha feltételezzük, hogy egy "szám" kódolt alakja van az ALU két regiszterében (és itt az ALU határozza meg, hogy milyen kódot vár) akkor van értelme annak, hogy aritmetikai műveletet végezzen el az ALU ("A" betű a névből), hogy az ALU milyen műveletet tud elvégezni csak és kizárlóg az ALU tervezőinek a fantáziájától függ (csak a történelmi hűség kedvéért pl. a Z3 /relés/ számítógép aritmetikai egysége egy egészen sajátos kódolású lebegőpontos számokkal tudott aritmetikai műveleteket végezni /ha jól emlékszem, de régen néztem ilyen mélyen a Z3-at összeadni, szorozni, -1-el szorozni, és talán osztani is tudott, volt külön *2 és /2 művelet, és a két mennyiség közül meg tudta mondani melyik a kisebb és melyik a nagyobb, vagy egyenlőek-e). Megint elkalandoztunk.

Gyakorlatilag ez a része a számítógépnek a mai napig változatlan. Így nyer értelmet az a "kifejezés, hogy bitenkénti" művelet. Mert azzal arra utalunk, hogy az aLu-ból az L funkciót használjuk, az ALU két forrás regiszterében lévő bitstringekkel az egyes bitpozíciókat tekintve egymástól függetlenül végezzük el az adott műveletet. Azaz pl. az 1-es biten lévő forrás adatoktól független lesz a 2-es biten lévő eredmény. Ennyit jelent a bitenkénti művelet. Itt továbbra is csak az ismert 16 két változós logikai függvény értelmezhető, mert mást nem tudunk.

Az egy "szerencsétlenség" de a Neumann elv következménye, hogy az ALU nem tudja, hogy a két bemeneti regiszterében lévő bitstringet hogyan kell értelmezni,ő elvégzi a kijelölt műveletet, úgy, ahogy a művelet megkívánja. Azaz képes arra, amitől egy matek tanár hülyét kap ha összeadsz 8 krumplit 4 almával. Az ALU nem tudja, hogy az egyik mennyiség 8 krumpli a másik 4 alma, ő össze fogja adni a 8+4-et. Az eredménnyel meg kezdjél amit akarsz. Ebből lesz az, hogy "látszólag" elvégzi a számítógép két természtes számon az XOR műveletet, de az eredmény nem szám lesz, hanem a két számot reprezentáló bitstring egyes bitjeinek a páronkénti XOR-ja. Ugyanezt írta a kolléga pár hozzászólással korábban, hogyha BCD-ben van a két mennyiség az XOR-zásnak lehet "értelmetlen" eredménye. Az megint csak egy kis hab a tortán, hogy a mai magasszintű programnyelvek valamennyire vigyáznak arra, hogy két totál eltérő adat típusra ne lehessen bitenkénti XOR-t ráengedni, de ez csak azért van így, hogyha a programozó figyelmetlen volt ne legyen belőle mégnagyobb káosz mint ami aznélkül is kialakult volna.

Amit Neumann leírt (illetve ezt konkrétan Goldstine írta le egy emlékiratában), hogy már az elején amikor ezt a javaslatot felvetették tudták, hogy ez a felépítés pont ilyen "káosz"-hoz fog vezetni, mert innen kezdve a számítógép már sose fogja tudni azt, hogy a két mennyiség amit összeakarunk adni az összeadható-e egyáltalán vagy sem. Azaz simán összefogja adni a 8 körtét az 5 krumplival. Gyakorlatilag 1946 közepe óta "minden" programozó tudja, hogy ez az ő felelőssége és az ő dolga, hogy figyeljen arra, hogy milyen adatokkal milyen műveletet fog elvégeztetni, mert elfog végezni a számítógép olyan műveletet aminek nincs matematikai értelme. Az, hogy ez a rész a mai okatatásból kimarad és ez rengeteg programozónál fehér folt az sajnos az oktatás (és valamilyen szinten a C nyelv pongyolaságának) a hibája. Tehát elvégezhető a művelet amit te felvettél, hogy egy A és egy B értéket reprezentáló bitstringen bitenkénti XOR-t hajtsunk végre, de ennek az eredménye nem egy értelmezhető szám lesz hanem egy bitstring. Ez kicsit olyan mintha a mákostésztába beleboritanád a tökfözeléket. Mindekettő külön-külön értelmezhető, a kettőt együtt mosléknak nevezik és emberi fogyasztásra vajmi kevéssé alkalmas. Ugyanez történik itt is van két számod és beleborítod valamibe és kijön valami amiről nem tudjuk, hogy mi. Gondolj pl. a BCD alakra. 5 (XOR?) 8 ebből mi lesz:

0101 XOR 1000 = 1101 ez BCD-ben értelmezhetetlen, és simán használnak még sok esetben BCD-t, simán lehet a két számod amit felírtál BCD alakban. Ugyanis arról még nem beszéltünk sehol, hogy hogyan írjuk át a természetes számokat bitstring formába. És akkor jön amiről már többször beszéltünk a negatív és a nem egész számok átírása (ezekből már közel 300 eljárás létezik, legalábbis ott hagytam abba ezek összeszedését jó pár éve).

Bocs inkább befejezem, mert ez nagyon messzire vezet már.

28/28 A kérdező kommentjér:

Akkor összefoglalom. Teljesen konkrétan ott van a válaszol elején: Totálisan értelmetlen az XOR függvény nem bitre. Nincs értelmezve. És nincs értelmezve az XOR függvény a [0,8] intervallumon sem. Sőt semmilyen intervallumon nem értelmezhető. Mert abban a halmazban amiben ez értelmezve van nincs kisebb nagyobb, nincs sorrend, és nincs "intervallum" vannak L és H (amit lustaságból 1-0-val jelölünk), vagy van jobb és bal. És ezen kívül nincs semmi más.

És egész számon sincs értelmezve.

És nem létezik semmilyen "fűrész fog", mert egyszerűen nem tudjuk értelmezni a kijött értéket, mert nincs értelme. Az XOR függvény (és fontos, hogy az XOR az valójában függvény) az XOR értelmezési tartománya bit (két állapotú) és az érték készlete szintén bit (két állapotú).

Mert a "fűrész fog" csak egybizonyos számábrázolás esetén jön ki. De pl. gray kód esetén valami egészen más fog kijönni, BCD esetén meg tele lesz lukkal, 1-2-4-6 kód esetén megint tele lesz lukkal. És most csak a 3 leggyakrabban használt kódolásról beszélek.

Tehát az a függvény nem létezik amiről itt beszélsz. És nem lehet kiterjeszteni sem, mert semilyen értelme sincs.

Itt ha lefordítom magyarra (csak nem akartam ilyen durván fogalmazni), és lehámozom róla a bonyolult matek jelelőséket, arra vagy kíváncsi, hogy "4 körte plusz 6 körte az hány alma". Mert erről szól a "fűrészfogad" mert nem tudjuk értelmezni az eredményt, mert nem értelmes. Mert mind a bemeneti "változó" mind az "eredmény" nincs benne a függvény értelmezési tartományában és érték készletében.

És attól, hogy a számítógép ezt "kiszámolja" attól még nem lesz értelmes az eredmény. Ld. összeönthető a mákostészta a tökfözelékkel is, csak megenni lesz kicsit nehéz.

És ezt indokoltam részletesen. És ennek a hosszabb magyarázatát írtam le fent. De feltehetően nem ment át a lényeg.