| und & Operator
-
juniorcrew schrieb:
Super klasse, ist ja einfach und wie sieht es mit folgendem aus:
c) 0x01 << 4
h) 0x01 >> 4aber zuerst dein versuch. na, was tun >> und << wohl?
btw, frag sowas bitte nie im C++ forum *fg*
-
Muss ich bei & | die Werte immer erst in binär umwandeln?
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 -> 0So ist das richtig oder? Jetzt solltes drin sein, hatte dann vorhin noch einen Denkfhler drin.
-
Das verrate ich erst, wenn Du sagst, was 4711+0815 ist.
-
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)00001ja, so geht das.
volkard schrieb:
Das verrate ich erst, wenn Du sagst, was 4711+0815 ist.
^^ 8 als oktalziffer? oder ist das base9 *fg*
-
;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.
-
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)0000110000
00001
-----
00000 -> 0Supi. 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*
-
;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?)
-
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?
-
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.
-
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
-
;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]
-
@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*