Seite 1 von 1

Probleme mit Floats und deren Konvertierung

Verfasst: 04.10.2006 15:21
von ZeHa
Hallo, da ich im Moment nicht mit Purebasic arbeite, poste ich es lieber mal hier in die Laberecke.

Also es geht um folgendes: Ich muß den Zahlenraum einer Float zwischen 0.0 und 1.0 optimal nutzen. Da die Mantisse ja 23 Bit bietet, müßte es doch eigentlich gehen, jede beliebige Zahl zwischen 0 und x7FFFFF dort hineinzuschreiben.

Da ich aber mit Floats nicht so viel Ahnung habe, hab ich einfach mal folgendes ausprobiert:

Code: Alles auswählen


void test()
{
    float f = 0;
    float previous = 0;
    int err = 0;

    for(int i=0; i<0xFFFFFFFF; i++)
    {
        __asm
        {
            mov eax, i
            mov f, eax
        }

        if (previous > f)
        {
            printf("moment mal die vorherige zahl war groesser\n");
            err++;
        }

        if (f > 1.0)
        {
            printf("\ndie 1.0 wurde erreicht\n");
            break;
        }

        if (i % 50000 == 0)
            printf("%8X - %1.58f\n", i, f);

        previous = f;
    }

    printf("\n\n%i errors.\n\n", err);

    exit(0);

}
Dieses Programm hat mir nun bewiesen, daß
a) der Float-Wert stetig ansteigt, es also keine Anomalien gibt
b) im Raum 0 bis 1 sogar nicht nur die 23 Bit zulässig sind, sondern sogar Zahlen bis 0x0x3F7FF370, was mich doch sehr gewundert hat.

Trotzdem wurden die Zahlen perfekt ausgegeben und ich dachte "supergenial, dann hab ich ja viel mehr Spannweite als eigentlich erwartet". Zwar ist es komisch, daß die Zahlen weiterhin so anstiegen, obwohl ja die 23 Bit der Mantisse längst überstiegen worden sind.

Aber gut, da wollte ich es einfach mal in mein fertiges Programm einbauen. Es geht drum, den Z-Wert für die glTranslatef-Funktion festzulegen. Nur leider sieht es nun so aus, als würde glTranslatef alle sehr kleinen Werte als 0 ansehen. Obwohl mein Test-Programm ja eigentlich (scheinbar?) bewiesen hat, daß das alles gültige und zudem mikroskopisch kleine, aber eindeutige Float-Werte sind.

Kann mir hier jemand weiterhelfen?

Verfasst: 04.10.2006 15:27
von MVXA
Wäre es dann nicht in "Andere Sprachen" besser aufgehoben?

Verfasst: 04.10.2006 15:34
von ZeHa
Naja es ist ein generelles Problem, das an keine Sprache gebunden ist. Meiner Meinung nach müßte das ja auch in PB möglich sein, aber ich weiß grad nicht genau wie die ASM-Syntax unter PB geht. Aber das Beispiel kann ich ja kurz umtippen....

EDIT: So das müßte so ungefähr das wiedergeben, um was es letztendlich geht (ungetestet)

NOCHMAL EDIT: Nun funzt es, aber da PB keine unsigned Variablen kennt habe ich nun den Wertebereich bis 0xFFFFFF begrenzt. Damit wird zwar die maximale Grenze nicht erreicht, aber man sieht schon von Beginn an, daß die Zahlen anfangs definitiv VORHANDEN sind und auch eindeutig sind.

Code: Alles auswählen

OpenConsole()

Procedure testprog()
	float.f = 0
	previous.f = 0

	For i = 0 To $FFFFFF
		MOV eax, i
		MOV float, eax

		If previous > float
			PrintN("moment mal die vorherige zahl war groesser")
		EndIf

		If float > 1.0
			PrintN("die 1.0 wurde erreicht")
			Break
		EndIf

		If (i % 50000 = 0)
			PrintN(Hex(i) + " - " + StrF(float, 60))
		EndIf

		previous = float
	Next i
EndProcedure

testprog()

Input()

Verfasst: 04.10.2006 18:40
von ZeHa
Naja also nach reifer Überlegung habe ich nun das Gefühl, das Problem liegt nicht bei den Floats selbst, sondern daran, daß der Depth Buffer evtl. keine allzu mikroskopisch aufgelösten Floats handhaben kann - ist das möglich?