Forum: Compiler & IDEs Multiplikation falsches Ergebnis


von Ronny S. (ronnysc)


Lesenswert?

Hallo,

ich habe zum Umrechnen eines AD-Wertes eine Gleichung nach dem Dreisatz 
erstellt. Doch GCC spuckt das falsche Ergebnis aus.
1
unsigned int adc_wert;
2
unsigned int cache;
3
char buffer[10];
4
5
int main (void)
6
{
7
   adc_wert = 1000;
8
   cache = (adc_wert * 6006)/2048;
9
   itoa (cache, buffer, 10);
10
}

wenn ich aber mit 65536 als Divisor rechne stimmt das Ergbnis wieder.
1
unsigned int adc_wert;
2
unsigned int cache;
3
char buffer[10];
4
5
int main (void)
6
{
7
   adc_wert = 1000;
8
   cache = (adc_wert * 196608)/65536;
9
   itoa (cache, buffer, 10);
10
}
wo liegt bei mir hier der Fehler.
Danke
Ronny

Und ja ich habe die Forumssuche benutzt, aber nichts dazu gefunden. Und 
ich habe gerade mein C-Buch nicht zur Hand, ist in der Wäsche. :-)

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Rechne mit 32 Bit und nicht mit 16. Deine Zehlen passen nämlich nicht in 
16 Bits rein.

Johann

von SoLaLa (Gast)


Lesenswert?

ich denke mal weil (6006/2048)!=(196608/65536) ist :-)

von Ronny S. (ronnysc)


Lesenswert?

das Ergebnis der ersten Berechnung ist 0 und das 2. Ergebnis ist 3000 
(richtig). Ich habe auch schon die Variable cache auf unsigned long 
geändert und dann wieder auf int16 gecastet (für ITOA). Keine Änderung. 
Wenn es daran liegen soll, würde die 2. Gleichung auch nicht 
funktionieren. Das Ergebnis stimmt aber.

Ronny

von Jörg G. (joergderxte)


Lesenswert?

Hast du es mal so probiert (was gjlayde sagte):
1
int main (void)
2
{
3
   adc_wert = 1000;
4
   cache = (adc_wert * 6006L)/2048;
5
//                         ^ so wird mit 32 Bit gerechnet
6
/* oder auch:
7
   cache = (adc_wert * 192192)/65536;
8
                       ^^^^^^ (ist NICHT die Zahl von dir)
9
*/
10
   itoa (cache, buffer, 10);
11
}
Der C Standard schreibt vor, dass im größten beteiligten Datentyp 
gerechnet wird - und nicht mit dem, für das Ergebnis, nötigen.

hth, Jörg
ps.: Gewöhne dir solche 'Magic Numbers' (unerklärte Zahlen) ab und 
schreib entweder die Gleichung hin oder benutz Macros.

von Ronny S. (ronnysc)


Lesenswert?

Jörg G. wrote:
> Hast du es mal so probiert (was gjlayde sagte):
>
1
> int main (void)
2
> {
3
>    adc_wert = 1000;
4
>    cache = (adc_wert * 6006L)/2048;
5
> //                         ^ so wird mit 32 Bit gerechnet
6
> /* oder auch:
7
>    cache = (adc_wert * 192192)/65536;
8
>                        ^^^^^^ (ist NICHT die Zahl von dir)
9
> */
10
>    itoa (cache, buffer, 10);
11
> }
12
>
> Der C Standard schreibt vor, dass im größten /beteiligten Datentyp/
> gerechnet wird - und nicht mit dem, für das Ergebnis, nötigen.
>
> hth, Jörg
> ps.: Gewöhne dir solche 'Magic Numbers' (unerklärte Zahlen) ab und
> schreib entweder die Gleichung hin oder benutz Macros.

Vielen Dank, das war der richtige Hinweis. Was mich aber wundert ist die 
Tatsache das (adc_wert * 196608)/65536 auch funktioniert ohne dem "L"

Ronny

von Helmut L. (helmi1)


Lesenswert?

>Tatsache das (adc_wert * 196608)/65536 auch funktioniert ohne dem "L"
                          ^^^^^^
                          Das kann der Compiler nur als Long darstellen

deshalb rechnet er dann den rest in long

Gruss Helmi

von Jörg G. (joergderxte)


Lesenswert?

>Was mich aber wundert ist die Tatsache das
>(adc_wert * 196608)/65536 auch funktioniert ohne dem "L"
Weil "196608" nicht in ein int passt und deshalb gleich als long 
gerechnet wird.
Evtl. erzeugt ein cast der Variablen besseren (kürzeren) Maschinen-Code, 
ich hab
aber keine Lust das jetzt auszuprobieren ;)
1
   adc_wert = 1000;
2
   cache = ((long)adc_wert * 6006)/2048;
Falls du dir also den Asm-Code anschaust (.lss/.lst-Datei), poste das 
mal bitte.

hth, Jörg

von Ronny S. (ronnysc)


Lesenswert?

Danke Anwort reicht mir schon, war nur interessehalber warum die 2. 
Berechnung funktionert hat.

Das beweist wieder den Satz: Der "Dumme" sitzt immer VOR dem Rechner. 
;-)

Ronny

von yalu (Gast)


Lesenswert?

Wenn Zeit- und Flash-Verbrauch eine Rolle spielen:
1
   cache = (adc_wert * 47)/16;

Das geht in 16 Bit und ist nur 0,17% falsch. Der ADC ist meist auch
nicht genauer.

Bitte 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
Noch kein Account? Hier anmelden.