3. (Für mich) unverständliches Ergebnis bei binärem Operator ~

(Für mich) unverständliches Ergebnis bei binärem Operator ~

  • N

    Warum das? Ham wir net alle in der Schule gelernt, das:

    000 = 0
001 = 1
010 = 2
011 = 3
100 = 4
101 = 5
111 = 6

    ?

    0
  • V

    Das haben wir bei positiven Zahlen gelernt, aber nicht bei negativen 😉

    mfg
    v R

    0
  • M

    Hi,

    ness:
    diese Schreibweise bezieht sich wie gesagt nur auf unsignierte Datentypen. Diese zeichnen sich dadurch aus, dass das 1. Bit ein ganz normales Bit für die Zahl ist.
    Bei signierten Datentypen bedeutet das erste Bit aber wie gesagt das Vorzeichen.
    Allerdings ist:

    10 nicht -0, sondern -1. Da -0 = +0 hat man durch die invertierte Schreibweise des Restes (also alles bis auf das Vorzeichenbit) mehr Zahlenmöglichkeiten.

    MfG Eisflamme

    0
  • P

    Für die binärkodierung negativer Zahlen gibnt es zwei gängige Verfahren:

    Einerkopmplement: -a ≡ ~a
    Zweierkomplement: -a ≡ ~a+1
    Bei beiden gibt das höchstwertige Bit das Vorzeichen an.

    Beide haben den Vorteil, daß bei arithmetischen Operationen nicht zwischen Vorzeichenlos und Vorzeichenbehalftet unterschieden wird. Im einerkomplement gibt es aber zwei Darstellungen für 0, was Vergleiche relativ kompliziert macht

    Der C++ - Standard macht keine Garantien zur binären Darstellung negativer Zahlen.

    0
  • C
    Mod

    letzlich wird jeder compiler die standard datentypen so codieren, wie der prozessor sie normalerweise verwendet - also für x86 prozessoren immer die zweierkomplementdarstellung.

    0
  • P

    ...genau deswegen macht der Standard ja auch keine Vorschriften.

    0
  • N

    virtuell Realisticer schrieb:

    Das haben wir bei positiven Zahlen gelernt, aber nicht bei negativen 😉

    mfg
    v R

    Ja, aber wenn ich mit -1 multipliziere ist die Zahl doch wieder positiv? Ach nein, das hängt sicher davon ab, ob die zahl negativ sein kann...
    Dann frag ich mal in die Runde: Wie kann ich mittels den binären Operatoren die Obergrenze eines vorzeichen-behafteten types ausgeben? Und wo genau ist das "Vorzeichen-bit"? Ganz "links" oder ganz "rechts"? (Auf einer x68-Architektur)

    0
  • P

    Es ist das höchstwertige Bit, üblicherweise ganz links dargestellt (aber das ist nur Konvention. Ich fände Spiralmuster zwar hübscher, aber die sind halt nicht so praktisch)

    Da du eigentlich überhaupt nichts über die Darstellung weißt, wird es schwierig. Vielleicht

    int i=0; while(i+1>0) ++i;

    . aber das dauert etwas.

    Wenn du die Kodierung kennst, geht alles natürlich ein bißchen schneller.

    0
  • N

    Ja, sowas hab ich auch schon, aber haste das schinmal mit long long probiert? 😃
    Woher könnte ich denn Informationen über die Darstellung beziehen? Prinzipiell müsste das Ergebnis binär gesehen ja ziemlich regelmäßig sein, bei unsigned eben 111111111111...

    0
  • V

    Ja, aber wenn ich mit -1 multipliziere ist die Zahl doch wieder positiv? Ach nein, das hängt sicher davon ab, ob die zahl negativ sein kann...

    Du hattest a = 0. ~a ist dann -1 und das *-1 ist 1. Was ist daran ungewoehnlich?

    Ja, sowas hab ich auch schon, aber haste das schinmal mit long long probiert? 😃
    Woher könnte ich denn Informationen über die Darstellung beziehen? Prinzipiell müsste das Ergebnis binär gesehen ja ziemlich regelmäßig sein, bei unsigned eben 111111111111...

    Wieso sollte es regelmaessig sein? In diesem Falle wuerde es eine +0 und eine -0
    geben. Und genau damit das nicht passiert, sind 32 einser-Bits -1 und nicht die
    kleinste negativ darstellbare Zahl. Damit du diese Zahl bekommst, kannst du das
    vorderste Bit auf 1 setzen:

    int a = 0;
    a = (1<<31);

    mfg
    v R

    0
  • N

    OK, und woher bekomme ich ne positive Zahl? Und warum ist long long a=(1<<63) 0?

    0
  • P

    Weil long long auf deinem compiler auch keine 4 bit hat?

    0
  • N

    long long == __int64 == 64bit? So stehts in der msdn?

    0
  • C
    Mod

    ich tip mal darauf,d ass der ausdruck (1<<63) zunächst als long ausgewertet und dann nach long long gecastet wird. wenn das so ist, müsste

    long long a = (long long)1 << 63;

    eigentlich funktionieren.

    0
  • P

    oder so 😉 stimmt.

    0
  • N

    Danke, jetzt gehts... Aber warum glaubst du, 1 wird als long gewertet? Ich würde eher auf int tippen...
    Aber dann bitte:

    long long a=(static_cast<long long>(1)<<63);

    Hast du nicht mehr effektiv c++ gelesen?
    Das Ergebnis ist übrigens 4611686018427387904...
    /edit:Kann net sein, wenn ich um 64 verschiebe komt -9...

    0
  • V

    ness schrieb:

    Danke, jetzt gehts... Aber warum glaubst du, 1 wird als long gewertet? Ich würde eher auf int tippen...

    Das ist egal, weil sizeof(int) == sizeof(long) auf 32-Bitsystemen

    Aber dann bitte:

    long long a=(static_cast<long long>(1)<<63);

    Hast du nicht mehr effektiv c++ gelesen?
    Das Ergebnis ist übrigens 4611686018427387904...
    /edit:Kann net sein, wenn ich um 64 verschiebe komt -9...

    Wenn du um 64-Bit shiftest, dann shiftest du ueber die Grenze deiner 64-Bit
    Variablen hinaus. Denn auch hier gillt: zaehlen von Bit 0 bis Bit 63. Ich
    wuerde sagen, dass dann das Ergebnis implementierungspezifisch ist. Hab jetzt
    grad keine Lust nachzuschauen, ob der Draft sich darueber auslaesst 🙂

    mfg
    v R

    0
Anmelden zum Antworten