Eigenartige FloatWerte : 1.#QNAN und -1.#IND ???

Für allgemeine Fragen zur Programmierung mit PureBasic.
Benutzeravatar
PureLust
Beiträge: 1145
Registriert: 21.07.2005 00:02
Computerausstattung: Hab aktuell im Grunde nur noch 'nen Lenovo Yoga 2 Pro im Einsatz.
Wohnort: am schönen Niederrhein

Eigenartige FloatWerte : 1.#QNAN und -1.#IND ???

Beitrag von PureLust »

In einer meiner Routinen funktionierte nach etlichen Berechnungen plötzlich etwas nicht so wie es sollte (Fehlberechnung).
Somit wollte ich das also mal per Debugger überprüfen.
Die Variablenliste des Debuggers gab mir für die fehlberechnete Variable (ySpeed.f) folgende Werte zurück:

ySpeed.f = -1.#IND
bzw.
ySpeed.f = 1.#QNAN

Hat jemand eine Ahnung was diese Werte zu bedeuten haben?

PS: Ist ein PB4 Code
[Dynamic-Dialogs] - komplexe dynamische GUIs einfach erstellen
[DeFlicker] - Fenster flimmerfrei resizen
[WinFX] - Window Effekte (inkl. 'durchklickbares' Window)
Benutzeravatar
Deeem2031
Beiträge: 1232
Registriert: 29.08.2004 00:16
Wohnort: Vorm Computer
Kontaktdaten:

Beitrag von Deeem2031 »

Bild
[url=irc://irc.freenode.org/##purebasic.de]irc://irc.freenode.org/##purebasic.de[/url]
Benutzeravatar
Zaphod
Beiträge: 2875
Registriert: 29.08.2004 00:40

Beitrag von Zaphod »

Und IND könnte für "Unendlich" stehen.
Benutzeravatar
#NULL
Beiträge: 2237
Registriert: 20.04.2006 09:50

Beitrag von #NULL »

bei infinite wird eigentlich
1.#INF
ausgegeben

Code: Alles auswählen

i=0
f.f=3/i
Debug f
hier
http://www.purebasic.fr/english/viewtop ... hlight=ind
werden einige dieser sonderwerte besprochen (ASM).

woandersher, nicht PB:
The -1.#IND was the result of taking the inverse cosine of x and
ofcourse there's no acos of a number lower than -1 or higher than 1.
(quelle - ein paar messages weiter)
#IND wird wohl für indefinite stehen, viellecht bei berechnungen die zur laufzeit einfach nicht sinnvoll ausgeführt werden konnten.
my pb stuff..
Bild..jedenfalls war das mal so.
Benutzeravatar
Zaphod
Beiträge: 2875
Registriert: 29.08.2004 00:40

Beitrag von Zaphod »

Stimmt, da hast du wohl recht.

Mußte mir erst wieder den Unterschied zwischen NaN und Undefiniert bewußt machen ;)
Benutzeravatar
PureLust
Beiträge: 1145
Registriert: 21.07.2005 00:02
Computerausstattung: Hab aktuell im Grunde nur noch 'nen Lenovo Yoga 2 Pro im Einsatz.
Wohnort: am schönen Niederrhein

Beitrag von PureLust »

Moin zusammen,

nachdem ich mich in dieses Thema nun etwas eingelesen habe komme ich damit wohl weiter - vielen Dank. :allright:

Mir wäre zwar lieber, dass solche - nennen wir sie mal Formel- oder auch Berechnungsfehler auf Grund fehlerhafter Werte - eine Exception auslösen würden, damit man den exakten Ursprung besser lokalisieren könnte - aber ich werde ihn schon irgendwie finden. ;)
Ich werd's mal mit der IsInforNaN(x.f) Prozedor aus #NULLs Link versuchen.

Also nochmals vielen Dank für die Hilfe. :allright:

Grüße, PureLust.


Auf Grund eines bösen Irrtums:
[######## NACHTRAG ########]


Die in #NULLs verlinktem Thread gepostete Lösung mit der Assembler-Prozedur
IsInforNaN(x.f) funktioniert leider nicht unter PB4.
Unter PB3.94 funnzt es jedoch alles problemlos. :cry:
Hätte jemand evtl. eine PB4-kompatible Variante davon?

(Scheinbar klappt der Compare nicht mehr oder ich kriege den JE zum Label @ nicht ans laufen. :|
Sorry, aber meine eigenen Assemblerkenntnisse sind halt noch auf dem 68000er Stand von von 20 Jahren.)
[Dynamic-Dialogs] - komplexe dynamische GUIs einfach erstellen
[DeFlicker] - Fenster flimmerfrei resizen
[WinFX] - Window Effekte (inkl. 'durchklickbares' Window)
Antworten