XOR-Verknüpfung 2er Zahlen

apfel schrieb:
> 9356 xor 2608 = ?

Ich hab mal in mein Mathebuch geschaut. Da kommen zwar viele Operationen 
vor, die man mit zwei Zahlen anstellen kann wie addieren, multiplizieren 
oder potenzieren, "xor" kommt da aber nicht vor.

Mike B. schrieb:
> Der ganz faule Windows-calc.exe-Nutzer erhält in der
> Programmierer-Ansicht 11.964 als Ergebnis, aber ob das stimmt?

Auch bei 9356.0 xor 2608.0? Muß ja mathematisch das Gleiche sein.

MfG Klaus

Yalu X. schrieb:
> In welcher Programmiersprache?
Hat nix mit Programmierung zu tun!

Walter S. schrieb:
> xor ist eine logische Operation die einzelne Bits verknüpft und sinnfrei
> bei float-Zahlen
Genau so sieht das aus.

Und wenn man das Umwandelt dez->bin und das dann einfach auf einem Blatt 
Papier exklusiv-oder verknüpft, kommt tatsächlich 11964 raus. Aber das 
kann man doch auch selber herausfinden, oder?

Ein Fallstrick könnte sein, das "modulo 2 add" fälschlicherweise auch 
als XOR bezeichnet werd, es aber wegen den Carry zu anderen 
Bitmustern/Ergebnissen kommt:
http://homepage.cs.uiowa.edu/~ghosh/2-24-09.pdf

so ein XOR mit Übertrag wird bei Codierungen gern benutzt, Galois-Felder 
und so.


Mike B. schrieb:

> selbst mit den Zwischenschritten bin->dez((dez->bin) XOR (dez->bin))
> kommt das gleiche Ergebnis

muss nicht unbedingt decimal sein könnte auch hex sein, oder ASCII.

Walter S. schrieb:
> xor ist eine logische Operation die einzelne Bits verknüpft und sinnfrei
> bei float-Zahlen

Im Titel steht: XOR-Verknüpfung 2er Zahlen. Und eine logische 
Operation außer größer, kleiner oder gleich ist bei allen Zahlen 
sinnlos. In lua z.B. sind Zahlen immer floating point, in anderen 
Sprachen ebenso. Die ganze Frage ist sinnfrei und ein etwaiges Ergebnis 
höchstens Zufall.

MfG Klaus

Klaus schrieb:
> In lua z.B. sind Zahlen immer floating point, in anderen
> Sprachen ebenso.

Du willst damit sagen, daß es keine ganzen Zahlen gibt? Nirgends?
Die Tatsache, daß hier zwei Zahlen stehen, in denen kein Komma vorkommt, 
macht dich gar nicht stutzig? Das sind also auch keine ganzen Zahlen, 
sondern Kommazahlen?

Du sagst:
> "immer floating point, in anderen Sprachen ebenso."
Also ist die Integer-Zahl "1234" ebenfalls "floating point"?

Mach dich mal bitte schlau über Zahlensysteme...

Hallo

IMHO ist XOR mathematisch gesehen die Addition zweier Repräsentanten 
modulo 2. (Also Addition ohne Übertrag - daher auch manchmal Halbadder 
genannt)

9356 xor 2608 = 9356 + 2608 (mod 2) = 0 + 0 (mod 2) = 0

Die meisten Programmiersprachen (vermutlich auch Personen) meinen aber 
mit xor im Context mit Zahlen eigentlich "bitweise xor". (Pascal 
basierte Sprachen z.B.)

Unter der Annahme es handelt sich um Zahlen des Dezimalsystems (so wie 
es gängige Konvention ist)

9356 xor 2608 =

    (10010010001100)d
xor   (101000110000)d =

    (10010010001100)d
xor (00101000110000)d =
--------------------------
    (10111010111100)d = 11964


9356 xor 2608 = 11964

MfG

Also falls der TO wirklich an einem Ergebnis interessiert ist:

a) sollen Deine Zahlen HEX- oder Dezimalzahlen sein? (binär und oktal 
fällt zum glück aus)
b) möchtest Du das Ergebnis in Hex, Dezimal, Binär, ASCII oder mittels 
CRC-CCITT gesichert?

c) wie sieht Dein bisheriger Ansatz aus, was klappt, was nicht?

npn schrieb:
> Du willst damit sagen, daß es keine ganzen Zahlen gibt? Nirgends?
> Die Tatsache, daß hier zwei Zahlen stehen, in denen kein Komma vorkommt,
> macht dich gar nicht stutzig? Das sind also auch keine ganzen Zahlen,
> sondern Kommazahlen?

Richtig, mathematisch ist das so. Und stutzig macht mich da gar nichts, 
führende Nullen schreibt man nicht, ein Komma, wenn nur Nullen folgen, 
auch nicht. Menschliche Faulheit oder Papier sparen.

npn schrieb:
>> "immer floating point, in anderen Sprachen ebenso."
> Also ist die Integer-Zahl "1234" ebenfalls "floating point"?

Richtig, Zahlen in lua sind immer floating point, gibt auch andere 
Sprachen, die so arbeiten. In wieder anderen Systemen sind Zahlen 
strings, so wie man es schreibt, und die können auch rechnen. Oder sie 
werden je nach Operation immer passend gewandelt.

apfel schrieb:
> 9356 xor 2608 = ?

ist sinnfrei, wenn man nicht noch einige Bedingungen dazu schreibt:

die beiden Zahlen müssen Ganzzahlen sein, sie müssen intern binär im 
Zweierkomplent dargestellt werden, nicht BCD und auch nicht als 
Zeichenstring, ...

MfG Klaus

Klaus schrieb:
> Richtig, Zahlen in lua sind immer floating point

Warum wird dann in lua zwischen "integer" und "float" unterschieden?
Zitat (Wiki):
"Neben den Datentypen nil, boolean, number
(mit den internen Subtypen integer und float),"
                           =================

Oder noch ein anderes Zitat (lua reference manual):
"The conversion from float to integer checks whether the float
has an exact representation as an integer (that is, the float
has an integral value and it is in the range of integer
representation). If it does, that representation is the result.
Otherwise, the conversion fails."

Wie kann eine Conversion fehlschlagen, wenn es doch nur "floating point" 
gibt?
Wie kann es sein, daß es überhaupt eine Conversion zwischen "integer" 
und "float" gibt, wenn es laut deiner Aussage nur "float" gibt? Und an 
vielen Stellen des manuals wird ausdrücklich auch von "integer" 
gesprochen!

Also entweder lügt das lua reference manual, oder der Irrtum ist auf 
deiner Seite!

npn schrieb:
> Also entweder lügt das lua reference manual, oder der Irrtum ist auf
> deiner Seite!

Hast aber recht, da hat sich wohl was geändert. Im "Programming in lua" 
von Roberto Ierusalimschy, was ich grad aufgeschlagen hab, steht

> The number type represents real (double-precision floating-point)
> nunmbers. Lua has no integer type, as it does not need it.

in einem neueren Text steht:

> Therefore, the programmer may choose to mostly ignore the difference
> between integers and floats

Aber falls dir lua nicht gefällt, schau mal bei Javasript vorbei.

> JavaScript has only one type of number.
> Numbers can be written with, or without, decimals:
> var x = 3.14;     // A number with decimals
> var y = 34;       // A number without decimals

MfG Klaus

PS: "lügt" ist ja schlimm, kommt das manual dann in die Hölle? Bei mir 
ist das zum Glück ja nur ein Irrtum.

Klaus schrieb:
> PS: "lügt" ist ja schlimm, kommt das manual dann in die Hölle? Bei mir
> ist das zum Glück ja nur ein Irrtum.

Naja, entweder lag dort der Fehler oder bei dir. Eine andere Möglichkeit 
sah ich nicht. War vielleicht etwas drastisch ausgedrückt. Aber schön, 
daß wir diesen Irrtum ausgeräumt haben :-)

War nicht persönlich gemeint...
Nichts für ungut :-)

npn schrieb:
> War nicht persönlich gemeint...
> Nichts für ungut :-)

Hab ich auch nicht so aufgefasst. Was sich aber ergeben hat ist, daß 
über die Zeit sich die Innereien von lua geändert haben. Mein Zitat 
bezieht sich auf die Version 5.0, deines IMHO auf 5.3. Beide sind sicher 
nicht grundfalsch, eher kontext oder zeitabhängig. Daher stoßen mir 
moralische Begriffe wie "Lüge" im technisch-wissenschaftlichen Bereich 
sauer auf. Das wollte ich mit meinem Bezug auf "Hölle", die ebenfalls 
keine wirkliche technische Relevanz hat, zum Ausdruck bringen. Hätte 
vielleicht ;) dahinter schreiben sollen

MfG Klaus

Mike B. schrieb:
> Wer 9356, 2608 und 11964 flux auf dem Papier von dez zu bin umwandeln
> kann, ja der kann diese Aufgabe auf dem Papier lösen. ;-)

Stell dir vor, der Taschenrechner wurde schon erfunden!
Gibt's übrigens auch als App für's Handy :-)

Adele schrieb:
> Stell dir vor, der Taschenrechner wurde schon erfunden!
> Gibt's übrigens auch als App für's Handy :-)

Jepp, man kann dumm bleiben und es sich einfach machen oder man übt mal 
sowas mit 'Hirn' zu lösen.
:-)

Der Andere schrieb:
> Adele schrieb:
>> Stell dir vor, der Taschenrechner wurde schon erfunden!
>> Gibt's übrigens auch als App für's Handy :-)
>
> Jepp, man kann dumm bleiben und es sich einfach machen oder man übt mal
> sowas mit 'Hirn' zu lösen.
> :-)

Genau, und eine Baugrube für ein Hochhaus hebt man auch mit der 
Sandkastenschippe aus. Man soll es sich ja nicht zu einfach machen und 
geeignete Werkzeuge dafür benutzen! ;-)

Der Andere schrieb:
> man kann dumm bleiben und es sich einfach machen

oder man macht es wie Klaus und erklärt einfach, dass es eine 
XOR-Verknüpfung zweier Zahlen überhaupt nicht gibt - Problem gelöst, 
Gehirn geschont.

Georg

Georg schrieb:
> oder man macht es wie Klaus und erklärt einfach, dass es eine
> XOR-Verknüpfung zweier Zahlen überhaupt nicht gibt - Problem gelöst,
> Gehirn geschont.

Wenn man das denn hat :-)

Irgendwie scheint mit die Diskussion recht sinnfrei - da gibt es 
schlicht nichts zu diskutieren!

Georg schrieb:

> oder man macht es wie Klaus und erklärt einfach, dass es eine
> XOR-Verknüpfung zweier Zahlen überhaupt nicht gibt


Klar gibt es die, nennt sich XOR-Verschlüsselung:
https://www.heise.de/security/artikel/XOR-Verschluesselung-270952.html

Bitwurschtler schrieb:
> XOR-Verschlüsselung:

Für Schwachmaten? Nix Verschlüsselung - einfach XOR ... nix besonderes.

Rolf M. schrieb:
> Johann L. schrieb:
>> Oder für Faule, weil ja bald Hex eingeführt wird (scnr)
>
> Hätte Gott gewollt, dass der Mensch Computer baut, hätte er ihm 16
> Finger gegeben.

Jetzt frag ich mich wieviel Finger ein Baske hat, oder ein Babyloner 
hatte:
https://en.wikipedia.org/wiki/List_of_numeral_systems 8-O

Rainer V. schrieb:
> Rolf M. schrieb:
>> Hätte Gott gewollt, dass der Mensch Computer baut, hätte er ihm 16
>> Finger gegeben.
>
> Wozu denn? 10 Finger sind zum Schälen einer Banane voll ausreichend, zum
> Bau von Computern ebenso.
>
> C. A. Rotwang schrieb:
>> Jetzt frag ich mich wieviel Finger ein Baske hat, oder ein Babyloner
>
> Weiß ich auch nicht, habe aber gelesen, daß es bei Bewohnern im Bereich
> des Bikini-Atolls nach den A-Bombentests Nachwuchs mit 6 Fingern pro
> Hand gegeben haben soll. Von "besser rechnen können" war da aber keine
> Rede.

Die 6-fingrigkeit gibt es erst nicht erst seit den 
Wasserstoffbombentest, genetisch also "von Gott" ist wohl die Tierwelt 
ohnehin auf eine variierende Anzahl von Fingern vorprogrammiert, die 
auch nicht unbedingt symmetrisch verteilt sein muß: 
https://de.wikipedia.org/wiki/Polydaktylie

Die "Zivilisationsstifter" im Zweistromland (Sumerer) rechneten im 
60iger system, die in Amerika (Maya) dagegen im Zwanziger. Und schaut 
man sich das römische Zahlensystem an, glaubt man fast, das wäre im 
Sägewerk entstanden.

-> ein natürliches System gibt es IMHO nicht, es ist immer subjektiv 
welches System angewandt wird. Und da macht es Sinn Operatoren für 
beliebige Symbolbreiten zu definieren, wie man es in der Algebra mit dem 
https://de.wikipedia.org/wiki/Galoisfeld macht. Da aber die Arbeiten der 
Akademiker und Kryptographen nicht in der Allgemeinheit vertraut sind, 
entsteht der Eindruck das XOR nur bitweise Sinn macht - dem ist aber 
nicht so.

PS:
Interessanter Fakt: Das "XOR-Problem" hätte fast die Forschung zu 
Neuronalen Netzen beendet, weil die ursprünglich modellierten Netze 
keine XOR-Funktion erlernen konnten.

Yalu X. schrieb:

> Viele Programmiersprachen definieren tatsächlich einen Operator, der
> zwei Integer-Zahlen bitweise XOR-verknüpft. Nur heißt dieser Operator –
> abgesehen von ein paar nicht der Norm entsprechenden Basic- und
> Pascal-Dialekten – meist nicht "xor", sondern bspw. "^".

Das ist genau, was ich an diesen C-lern so abgrundtief hasse. Die 
Arroganz, "ihre" Sprache für die allgemein gültige Norm zu halten.

Im übrigen: was ist wohl leichter als xor-Operation zu lesen, das, wo 
direkt "xor" dransteht oder das, wo irgendein ziemlich willkürlich 
gewähltes Zeichen die entsprechende Operation repräsentiert?

Soll heißen: C ist ein Sprache, die geschaffen wurde, um möglichst 
kryptisch und unlesbar zu sein. Basic und Pascal hingegen wurden 
geschaffen, damit man den Code recht einfach lesen kann, zumindest wenn 
man Englisch als natürliche Sprache kann.

Rolf M. schrieb:
> Warum sollte man mit 6 Fingern pro Hand auch besser rechnen können?

60 Finger wären korrekter, braucht(e) man aber gar nicht:
https://de.wikipedia.org/wiki/Sexagesimalsystem

Rechenmeister Mittring richtet sein KalenderimKopf-Rechensystem auf die 
Zahl 12 aus, ist also nicht weit davon weg.

Chris F. schrieb:

> Und was ist leichter zu lernen

Als C? Pascal und Basic natürlich. Denn genau dafür wurden sie ja 
geschaffen.

> und schneller zu schreiben?

Mit modernen IDEs? Pascal und Delphi natürlich. Dank der höheren 
Redundanz im Code kann eine Codevervollständigung á la MS "IntelliSense" 
hier viel effizienter und treffender erahnen, was der Benutzer als 
nächstes wohl schreiben will.

Sehr schön kann man das im direkten Vergleich in VS zwischen C# und VB 
sehen. Beides erzeugt ja de facto den gleichen (CIL-)Zwischencode und 
greift auch auf die gleichen Bibliotheken zurück.
Aber C# ist recht "C'isch" und kommt deshalb statistisch mit wesentlich 
weniger Zeichen im Quelltext aus als VB. Geht das Schreiben von Code 
dadurch schneller? DEFINITIV NEIN. Und das gleich aus mehreren Gründen. 
Zum einen kommt, wie gesagt, Intellisense (genauer: der tokenizer) hier 
auf Grund der geringeren Quelltext-Redundanz viel öfter "aus dem Tritt" 
als in VB. Das führt u.a. auch dazu, dass beim kleinsten Tippfehler 
gleich gerne mal tausende Zeilen eingefalteten Codes einfach mal 
ausgefaltet werden, was ein "very annoying behaviour" ist...

Zum anderen werden in C# Sachen als Kommentar nötig, die in VB bereits 
durch den Quelltext selbst dokumentiert werden. Ich denken da z.B. an 
die typische Wüste schließender curly braces zum Ende von wasauchimmer 
hin, wo der C'ler (und auch der C#'ler) dann gerne mal Kommentare 
einstreut á la
"       } //end if". Das ist in VB nicht nötig, da steht dann nämlich 
einfach schon "end if", "next", "end structure", "end class", "end 
namespace" usw....

> kannst Du Dir in sehr vielen aktuellen Versionen von heute genutzten
> Hochsprachen die Operatoren so definieren wie Du willst, auch in
> ausgeschriebenem Englisch.

Ja, gerade dieses Feature (operator overloading) bietet sich an, um 
jeden Quelltext endültig zu "Klartext-Verschlüsseln". Man sollte dieses 
Feature eher nur sparsam einsetzen. Dazu gehört ganz sicher nicht, 
Standard-Operatoren für Standard-Datentypen (der jeweiligen Sprache) zu 
ersetzen. Das ist allerdings ganz offensichtlich spezielles Hobby 
einiger C#- und C++-Wichser geworden...

BTW: Natürlich kann man auch in VB.net Operatoren überladen...

> Eigentlich waren die Gründe für C genau das Gegenteil. Es ist auf jeden
> Fall besser und angenehmer in C als in Assembler zu arbeiten.

Tja, das war tatsächlich der Plan, insofern gebe ich dir Recht. Er ist 
nur leider ziemlich kläglich gescheitert...

De facto kann man in C nicht kompetent programmieren, ohne über fast so 
weitgehende Kenntnisse über das Zielsystem zu verfügen, wie sie auch für 
Assemblerprogrammierung nötig sind. Weil das so ist, gibt es auch so 
viele unsäglich schlechte C-Programme und so ungeheuer viele 
Sicherheitslücken in C-Programmen...

Also: Wenn Hochsprache, dann doch besser sowas wie C#, Java oder VB.net. 
Erst auf diesem Level kann man tatsächlich oft (aber leider immer noch 
nicht grundsätzlich) auf spezielle Kenntnisse über die Zielmaschine 
verzichten und viele Standardfehler (=potentielle Sicherheitslücken), 
die aus der Unkenntnis dieser Details resultieren, werden standardmäßig 
von der Laufzeitumgebung abgefangen.