| und & Operator

volkard

Das verrate ich erst, wenn Du sagst, was 4711+0815 ist.

juniorcrew

2505 + 2069 = 4574

juniorcrew schrieb:

Muss ich bei & | die Werte immer erst in binär umwandeln?

kommt auf deine kopfrechenkünste an, ich kann's z.b. am besten mit hexzahlen. ich kenne aber einen, der kann sogar dezimalzahlen im kopf binär verknüpfen, aber das ist eher selten (der typ spielt auch schach ohne brett und figuren). umwandeln in binär hat den vorteil, dass du's untereinander schreiben kannst und dann musste nur noch spaltenweise durchgehen.

juniorcrew schrieb:

a) 0x10 & 0x01 = (b)10000 & (b)1
Aber die müssen doch die gleiche Länge haben. Fülle ich die (b)1 vorne einfach mit NUllen auf? (b)10000 & (b)00001

ja, so geht das.

volkard schrieb:

Das verrate ich erst, wenn Du sagst, was 4711+0815 ist.

^^ 8 als oktalziffer? oder ist das base9 *fg*

volkard

;fricky schrieb:

volkard schrieb:

Das verrate ich erst, wenn Du sagst, was 4711+0815 ist.

^^ 8 als oktalziffer? oder ist das base9 *fg*

Genau. Bei 0815 streikt der Compiler. Wegen der 0 am Anfang fängt er an, eine Oktalzahl zu lesen und bei der 8 haut's ihn dann aus den Socken.

volkard

juniorcrew schrieb:

a) 0x10 & 0x01 = (b)10000 & (b)1
Aber die müssen doch die gleiche Länge haben. Fülle ich die (b)1 vorne einfach mit NUllen auf? (b)10000 & (b)00001

10000
00001
-----
00000 -> 0

Supi. Völlig richtig.
Ja, das Auffüllen war nötig, damit man das so untereinanderschreiben kann.

Übrigens kann auch Fricky mindestens folgende Aufgaben im Kopf lösen, er gibts nur nicht zu:
(Ergebnisse immer hex angeben, da isses am leichtesten)

0x05 & 0x60
0x05 | 0x60
0x05 ^ 0x60
0xff & 0xbe
0xff | 0xbe
0xfa & 0xef
0x42 & 0x84
0x10 & 0x01
0x10 | 0x01

volkard schrieb:

Übrigens kann auch Fricky mindestens folgende Aufgaben im Kopf lösen, er gibts nur nicht zu...

das ist nicht schwer, ich 'sehe' hexzahlen als bitmuster (pro ziffer vier bits), ist bloss übungssache, eigentlich nix besonderes.
aber hier mal was für dich, oh grosser rechenmeister: 102d + b79 = 1ba3
^^welche basis hab' ich verwendet? tip: hex ist es nicht. *fg*

TyRoXx

;fricky schrieb:

102d + b79 = 1ba3
^^welche basis hab' ich verwendet? tip: hex ist es nicht. *fg*

Gar keine? Wenn d = 13 ist, kann die Endziffer des Ergebnisses nicht 3 sein. (Denkfehler bei mir?)

juniorcrew

Gut dann haben wir doch schoneinmal eine Sache abgehackt

Aber dieses >> oder <<, wie geht das damit?

c) 0x01 << 4 = (b)1 << 4 = (b)10000 = 0x10

h) 0x01 >> 4 = (b)1 >> 4 = (b)00001 = ??? Wie soll das denn gehen?

TyRoXx

juniorcrew schrieb:

h) 0x01 >> 4 = (b)1 >> 4 = (b)00001 = ??? Wie soll das denn gehen?

Das wird einfach 0.

TyRoXx schrieb:

;fricky schrieb:

102d + b79 = 1ba3
^^welche basis hab' ich verwendet? tip: hex ist es nicht. *fg*

Gar keine? Wenn d = 13 ist, kann die Endziffer des Ergebnisses nicht 3 sein. (Denkfehler bei mir?)

ja und nein, d=13 ist richtig, d.h. die basis ist mindestens 14. die endziffer des ergebnisses ist natürlich davon abhängig, wann es 'nen übertrag gibt.

juniorcrew schrieb:

c) 0x01 << 4 = (b)1 << 4 = (b)10000 = 0x10

vier mal shiften:

0x01 << 1 = 0x02
0x02 << 1 = 0x04
0x04 << 1 = 0x08
0x08 << 1 = 0x10

^^ passt also, würde ich mal sagen.

juniorcrew

Ja aber wieso wid das denn einfach 0? Das WARUM juckt mich ja

juniorcrew schrieb:

Ja aber wieso wid das denn einfach 0? Das WARUM juckt mich ja

rechts von bit 0 ist halt nix mehr. in assembler würde die 1 ins carry-flag wandern (hallo pointercrash *fg*), aber in C verschwindet sie einfach:

int a = 0x01;   // 1
int b = a >> 1; // 0
int c = a >> 2; // 0
int d = a >> 3; // 0
... // egal wie oft du auch rechts-shiftest, weg ist weg

TyRoXx

;fricky schrieb:

TyRoXx schrieb:

;fricky schrieb:

102d + b79 = 1ba3
^^welche basis hab' ich verwendet? tip: hex ist es nicht. *fg*

Gar keine? Wenn d = 13 ist, kann die Endziffer des Ergebnisses nicht 3 sein. (Denkfehler bei mir?)

ja und nein, d=13 ist richtig, d.h. die basis ist mindestens 14. die endziffer des ergebnisses ist natürlich davon abhängig, wann es 'nen übertrag gibt.

Ach natürlich. Dann ist die Basis 19.

(1 >> 4) ist 0, weil das Bit rechts rausgeschoben wird.

TyRoXx schrieb:

Ach natürlich. Dann ist die Basis 19.

^^ we have a winner!

juniorcrew schrieb:

Ja aber wieso wid das denn einfach 0? Das WARUM juckt mich ja

Was ist 1/2? Und was passiert wenn du das Ergebnis einem int zuweisen würdest?

Einfach ausgedrückt (es gibt da Sonderfälle die wir später betrachten können) ist

x = a >> b

äquivalent zu

x = a / 2[h]b[/h]

Ebenso ist auch

x = a << b

äquivalent zu

x = a * 2[h]b[/h]

volkard

@Fricky: Wir sind einer Meinung, daß die Fälle klar waren, weil "ich 'sehe' hexzahlen als bitmuster (pro ziffer vier bits)". Du hast doch sofort gesehen, daß die Aufgaben genau auf diese Deine Fähigkeit abgesteckt waren. Ich habe ja auch gesagt, daß Du die alle im Kopf kannst. Damit habe ich Deine Aussage über den Mann, der hex im Kopf verknüpfen kann, abgeschwächt. Vorwiegend darum ging es mir. Viele der weiteren vorstellbaren nichttrivialen Aufgaben kannst Du auch und die Bitmuster 0-A wirste auch im Kopf haben, damit geht schon einiges. Und der ganze Rest geht auch im Kopf, dauert nur länger. Und das ist keine Abwertung. Damit bist Du weit vorne. Leider braucht keiner mehr diese Fähigkeit, aber das ist eine andere Geschichte.

Tim schrieb:

Was ist 1/2? Und was passiert wenn du das Ergebnis einem int zuweisen würdest?

das müßte das gleiche sein wie

float x = floor(1/2);

lg lolo

noobLolo schrieb:

Tim schrieb:

Was ist 1/2? Und was passiert wenn du das Ergebnis einem int zuweisen würdest?

das müßte das gleiche sein wie
float x = floor(1/2);

^^ lustiger thread, so kommt man von bitgefummel zu fliesskommazeugs *fg*

juniorcrew

Alles habe ich verstanden Dankeschön!

Gruß juniorcrew

| und &amp; Operator

| und & Operator