GCC - Rundungsfehler ?

Ralph S. schrieb:
> printf("\n  Pythagoras");
>   printf("\n  Diagonale [cm] : %.2f",dinch*2.54);
>   printf("\n  Breite    [cm] : %.2f",(x / sqrt((x*x)+(y*y))) * 2.54   );
>   printf("\n");

Bei Breite fehlt doch ein *dinch, daher der Fehler.

Ich bin sooooooooooooooooooooooo blöd, und Entschuldigung für die 
Störung, ich hätte mir den ganzen Text hier sparen können:

printf("\n  Breite    [cm] : %.2f",(x / sqrt((x*x)+(y*y))) * 
(dinch*2.54) );

Tassilo H. schrieb:
> Bei Breite fehlt doch ein *dinch, daher der Fehler.

jetzt ... weiß ichs leider auch ! Aber danke !

hrmpf und schäm !

Noch so ein kleiner Tipp am Rande:

Man kann zwar für den Atmega (AVR-GCC)

1

double myVar = 1234.56789;

schreiben, das wird aber immer ein float sein, sprich myVar hätte 
lediglich den Wert 1234.567 (wenn ich mich recht entsinne mit 7 Stellen 
Genauigkeit bei Float).

M. K. schrieb:
> das wird aber immer ein float sein

Um es zu präzisieren:
AVR-GCC verwendet für float und double den gleichen Datentyp; sizeof 
float == sizeof double == 4.

Es hat sich bislang niemand die Mühe gemacht, 
64-Bit-floatingpoint-Aritmetik auf den AVR zu portieren.

Ralph S. schrieb:
> Wo liegt nun mein Fehler ? (an Rundungsfehler will ich nicht glauben)

Du rundes nicht.
Sonder du kürzt letztendlich das Ergebnis auf 2 Nachkommastellen.
Zum runden muss man z.b. den Befehl round() vor der Ausgabe verwenden.

M. K. schrieb:
> Noch so ein kleiner Tipp am Rande:
>
> Man kann zwar für den Atmega (AVR-GCC)
>
>

1

double myVar = 1234.56789;

>
> schreiben, das wird aber immer ein float sein,

No, es ist kein float sondern ein nicht standardkonformer double. 
Ersichtlich z.B. daran, dass avr-g++ double als "d" mangled und float 
als "f".

Johann L. schrieb:
> No, es ist kein float sondern ein nicht standardkonformer double.
> Ersichtlich z.B. daran, dass avr-g++ double als "d" mangled und float
> als "f".

Einfach mal obiges Beispiel ausprobieren und anzeigen lassen, was bei 
rum kommt ;)

Beim AVR-GCC haben float und double zwar die gleiche Größe und die
gleiche interne Darstellung, es sind aber formal trotzdem zwei
verschiedene Datentypen. Entsprechendes gilt bspw. auch für int und
short, die beim AVR-GCC beide vorzeichenbehaftete 16-Bit-Ganzzahlen,
aber trotzdem verschiedene Datentypen sind.

Yalu X. schrieb:
> Beim AVR-GCC haben float und double zwar die gleiche Größe und die
> gleiche interne Darstellung, es sind aber formal trotzdem zwei
> verschiedene Datentypen. Entsprechendes gilt bspw. auch für int und
> short, die beim AVR-GCC beide vorzeichenbehaftete 16-Bit-Ganzzahlen,
> aber trotzdem verschiedene Datentypen sind.

So kenn ich es auch. Es sind zwar unterschiedliche Datentypen, haben 
aber die gleiche Größe was unterm Strich bedeutet, dass man damit das 
gleiche Ergebniss erhält. Ich wollte nur drauf hinweisen da ja z.B. 
Double eigentlich bedeutet, dass das ein Float mit doppelter Genauigkeit 
ist, im Falle des AVR-GCC ist dem aber nicht so, da ist ein Double eben 
nicht genauer als ein Float.

Schmunzeln muß, ich wollte jetzt keine Fiskussion über Datentypen 
anwerfen. Ursprünglich war das eh alles float und ich hatte die 
Datenrypen verändert.

Ich hatte einfach nur schlicht einen Programmierfehler den ich vor 
Blindheit nicht sah. Erfreulich für mich war, dass der Codeschnippsel 
für alle 3 Plattformen ohne Änderung übersetzt wurde....

Ralph S. schrieb:
> Hieraus ergeben sich 2 Lösungsansätze, einmal über Trigonometrie und
> einmal über den Satz des Pythagoras:

Der Ansatz über "Trigonometrie" ist allerdings deutlich aufwändiger, 
sowohl was Rechenzeit als auch Codegröße angeht, und schlechter 
konditioniert ist er auch.

Offenbar gilt cos(atan(x)) = 1/(1+x²) so dass die 2. Formel ohne atan 
und cos geschrieben werden kann, und die Umrechnungen zwischen Altrgrad 
und Radians fällt auch weg.

Zur Berechnung der Hypothenusenlänge gibt's seit C99 übrigens hypot:

https://linux.die.net/man/3/hypot

jo schrieb:
> Mal %lf im Formatstring probiert? %f ist normalerweise für float. Ob es
> was ausmacht, ist natürlich sehr compiler- und prozessorabhängig...

Nein. %f ist für double. float kann man an printf gar nicht übergeben, 
da bei variadischen Parametern float immer erst in double konvertiert 
wird.

Ralph S. schrieb:
> Ursprünglich war das eh alles float und ich hatte die
> Datenrypen verändert.

Warum hast du sie denn verändert, hilft doch beim AVR eh nicht.

M. K. schrieb:
> Warum hast du sie denn verändert, hilft doch beim AVR eh nicht.

Weil ich so dämlich war und den logischen Fehler nicht gesehen hatte, 
also hab ich geguckt wie es sich mit unterschiedlichen Datentypen 
verhält.

Letztlich ist es halt schlicht MEIN Programmierfehler gewesen, mehr 
nicht !
noch mal lächeln muss : Verrückt, dass hieraus ein längerer Thread 
entsteht als es muss...

Johann L. schrieb:
> Der Ansatz über "Trigonometrie" ist allerdings deutlich aufwändiger,
> sowohl was Rechenzeit als auch Codegröße angeht, und schlechter
> konditioniert ist er auch.

Das ... wäre das Ziel der Lerneinheit gewesen... die ich nun doch nicht 
mache, irgendwie ist mir mein Fehler schlicht peinlich, dass ich ein 
anderes Beispiel verwenden werde...

Ralph S. schrieb:
> x= 128.0; y= 64,0; dinch= 0.96;
                 ^
Glück gehabt, weil da eine 0 folgt.
Wäre mit Warnings wohl aufgefallen.