uint16_t Division klappt nicht

Peter Gast #5264114
Lesenswert?
• ▲
▼ 
Hallo zusammen, ich habe folgendes Problem und wäre über etwas Hilfe 
dankbar.


uint16_t value1 = 1400;
uint16_t value2 = 15;
uint16_t result = 0;
float div = 0.0;

div = value1 / value2;
result = (int)div;

Als Ergebnis bekomme ich immer 0!!!


Im anderen Fall bekomme ich aber immer ein richtiges Ergebnis:

uint16_t value1 = 1320;
float multiply = 0.0;
uint16_t result = 0;

multiply = value1 * 0.00209;
result = (int)multiply

Weis jemand, woran das liegt und wo das Problem im ersten Fall liegt?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
M. K. #5264183
Lesenswert?
• ▲
▼ 
Stefan K. schrieb:
> Wahrscheinlich wurde die Berechnung vom Compiler wegoptimiert, weil das
> Ergebnis nirgends gebraucht wird.

Eher unwahrscheinlich wegen:

Peter schrieb:
> Als Ergebnis bekomme ich immer 0!!!

Irgendwie muss er sich ja div anzeigen lassen und spätestens da wird das 
Ergebnis gebraucht.
Wahrscheinlicher ist, dass die gewählte Anzeigeart ungeeignet ist. Ohne
den kompletten Code ist das aber alles nur Stochern im Nebel.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Beitrag #5264184 wurde von einem Moderator gelöscht.
Beitrag #5264193 wurde von einem Moderator gelöscht.
Peter Gast #5264533
Lesenswert?
• ▲
▼ 
Entweder castest du die Operanden auf float BEVOR die Operation 
ausgeführt wird:
1
div = (float)value1 / (float)value2;


Oder du definierst die Operanden von vorne herein als float:
1
float value1 = 1400.0;

2
float value2 = 15.0;


Den C-Compiler juckt der Typ vor dem '=' nicht. Wenn die Operanden 
integer sind, dann wird auch eine integer-Operation durchgeführt.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jim M. #5264554
Lesenswert?
• ▲
▼ 
Peter schrieb:
> Entweder castest du die Operanden auf float BEVOR die Operation
> ausgeführt wird:

Auch dann wäre das Ergebnis nicht Null, denn 15 passt ein paar mal in 
1400.

Der OP hat ein Anzeigeproblem, vermutlich weil die passende 
Format-String Library nicht verlinkt wurde. Aber das sehen wir ohne 
Zugriff auf den restliche Code nicht.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Di P. Persönliche Seite #5264572
Lesenswert?
• ▲
▼ 
Bei mir kommt auch keine 0 als für result raus: 
https://onlinegdb.com/HyGUKu9mG

Hab's mal um den richtigen cast für div2 erweitert ;)

1
#include<stdio.h>

2


3
int main() {

4
__uint16_t value1 = 1400;

5
__uint16_t value2 = 15;

6
__uint16_t result = 0;

7
__uint16_t result2 = 0;

8
float div = 0.0;

9
float div2 = 0.0;

10


11
div = value1 / value2;

12
result = (int)div;

13


14
div2 = (float)value1 / value2;

15
result2 = (int)div;

16


17
printf("div: %.6f \n", div);

18
printf("result: %i \n \n", result);

19


20
printf("div2: %.6f \n", div2);

21
printf("result2: %i \n \n", result2);

22
}
Antwort Zitieren Bearbeiten Löschen Beitrag melden
W.S. Gast #5266404
Lesenswert?
• ▲
▼ 
Peter schrieb:
> Hallo zusammen

..also schreib zuerst mal, auf was für einer Hardware und mit welchem 
Compiler das ganze laufen soll.

Der Grund für meinen Einwurf besteht darin, daß ich vor einiger Zeit bei 
einer speziellen CPU, nämlich dem LPC11E12 und mit dem Keil übersetzt 
festgestellt habe, daß dort Rechnungen in float bei bestimmten 
Argumenten schlichtweg falsch gehen.

Derselbe Code - präziser: derselbe Maschinencode, dasselbe Hexfile auf 
einen LPC11E14 gebrannt - funktionierte richtig.

Peter schrieb:
> float div = 0.0;
>
> div = value1 / value2;
> result = (int)div;

Warum schreibst du sowas?

Also ich würde es so schreiben:

1
 int result;

2
 float div;

3


4
 div = value1;

5
 div = div / value2;

6
 result = div;

Warum? Damit die Division in float stattfindet und nicht in int.

Und in Pascal würde ich dann auch result:= round(div); schreiben.

W.S.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jim M. #5266505
Lesenswert?
• ▲
▼ 
W.S. schrieb:
> daß dort Rechnungen in float bei bestimmten
> Argumenten schlichtweg falsch gehen.
>
> Derselbe Code - präziser: derselbe Maschinencode, dasselbe Hexfile auf
> einen LPC11E14 gebrannt - funktionierte richtig.

Bei sowas sollte man mal in das Errata Sheet schauen. Ich würde spontan 
auf Errata 5.2 tippen:

> For LPC11E14/401 devices with date codes 1238 and before, the 2 kB SRAM
> located at address 0x20000000-0x20000800 is not available.

Float Sachen auf Cortex-M0 sind reine Software. Wenn DAS nicht geht ist 
was grundsätzliches faul.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
M. K. #5266846
Lesenswert?
• ▲
▼ 
W.S. schrieb:
> Damit die Division in float stattfindet und nicht in int.

Und welchen Vorteil soll das beim bestehenden Problem haben? Ich mein, 
1400/15 = 93, und wenn das System nur auf 8 bit arbeiten würde käme da 
immer noch 17 raus. Beim TE kommt aber anscheinend 0 raus und daran 
sieht man, es ist kein Typ-Problem sondern ein Anzeigeproblem. Er sollte 
erstmal das Problem lösen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren