Verständnisfrage zu shift Operatoren in vorzeichenbehafteten Rechnungen in c (Festkommarechnung)

[Thorsten S. (whitejack)]

Hallo,

ich habe folgende Beispielformel zusammengefrickelt um meine Frage zu 
verdeutlichen...
int8_t Beispielrechnung (....)
{
    //Formel mul*0.3-50+r1

    uint8_t mul=133; //0-255
    uint16_t r1=30;  //0-99
    uint16_t c1=(uint16_t)(0.3*(1<<9));

    return 
(int8_t)(((((int16_t)(c1*(uint16_t)mul))-(50*1<<9))>>9)+(int16_t)r1);
}
Diese Geschichte rechnet richtig. Bitte vernachlässigt den Sinn und 
teilweise auch die Wahl der Zahlen. Ich möchte folgende Frage 
hervorheben:

Mit dem ersten Typecast (int16_t) an der Multiplikation möchte ich 
sicherstellen das die weitere Rechnung (Subtraktion) auf basis int16_t 
stattfindet, das geht auch.

Nun die Frage:
An der Stelle >>9 schifte ich eine vorzeichenbehaftete int16_t um 9 Bit 
nach rechts, warum geht das mit dem Vorzeichen nicht in die Grütze?

Müsste ich nicht viel eher schreiben /(int16_t)(1<<9)  ?

Gruß,
Thorsten

[(prx) A. K. (prx)]

Thorsten S. schrieb:

> An der Stelle >>9 schifte ich eine vorzeichenbehaftete int16_t um 9 Bit
> nach rechts, warum geht das mit dem Vorzeichen nicht in die Grütze?

Ohne deinen Klammernsalat aufgedröselt zu haben: >> bewahrt das 
Vorzeichen, mindestens üblicherweise. Es muss wohl vor Jahrzehnten 
Maschinen gegeben haben, die damit Probleme hatten, daher ist (war?) C 
laxer definiert, aber das ist Vergangenheit.

Wobei >> und / nur dann äquivalent sind, wenn kein negatives Vorzeichen 
mitmischt. Bei negativem Zähler kommen verschiedene Ergebnisse raus.

[Klaus W. (mfgkw)]

Bei vorzeichenbehafteten Zahlen wird beim Rechtshiften von links
mit dem bisherigen Vorzeichen aufgefüllt, also mit 1, wenn die Zahl
negativ ist.
Negativ bleibt dabei also negativ.

[Klaus W. (mfgkw)]

A. K. schrieb:
> Wobei >> und / nur dann äquivalent sind, wenn kein negatives Vorzeichen
> mitmischt. Bei negativem Zähler kommen verschiedene Ergebnisse raus.

Ja, aber nur in der niedrigstwertigen Stelle (Rundung nach unten bzw. zu 
0 hin)

[Yalu X. (yalu) (Moderator)]

A. K. schrieb:
> Es muss wohl vor Jahrzehnten Maschinen gegeben haben, die damit
> Probleme hatten, daher ist (war?) C laxer definiert, aber das ist
> Vergangenheit.

Es ist an der Stelle immer noch "lax" definiert:

  "The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1
  has an unsigned type or if E1 has a signed type and a nonnegative
  value, the value of the result is the integral part of the quotient of
  E1 / 2E2 . If E1 has a signed type and a negative value, the resulting
  value is implementation-defined." (Quelle:  ISO/IEC 9899:TC3)

Hat der Prozessor, wie fast jeder, einen ASR-Befehl (arithmetic shift
right), werden beim Rechtsshift von vorzeichenbehafteten Zahlen die frei
werdenden Bits üblicherweise mit dem höchstwertigen Bit von E1
aufgefüllt, das Vorzeichen bleibt dadurch erhalten.

[Thorsten S. (whitejack)]

Hallo,

vielen Dank für die schnelle Antwort.

.. so das klingt logisch,

1)also kann ich es bedenkenlos so lassen?

Mir ist beim Rumpobieren mit dem Atmega168 noch aufgefallen das mir die 
Formel mit >>9, 19 als Ergebnis und die Variante /(int16_t)(1<<9), 20 
als Ergebnis liefert.

Ergebnis ist eigentlich 0.3*133-50+30=19,9

2)Habe ich in der Shift Geschichte noch einen Denkfehler, oder wie kann 
ich mir das erklären?

Gruß,
Thorsten

[Thorsten S. (whitejack)]

Wobei >> und / nur dann äquivalent sind, wenn kein negatives Vorzeichen
mitmischt. Bei negativem Zähler kommen verschiedene Ergebnisse raus.


ist das nicht genau das was hier eben doch funktioniert? oder verstehe 
ich das falsch?

Gruß,
Thorsten

@AK, ich habe mich gestern dran gestetzt, die Formel ist lauffähig, und 
liefert für den SHT bereits passende Werte (ca. 30 verglichen mit float 
Rechnung)...

[(prx) A. K. (prx)]

Thorsten S. schrieb:

> Mir ist beim Rumpobieren mit dem Atmega168 noch aufgefallen das mir die
> Formel mit >>9, 19 als Ergebnis und die Variante /(int16_t)(1<<9), 20
> als Ergebnis liefert.

/  rundet gegen 0
>> rundet gegen -unendlich

Der Compiler wird ggf. dennoch den Shift an Stelle einer Division 
verwenden, aber bei negativem Wert vorher Nenner-1 addieren.

[(prx) A. K. (prx)]

Klaus Wachtler schrieb:

> Ja, aber nur in der niedrigstwertigen Stelle (Rundung nach unten bzw. zu
> 0 hin)

Auf die es in dem hier betrachteten Fall nicht ankommt, wenn Thorsten in 
den Hunderstel% Feuchte weiterrechnet, die aus der vorigen Formel 
rauskommen.

[Thorsten S. (whitejack)]

...kann man so aus dem Ärmel sagen, welche Lösung den genaueren Wert 
liefert oder hängt es von den Multiplikatoren ab.

Gruß,
Thorsten

[(prx) A. K. (prx)]

Thorsten S. schrieb:

> ...kann man so aus dem Ärmel sagen, welche Lösung den genaueren Wert
> liefert oder hängt es von den Multiplikatoren ab.

Im Mittel sind beide Ergebniss gleich ungenau. Echte Rundung ist 
genauer.

Aber wie eben schon geschrieben: Wenn das weiterhin Hunderstel %RH sind, 
dann interessiert dieser Unterschied nur pathologische Pedanten.

[Thorsten S. (whitejack)]

:-) das ist richtig, es sind in diesem fall Hunderstel, aber mir ging es 
bei der "Kleinigkeit" nun nur noch ums Verständnis. Will ja nicht dumm 
sterben.

Der Kernpunkt war Punkt 1, und das ist nun klar.

Vielen Dank für die ausführliche Hilfe.

Gruß,
Thorsten

[Johann L. (gjlayde)]

Thorsten S. schrieb:
> An der Stelle >>9 schifte ich eine vorzeichenbehaftete int16_t um 9 Bit
> nach rechts, warum geht das mit dem Vorzeichen nicht in die Grütze?
>
> Müsste ich nicht viel eher schreiben /(int16_t)(1<<9)  ?

Eigentlich ganz einfach:

Wenn du schieben willst, dann schiebe.
Wenn du dividieren willst, dann dividiere.

Offenbar willst du hier eine Division ausführen, also...?

Je nach Compiler und Hardware wird er eine signed Division y = x/(1<<n) 
so umsetzen:

x1 = x;
if (x < 0)
  x1 += (1<<n)-1
y = x1 >> n // signed