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 ? :)
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
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)
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 :)
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!
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 ;-)
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....
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...
:
Bearbeitet durch User
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.
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.
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....
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 | #include <stdio.h> |
2 | #include <stdint.h> |
3 | |
4 | void calc16 () |
5 | {
|
6 | int16_t a16 = 0xFFFF; |
7 | int16_t b16 = 0x8000; |
8 | int16_t c16 = 1; |
9 | int16_t d16 = a16 - b16 + c16; |
10 | |
11 | printf ("0x%hx\n", d16); |
12 | }
|
13 | |
14 | void calc32 () |
15 | {
|
16 | int32_t a32 = 0xFFFF; |
17 | int32_t b32 = 0x8000; |
18 | int32_t c32 = 1; |
19 | int32_t d32 = a32 - b32 + c32; |
20 | |
21 | printf ("0x%x\n", d32); |
22 | }
|
23 | |
24 | int main () |
25 | {
|
26 | calc16 (); |
27 | calc32 (); |
28 | return 0; |
29 | }
|
1 | $ cc -O -Wall signed.c -o signed && ./signed |
2 | 0x8000 |
3 | 0x8000 |
:
Bearbeitet durch Moderator
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 ;-)
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.