Hallo alle zusammen kann mir jemand erklären wie die hier auf das Ergebnis kommen ? FFFh -8000h +1 = 8000 h Wie haben die das gerechnet ? FFF ist ja 4095 . Ich verstehe nicht wie die auf das Ergebnis kommen ? :)
Fehlt da ein F? (FFFh -> FFFFh)
oh ja ein F fehlt :) Aber verstehe trotzdem nicht wie die auf das Ergebnis kommen ? Macht mich gerade verrückt auch wenn das einfach sein soll
32Bit Zahlen -> es kommt zum Overflow?
Kannst du es mir bitte erklären ? :)
Volker S. schrieb: > Fehlt da ein F? (FFFh -> FFFFh) Richtig. Damit kommt bei meinem Taschenrechner auch genau das heraus: FFFFh - 8000h + 1 = 8000h FFFFH - 8000h = 7FFFh (65535 - 32768 = 32767) 7FFFH + 1 = 8000h (32767 + 1 = 32768)
Gast
#5948814
Wende einfach die Grundrechenarten mit Basis 16 (=HEX) an.
Volker S. schrieb: > 32Bit Zahlen -> es kommt zum Overflow? Nein. Siehe meine Rechnung oben.
Malvia R. schrieb: > Aber verstehe trotzdem nicht wie die auf das Ergebnis kommen ? Das Kommutativgesetz macht es einfach, dies im Kopf auszurechnen: 0xFFFF + 0x0001 = 0x10000 0x10000 - 0x8000 = 0x8000, denn 2 mal 0x8000 sind 0x10000. oder noch einfacher: 0x8 + 0x8 = 0x10, also muss 0x8000 + 0x8000 = 0x10000 sein. Du kannst aber auch alles vorher in Dezimal umrechnen. ;-)
Weisst du wie man das im casio eingeben kann und in einem Schritt vielleicht rechnen kann ? Ich weiss net wie ich es mit Taschenrechner ausrechnen kann :)
Gast
#5948824
Malvia R. schrieb: > Weisst du wie man das im casio eingeben kann und in einem Schritt > vielleicht rechnen kann ? > Ich weiss net wie ich es mit Taschenrechner ausrechnen kann :) Kann Dein Rechner mit HEX-Zahlen rechnen und kannst Du eine Bedienungsanleitung lesen?
FFFFh = -1 8000h = -32.768d ist die negativste Zahl die bei 32Bit möglich ist -1 -(−32.768d) +1 = 32.768d (+32.768d) gibt es bei 32 Bit signed nicht. Es kommt zum Überlauf und das Ergebnis ist falsch!
Mit taschenrechner bekomme ich es jetzt zumindest hin :)
Malvia R. schrieb: > Weisst du wie man das im casio eingeben kann und in einem Schritt > vielleicht rechnen kann ? Wenn du HEX rechnen willst, muss der Rechner das natürlich können. Ich habe das auf einem casio fx-107 gerechnet: Umstellung auf HEX: Tasten "MODE" und "3" dann ganz normal rechnen: Tasten "FFFF-8000+1=" ergibt auf der Anzeige "8000".
Steht bei der Aufgabe eigentlich etwas von der Bitbreite der Zahlen dabei? Also wenn 32 Bit, dann ist das Ergebnis eigentlich falsch, wegen Überlauf. Wenn unbegrenzt (mehr als 32), dann ist es richtig und die Aufgabe zu einfach ;-)
Gast
#5948842
Volker S. schrieb: > 8000h = -32.768d ist die negativste Zahl die bei 32Bit möglich ist Nö, ist sie nicht. Das ist sie nur bei 16bit. Malvia R. schrieb: > Ich weiss net wie ich es mit Taschenrechner ausrechnen kann :) Wenn du Windows10 verwendest, kannst du den "Bord-"Rechner in den Programmierermodus versetzen und dir dann deine Berechnungen auf dem Bildschirm ansehen.
STK500-Beistzer schrieb: > Nö, ist sie nicht. > Das ist sie nur bei 16bit. AAAhhhhhhrrrgggg ;-) Ersetzte überall 32 durch 16....
Gast
#5948863
Bei Win7 tuts der Rechner in der Ansicht "Programmierer"
Dietrich L. schrieb: > Volker S. schrieb: >> 32Bit Zahlen -> es kommt zum Overflow? > > Nein. Siehe meine Rechnung oben. Ja das mit den 32 Bit war wohl ein bisschen schnell :-( (4 Nibble sind ja nur 2 Byte also 16 Bit. Die Werte und ihre Darstellung deuteten (für mich) einfach zu offensichtlich auf einen Überlauf hin. Da wurde der Rest zur Nebensache ;-) <edit> Dass so was triviales wie 999 -500 +1 = 500 gemeint sein könnte, schien mir eher unwahrscheinlich...
Gast
#5949005
Man ordne den letzten (drei) Stellen eines mehrstelligen Binärzählers: Stellen: ... 100 101 110 111 000 001 010 011 ... Zahlenstrahl: ...-4 -3 -2 -1 0 1 2 3 ... der Folge des Zahlenstrahls zu Wenn Du diese Zuordnung der Zählweise eine Binärzählers zum Zahlenstrahl betrachtest, ist folgende Betrachtung möglich: Das höchstwertige Bit ist das Vorzeichenbit, Zahlen mit 1 beginnend sind negative Zahlen.(Zuordnungsart nennt man signed.) 8000h ist also eine negative Zahl, ffffh ebenfalls. Beim Addieren oder Subtrahieren über die 0 hinweg passieren dann seltsame Dinge, Die Einzelschritte sind ja oben von verschiednen Leuten angezeigt. Wenn man übersieht, dass das höchstwertige Bit ein Vorzeichenbit ist,und nicht Teil der Zahl kommt da anscheinend solch Unsinniges heraus.
Peter R. schrieb: > Wenn man übersieht, dass das höchstwertige Bit ein Vorzeichenbit ist... Vielleicht denken wir aber auch nur zu kompliziert. Man müsste die komplette Aufgabenstellung kennen.
Gast
#5949018
Man ordne den letzten (drei) Stellen eines mehrstelligen Binärzählers: Stellen: ... 100 101 110 111 000 001 010 011 ... Zahlenstrahl: ...-4 -3 -2 -1 0 1 2 3 ... der Folge des Zahlenstrahls zu Wenn Du diese Zuordnung der Zählweise eine Binärzählers zum Zahlenstrahl betrachtest, ist folgende Betrachtung möglich: Das höchstwertige Bit ist das Vorzeichenbit, Zahlen mit 1 beginnend sind negative Zahlen.(Zuordnungsart nennt man signed.) 8000h ist also eine negative Zahl, ffffh ebenfalls. Beim Addieren oder Subtrahieren über die 0 hinweg passieren dann seltsame Dinge, Die Einzelschritte sind ja oben von verschiednen Leuten angezeigt. Wenn man übersieht, dass das höchstwertige Bit ein Vorzeichenbit ist,und nicht Teil der Zahl kommt da anscheinend solch Unsinniges heraus.
Peter R. schrieb: > Das höchstwertige Bit ist das Vorzeichenbit, Nein, ist es nicht. Zumindest nicht beim Zweier-Komplement, das du hier beschreibst. Sonst könnte man durch setzten oder löschen des Bit das Vorzeichen ändern und den Betrag beibehalten. > Zahlen mit 1 beginnend sind > negative Zahlen.(Zuordnungsart nennt man signed.) In diesem Fall ja. Aber: Nicht jede Binär oder Hexdarstellung ist Zweierkomplement oder an irgendeine Bitbreite gebunden.. Man kann auch das Vorzeichen als - davor schreiben.
Gast
#5949036
FFFFh ist also eine -1 , 8000h = 1000...000 ist eine fünfzehnstellige mit -Zeichen Das Subtrahieren von -0 ist eine Addition von 0 . Es bleibt also bei FFFFh im ersten Schritt: eine 1 mit Einsen. Wenn man da 1 addiert (15 Nullen und ein 1 am Ende) kommt halt FFFF heraus, mit einem carry-bit. Die oberste Stelle ist ja keine Stelle der Zahl sondern ihr Vorzeichen Wenn man dann die Zahlen als binär betrachtet und nicht als binär signed,kommt dann halt Unsinn heraus FFFF ist -32... und nicht 65....
Gast
#5949048
Peter R. schrieb: > FFFFh ist also eine -1 , 8000h = 1000...000 ist eine fünfzehnstellige > mit -Zeichen Nü. 65535 dezimal. Peter R. schrieb: > Wenn man dann die Zahlen als binär betrachtet und nicht als binär > signed,kommt dann halt Unsinn heraus FFFF ist -32... und nicht 65.... Es ist eine Darstellungsinterpretation. Kein Computer (µC, PC o.dergl.) braucht ein (negatives) Vorzeichen. Das wird dadurch "überflüssig", dass die Zahlbereiche begrenzt sind, und es ggf. zu einem Überlauf kommt. Dass es eine Rechenregel für "-" gibt, ist was anderes. Es geht ums Vorzeichen!
Volker S. schrieb: > FFFFh = -1 Nur bei 16-Bit vorzeichenbehafteten Zahlen. Davon steht nix im Ausgangsposting.
Peter R. schrieb: > Die oberste Stelle ist ja keine Stelle der > Zahl sondern ihr Vorzeichen Das wäre beim Einerkomplement so. Dann hast du aber zwei Werte für 0: +0 und -0 Zudem wird das rechnen schwierig. Darum nimmt man gerne das Zweierkomplement.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
1 | |
2 | |
3 | |
Frank M. schrieb: > Volker S. schrieb: >> FFFFh = -1 > > Nur bei 16-Bit vorzeichenbehafteten Zahlen. Davon steht nix im > Ausgangsposting. Im Ausgangspost steht ja so gut wie gar nix Das verleitet leider manchmal zum rein interpretieren. (à la 999 -500 +1 = 500 wäre ja viel zu einfach ;-)
Volker S. schrieb: > (à la 999 -500 +1 = 500 wäre ja viel zu einfach ;-) Ich habe die "Aufgabe" aber genau so einfach verstanden.
Frank M. schrieb: > Ich habe die "Aufgabe" aber genau so einfach verstanden. Ja, das ist eben so und ohne Rückmeldung vom OP oder gar dem Aufgabensteller können wir nie ganz sicher sein um was es da ging. Also ich würde niiieeemals so eine Aufgabe mit diesen Werten stellen... Meine kleine Verwechslung mit den 16/32 Bit war natürlich blöd, aber diese Posts haben ja sicherheitshalber schon einige "nicht lesenswert" bekommen und man kann guter Hoffnung sein, dass dadurch nicht doch noch einer in die Irre geleitet wird. Na ja, Gäste haben halt Pech gehabt ;-)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.