AVR GCC Wurzel-ziehen

Oct 30, 2006 7 Replies

Hallo,



ich habe hier ein Programm für einen ATMega128 geschrieben, in dem ich an einer Stelle die Quadratwurzel aus einer Float-Variablen ziehen muss. Dazu verwende ich pow(x,y) mit y = 0.5. An einer anderen Stelle muss ich einen Wert mit 0.37 potenzieren, was anscheinend einwandfrei funktioniert. Dort wird die zu potenzierende Variable aber niemals 0:



..... double hu(double h, double g) // berechnet Haugh-Units aus Eiklarhöhe h und Gewicht g { return (100 * log10(h + 7.57 - 1.7* pow(g,0.37) )); } ....


weiter unten verwende ich pow(x,0.5) als Übergabeparameter für einen Funktionsaufruf, in dem ich das Ergebnis auf eine serielle Schnittstelle ausgebe:



... printfdouble(pow(weight_v,0.5),5,1); ...



Wenn aber weight_v = 0 ist, erhalte ich als Ergebnis 1.0 Für Werte > 0 funktioniert pow(x,y) anscheinend einwandfrei.



Ist das normal?


Gruß



Stefan


hm, hab da noch eine Idee, was ist, wenn weight_v = -0.00000000000000000000000001 ??



dürfte aber nicht sein???


Hi Stefan,

Es gibt aber auch sqrt().

Da Du "weiter unten" sagst, nehme ich an, daß es die gleiche Quelle ist?

Ansonsten wär mein Tipp: Header vergessen, dadurch Prototyp unbekannt, Datentyp der Parameter defaultet zu int, aus 0.5 wird 0, und irgendwas hoch 0 ist 1.0 (ja, auch 0 hoch 0).

Ansonsten ist das IMHO nicht normal, und auch nicht standardkonform. Mit mingw32-gcc kriege ich für pow(0, 0.5) wie erwartet 0.0 raus.

Dann bekommst Du NAN zurück, isnan() auf den Rückgabewert von pow() liefert dann wahr.

Da bin ich nicht so sicher. Vergleich doch einfach vorher, ob Dein Wert nahe genug an Null ist, sodaß Du ihn als Null verstehen willst. DBL_EPSILON ist der kleinste garantiert darstellbare Unterschied zweier Doubles (AFAIR).

Gruß, Felix

Stefan Brr=F6ring schrieb:

Hallo,

pow(x, y) soll f=FCr x !=3D 0 und y =3D=3D 0 den Wert 1 liefern, f=FCr x =3D=3D 0 und y 0 m=FCsste es den Wert 0 liefern.

Gibt es bei dem benutzten Compiler =FCberhaupt NaN? Was steht in der=20 Beschreibung der Library zu pow?

Bye

ACK.

ACK.

Gruß, Felix

Danke erstmal für die Antworten. Ich programmiere sonst fast ausschließlich in Pascal bzw. Delphi und dort fallen mir solche Merkwürdigkeiten nicht (oder nicht mehr?) auf.

Der Tip mit sqrt() ist aber schon mal gut, sieht genauso aus wie in Pascal :-) Werd ich morgen mal ausprobieren. Und wenn es damit dasselbe Problem gibt, ein Workaround schreiben.

Gruß

Stefan

Uwe Hercksen schrieb:

Compiler: ja (ist halt ein GCC), Library: halbherzig bis eher nicht.

-- cheers, J"org .-.-. --... ...-- -.. . DL8DTL

formatting link
NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)

Also eigentlich bin ich ziemlich begeistert von WINAVR. Ist zwar eine Umstellung von Pascal nach C (C ist einfach krank :-) ), aber für aufwendigere Projekte doch angenehmer als Assembler.

Besonders angenehm war, dass es nach der Installation weitgehend problemlos funktionierte.

Gruß

Stefan

"Stefan Brroering" schrieb:

Das ändert nichts an der Tatsache, dass der Gleitkomma-Teil der Bibliothek, nun, ähem, ziemlich unverständlicher Kauderwelsch ist, den wir seinerzeit von einem Pionier der AVR-GCC-Geschichte geerbt haben (und der wiederum ist wohl aus einer Portierung von 8051-Code entstanden, wenn ich das richtig sehe). Er ist zwar mit seinem Assemblergehacke schweinisch effektiv (das ist *der* Grund, warum das nicht schon längst jemand neu gezimmert hat), aber auf ,,Randgebiete'' wie all die netten IEEE-754-Features geht er eher halbherzig ein, teilweise (denormals) sind sie gar nicht behandelt.

Jörg Wunsch "Verwende Perl. Shell will man können, dann aber nicht verwenden." Kristian Köhntopp, de.comp.os.unix.misc

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required