Gemischte Datentypen

[Georg M. (g_m)]

Spricht etwas dagegen, das Ergebnis einer arithmetischen Operation in 
die Variable eines anderen Datentyps zu speichern?

Z.B. Subtraktion:
4 Byte - 4 Byte ==> 2 Byte

uint32_t minuend;
uint32_t subtrahend;
uint16_t difference;

Z.B.:
67108864 - 67107840 = 1024

[Rufus Τ. F. (rufus)]

Ja, nämlich dann, wenn das Ergebnis nicht passt.

 Z.B.:
67108864 - 1 = 67108863

[NurEinGast (Gast)]

67108864 - 1 = 67108863
Passt nicht in die uint_16

[NurEinGast (Gast)]

... war zu langsam ...

[Sebastian K. (sek)]

Rufus Τ. F. schrieb:
> Ja, nämlich dann, wenn das Ergebnis nicht passt.
>
>  Z.B.:
> 67108864 - 1 = 67108863

Oder anders ausgedrückt:

Ich würde mich sehr darüber ärgern, wenn ich 67108864€ auf meinem Konto 
hätte, 1€ abhebe und anschließend nur noch 65535€ drauf habe, weil der 
Programmierer des Bankings so dämlich war die 32-Bit auf 16-Bit zu 
kürzen.

[Georg M. (g_m)]

Rufus Τ. F. schrieb:
> Ja, nämlich dann, wenn das Ergebnis nicht passt.

Hoffentlich wird der Chip nicht zerstört?


Aber falls das Resultat die reservierte Bitbreite nicht überschreitet, 
ist dann alles fehlerfrei?

[W.S. (Gast)]

Georg M. schrieb:
> Aber falls das Resultat die reservierte Bitbreite nicht überschreitet,
> ist dann alles fehlerfrei?

Und wie willst du das prüfen?

Das ganze ist ein Abschneiden relevanter Bits und das sollte man nur 
dann wagen, wenn man mit allerletzter Sicherheit ganz genau weiß, daß da 
NIEMALS was passieren könnte. Sonst hast du nämlich ne Hausnummer 
anstelle einer Differenz und kannst das nichtmal merken.

Was mir da als Beispiel einfällt, sind die (zumindest mir) noch immer 
unverständlichen Verhältnisse bei einem CIC-Dezimator nach Hogenauer: 
zuerst eine oder mehrere Additionsstufen (die überlaufen können und 
dürfen) und dann ebensoviele Differenzierer. Aber OK, zumindest bei 
Xilinx wachsen dafür die Datenbreiten ins Erhebliche an, mehr als 80 Bit 
für die Register mittendrin scheinen keine Seltenheit zu sein.

Und du willst Bits abschneiden...

W.S.

[A. S. (Gast)]

Georg M. schrieb:
> Aber falls das Resultat die reservierte Bitbreite nicht überschreitet,
> ist dann alles fehlerfrei?

Was ist dann Deine Frage? Und wenn ja, für welche Programmiersprache?

Wenn Dein Ergebnis 0..32767 ist, dann reicht eine 2-Byte Variable (*) 
aus.

Wenn Dein Ergebnis -32768..65535 ist, dann solltes Du Dir frei nach 
Hamlet schon um signed oder nicht seigned gedanken machen.





*)bei aktuellen CPUs mit 2er-Komplement und 8Bit pro Byte etc.

[S. R. (svenska)]

Georg M. schrieb:
> Spricht etwas dagegen, das Ergebnis einer arithmetischen Operation in
> die Variable eines anderen Datentyps zu speichern?

Für Division (32 Bit geteilt durch 16 Bit ergibt 16 Bit) ginge das, für 
alle anderen klassischen Operationen (Addition, Subtraktion, 
Multiplikation, beliebige Bitoperationen) nicht.

[Karl M. (Gast)]

S. R. schrieb:
> Georg M. schrieb:
>
> Für Division (32 Bit geteilt durch 16 Bit ergibt 16 Bit) ginge das, für
> alle anderen klassischen Operationen (Addition, Subtraktion,
> Multiplikation, beliebige Bitoperationen) nicht.

Nein stimmt nicht eine 32 Bit Zahl/ 1 ist immer noch eine 32 Bit Zahl.

[Sebastian S. (amateur)]

Wenn Du genau weist in welchem Zahlenbereich das zu speichernde Ergebnis 
liegt, kannst Du die Datentypen kunterbunt mischen.
Da aber vieles im "Hintergrund" passiert, ist so etwas nicht zu 
empfehlen. Vor allem, wenn Du Zahlen mit und ohne Vorzeichen mischt. 128 
wird dann schnell zu -1.

Weißt Du aber genau, welche Ziffern auftreten können, spricht nichts 
dagegen (uint8_t) = (uint32_t) + (uint32_t) durchzuführen.
Sollte aber Deine Annahme nicht zutreffen, gibt es keine Fehlermeldung 
im Falle eines Falles. Also dann ist halt 120 + 136 = 0(!)

[c-hater (Gast)]

Georg M. schrieb:

> Spricht etwas dagegen, das Ergebnis einer arithmetischen Operation in
> die Variable eines anderen Datentyps zu speichern?

Nein. Jedenfalls nicht, solange sie sicher da rein passen wird...

Allerdings ist die Zahl der Probleme, bei denen das gegeben ist, sicher 
sehr klein im Verhältnis zur Gesamtzahl aller denkbaren Probleme...

Das sollte dich aber nicht ernsthaft entmutigen. Denn selbst, wenn man 
immer Hochsprachen-treudoof beim gewählten Datentyp bleibt, ist dieses 
Verhältnis oft nicht wirklich besser...

[S. R. (svenska)]

Karl M. schrieb:
> Nein stimmt nicht eine 32 Bit Zahl/ 1 ist immer noch eine 32 Bit Zahl.

Hast du natürlich recht, Asche auf mein Haupt.