Forum

> > Stranded II > Allgemein > Bug Thread
Forums overviewStranded II overviewAllgemein overviewLog in to reply

German Bug Thread

1,167 replies
Page
To the start Previous 1 2 … 32 33 34 … 58 59 Next To the start

old Re: Bug Thread

Mc Leaf
Super User Off Offline

Quote
Fein, dass du (DC) wieder etwas Zeit fürs Bugfixen gefunden hast!
DC has written
Nicht beheben (können) werde ich Rundungsfehler und ähnlichen Mathescheiß.

Also einige Dinge waren schon etwas katastrophal... (naja, als Mathestudent kann ich das ja nicht unerwähnt lassen... :D)

Aktuell hab ich noch in meinem Bugreport, dass der Sinus von 90 Grad und der Kosinus von 270 Grad enorm vom tatsächlichen Wert abweichen... (evtl. war es auch sin270 und cos90... muss ich zu Hause nochmal checken).
Irgendwas hattest du ja bei den trig. Fkt. gebugfixed (s.o.), weiß nicht, ob es das war.

Vorläufig lässt sich der aber auch Bug umgehen, indem man einfach den Sinus von 90.0001 o.ä. berechnen lässt...

PS: Frohes Neues @all

old Re: Bug Thread

DC
Admin Off Offline

Quote
Die trigonometrischen Scriptbefehle sind 1:1 von den Blitz 3D Befehlen übernommen. Wenn die nicht mit dem übereinstimmen was du von Mathe kennst, ist das egal. Die erfüllen ihren Zweck dennoch. Wenn das was ich gerade geschrieben habe keinen Sinn macht, ist Magie im Spiel. Jedenfalls passt das definitiv so. Oder besser gesagt: Es MUSS so passen.

old Re: Bug Thread

Flying Lizard
User Off Offline

Quote
Nein DC, das kann ich bestätigen, allerdings ist das erst so seit die string und float (hm, isdas das richtige? habs nich so mit bezeichnungen, egal ihr wist was ich meine) Variablen eingeführt wurden.

Das hat den äuserst unschönen effekt dass wenn man mithilfe der trigonometrischen Werte Objecte in einer gewissen Position zu anderen Objecten platzieren lässt, bei genau diesen Werten die Dinge total falsch platziert werden. Is natürlich ziemlich schlecht da der Editor genau diese Winkel verwendet

old Re: Bug Thread

DC
Admin Off Offline

Quote
Oh. Ja dann liegt es aber natürlich an den Variablen, nicht an den Befehlen! Die sind nämlich korrekt.

old Re: Bug Thread

Mc Leaf
Super User Off Offline

Quote
Flying Lizard has written
Das hat den äuserst unschönen effekt dass wenn man mithilfe der trigonometrischen Werte Objecte in einer gewissen Position zu anderen Objecten platzieren lässt, bei genau diesen Werten die Dinge total falsch platziert werden. Is natürlich ziemlich schlecht da der Editor genau diese Winkel verwendet

Exakt. Aber mit dem obigen Workaround funzt es noch ganz gut.

old Re: Bug Thread

Flying Lizard
User Off Offline

Quote
also:

bei sinus weicht es bei 180° ab, eigentlich müste es 0 sein, aber er macht 2,74228

bei cosinus weicht er bei 90 und -90 ab, wieder eigentlich 0 macht aber -10,3711

jedesmal wenn man sich auch nur ein bischen dreht (ich hab den Spieler verwendet um die drehung schneller zu machen) macht er wieder den korrekten wert.

hier is der code den ich verwendet habe, und ja mit Variablen als zwischenspeicher. Die Drehung vom Spieler wird im übrigen correct ausgegeben.

1
2
3
4
5
6
7
8
9
10
11
12
on:start {
timer "self",1,0,"msg";
}

on:msg {
$yaw=getyaw ("unit",1);
$sin=sin ($yaw);
$cos=cos ($yaw);
msg "$yaw";
msg "$sin";
msg "$cos";
}

zur unterstützung um genau die richtigen Winkel zu erwischen hab ich mir noch Fackeln platziert und ihnen ein Script zum drehen des Spielers eingegeben, nix besonderes.

und jetzt probier ich mal Mc. Leafs seine idee aus, bei mir hats iwie nie ganz geklappt

EDIT:

ok, ich hab jetzt dein Workaround mal genauer durchgecheckt, undbin zum schluss gekommen dass es am wenigsten Abweichung gibt wenn man +0.001 macht (vor jeglicher Berechnung zum yaw Wert dazugezählt natürlich @andere), wenn man den wert höher setzt weicht er schon wieder ab (das scheint in einem gewissen bereich abzuweichen, nicht auf einem bestimmten Punkt) und wenn man es NOCh höher setzt, wird es ignoriert weil S2 nich genug Kommastellen bieted.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
on:start {
timer "self",1,0,"msg";
}

on:msg {
$yaw1=getyaw ("unit",1);
$sin1=sin ($yaw1);
$cos1=cos ($yaw1);

$yaw2=getyaw ("unit",1);
$yaw2= $yaw2 + 0.001;
$sin2=sin ($yaw2);
$cos2=cos ($yaw2);

msg "";
msg "";
msg "Yaw1: $yaw1";
msg "Sin1: $sin1";
msg "Cos1: $cos1";
msg "";
msg "Yaw2: $yaw2";
msg "Sin2: $sin2";
msg "Cos2: $cos2";

}

EDIT2:
@DC allerdings solltest du dich bitte trotzdem bemühen herauszufinden woran es liegt, weil unter garantie wird es bei diesem Workaround anderweitige Fehler geben
edited 3×, last 05.01.08 06:05:10 pm

old Re: Bug Thread

Mc Leaf
Super User Off Offline

Quote
Warum so kompliziert....? (okay, meine Version geht davon aus, dass der Bug nur bei ganzzahligen Vielfachen von 90 auftritt)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
on:start {
  $sin0=sin(0);
  $sin90=sin(90);
  $sin180=sin(180);
  $sin270=sin(270);
  $cos0=cos(0);
  $cos90=cos(90);
  $cos180=cos(180);
  $cos270=cos(270);
  msg "Sin 0, 90, 180, 270: $sin0, $sin90, $sin180, $sin270",4,60000;
  msg "Cos 0, 90, 180, 270: $cos0, $cos90, $cos180, $cos270",4,60000;

  msg "nochmal für negative Werte...:",3,60000;
  $sin0=sin(-0);
  $sin90=sin(-90);
  $sin180=sin(-180);
  $sin270=sin(-270);
  $cos0=cos(-0);
  $cos90=cos(-90);
  $cos180=cos(-180);
  $cos270=cos(-270);
  msg "Sin -0, -90, -180, -270: $sin0, $sin90, $sin180, $sin270",4,60000;
  msg "Cos -0, -90, -180, -270: $cos0, $cos90, $cos180, $cos270",4,60000;
}
Sin180, Cos90 und Cos270 weichen vom exakten (ganzzahligen!) Wert ab.

Allerdings erhalte ich teilweise andere Werte...:
Sin180=-14.7423
Sin-180=2.74228
Cos 90=-10.3711
Cos270=-4.80751
Cos-90=-10.3711

Eigentlich müsste wegen der Periodizität der trigonometrischen Fkt. sogar Sin180=Sin-180 und Cos270=Cos-90 sein... Also langsam werd ich hier ganz kirre...

DC hat ja die Prozeduren zur Berechnung der Funktionswerte 1:1 von BB übernommen, was ja auch sinnvoll und richtig ist. Also wenn die Entwickler von BB tatsächlich so inkompetent sein sollten, dann gute Nacht.
(^vielleicht suchen die ja noch einen angehenden Diplom-Mathematiker :D)

old Re: Bug Thread

bizzl
User Off Offline

Quote
Ich glaube mal eher das es was mit dem Float-Defekt zu tun hat (Arithmetik mit floats liefert selten exakte Ergebnisse).
C liefert mir zbsp folgende Ergebnisse (bei Verwendung von float oder double):
1
2
3
4
5
0: 0.000000
Sin 0, 90, 180, 270: 0.000000, 0.893997, -0.801153, -0.176046
Cos 0, 90, 180, 270: 1.000000, -0.448074, -0.598460, 0.984382
Sin -0, -90, -180, -270: 0.000000, -0.893997, 0.801153, 0.176046
Cos -0, -90, -180, -270: 1.000000, -0.448074, -0.598460, 0.984382
Wie man leicht sieht haben alle Werte (außer denen für 0) einen Defekt, auch wenn der hier kleiner ist als in Stranded.
Das liegt einfach an der Art und Weise wie Floats im Speicher abgelegt werden

Der einfachste was DC da machen kann wird wohl eine Wegkapselung der sin- und cos-Funktionen sein, etwa nach folgendem Schema:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
float mysin(float in) {
	int forcheck = ((int)in)%360;
	if ((forcheck == 90) || (forcheck == -270)) return 1;
	else if (abs(forcheck) == 180) return 0;
	else if ((forcheck == 270) || (forcheck == -90)) return -1;
	else return sin(in);
}

 float mycos(float in) {
	int forcheck = abs(((int)in)%360);
	if ((forcheck == 90) || (forcheck == 270)) return 0;
	else if (forcheck == 180) return -1;
	else return cos(in);
}

old Re: Bug Thread

Mc Leaf
Super User Off Offline

Quote
bizzl has written
Das liegt einfach an der Art und Weise wie Floats im Speicher abgelegt werden

Herrlich, bizzl!

Das liegt einfach daran, dass deine Werte in rad(iant) statt in deg(gree) berechnet wurden...

(typisch Informatiker... )

old Re: Bug Thread

bizzl
User Off Offline

Quote
Mc Leaf has written
Das liegt einfach daran, dass deine Werte in rad(iant) statt in deg(gree) berechnet wurden...

hoppla, tatsache
Trotzdem bekomme ich diverse Float-Defekte
single:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
sin(0)=0
sin(90)=1
[b]sin(180)=-5.421010862E-20[/b]
sin(270)=-1
sin(-0)=0
sin(-90)=-1
[b]sin(-180)=5.421010862E-20[/b]
sin(-270)=1
cos(0)=1
[b]cos(90)=-2.710505431E-20[/b]
cos(180)=-1
[b]cos(270)=1.897353802E-19[/b]
cos(-0)=1
[b]cos(-90)=-2.710505431E-20[/b]
cos(-180)=-1
[b]cos(-270)=1.897353802E-19[/b]

double erspar ich euch mal, der defekt ist dort identisch

old Re: Bug Thread

Mc Leaf
Super User Off Offline

Quote
Okay, und jetzt vergleich die Fehlerabweichung mit der bei Stranded. Na, klingelts?

Aber im Prinzip hast du natürlich Recht, bei numerischen Berechnungsverfahren gibt es stets eine Fehlerabweichung. Unter Umständen können selbst kleinste Fehlerabweichungen zu drastisch verfälschten Ergebnissen führen (schlecht konditionierter Algorithmus), aber bei Stranded vermutete ich eher einen groben Fehler bei der Konvertierung in einen anderen Zahlentyp. Wahrscheinlich ist der Exponent-Anteil bei der Konvertierung verloren gegangen, so wird bspw. aus Sin180=-5.421010862E-20 schnell -5.421010862.

old Re: Bug Thread

bizzl
User Off Offline

Quote
Mc Leaf has written
Okay, und jetzt vergleich die Fehlerabweichung mit der bei Stranded. Na, klingelts?

ja, die abweichung ist verschieden

Mc Leaf has written
aber bei Stranded vermutete ich eher einen groben Fehler bei der Konvertierung in einen anderen Zahlentyp.

Guter einfall, aber wo soll diese Umwandlung stattfinden, und von welchem Typ zu welchem anderen, und wie würdest du das ganze umgehen ?

old Re: Bug Thread

Mc Leaf
Super User Off Offline

Quote
bizzl has written
ja, die abweichung ist verschieden

Der absolute Fehler ist ungleich größer...

bizzl has written
Mc Leaf has written
aber bei Stranded vermutete ich eher einen groben Fehler bei der Konvertierung in einen anderen Zahlentyp.

Guter einfall, aber wo soll diese Umwandlung stattfinden, und von welchem Typ zu welchem anderen, und wie würdest du das ganze umgehen ?

Dafür müsste ich die Ursache des Problems genauer kennen. Bzw. mehr Kenntnisse in BlitzBasic haben...

Ansonsten müsste eine Zahlenkonvertierung in einen Zahlentyp mit Dezimalzahldarstellung (d.h. bspw. 0,01 statt 1,0E-2) erfolgen. Anschließend nach der 4. (bspw.) Stelle runden, und den Rest abschneiden (wenn notwendig, vorher in string konvertieren).
Wie gesagt, die sinnvollste Methode ergibt sich aber letzlich je nach Programmiersprache.

old Re: Bug Thread

jeepohahyo
User Off Offline

Quote
Ich nehme mal an, dass dieses ganze Kommazeugs Blödsinn ist. Im Bereich von 0 bis 1 sind die float-Zahlen so nah angeordnet, dass man eine Abweichung frühestens in der fünften Stelle bemerkt.

Das was du haben willst um Fehler zu vermeiden ist eine Festkommazahl, also eben eine solche, oder wenn es das in BB nicht gibt, ein umfunktionierter Integer

Das bringt aber auch nix, da der Fehler ja schon da ist, wenn das berechnet wurde (die Funktionen liefern immer floats zurück)

Mc Leaf has written
Wahrscheinlich ist der Exponent-Anteil bei der Konvertierung verloren gegangen, so wird bspw. aus Sin180=-5.421010862E-20 schnell -5.421010862.

Ohne Ahnung von BB zu haben sage ich mal, dass das Schwachsinn ist, dem Computer ist die dezimale Schreibweise recht egal. Ansonsten siehe oben.

Und nu Schluss, ohne Source stochern wir doch eh nur im Dunkeln herum

old Re: Bug Thread

Mc Leaf
Super User Off Offline

Quote
Dicker has written
Im Bereich von 0 bis 1 sind die float-Zahlen so nah angeordnet, dass man eine Abweichung frühestens in der fünften Stelle bemerkt.

Bei bizzls Beispiel ist sie etwa bei der 20. Stelle, bei den angesprochenen Werten bei Stranded bei der ersten Stelle...

Dicker has written
Das was du haben willst um Fehler zu vermeiden ist eine Festkommazahl, also eben eine solche

Ja, darauf wollte ich hinaus. Mir schwirrt noch eine andere Lösung durch den Kopf, aber lassen wir das.

Dicker has written
Das bringt aber auch nix, da der Fehler ja schon da ist, wenn das berechnet wurde (die Funktionen liefern immer floats zurück)

Ja, wie bei bizzls Beispiel z.B. sin(180)=-5.421E-20. Dezimalzahlen werden bei float etc. intern in Mantisse und Exponent gespalten (im Gegensatz zu Ganzzahltypen wie Integer oder Byte), geht der Exponent verloren (häufig bei falscher Konvertierung), erhält man eben nur noch -5.421.

Dicker has written
Mc Leaf has written
Wahrscheinlich ist der Exponent-Anteil bei der Konvertierung verloren gegangen, so wird bspw. aus Sin180=-5.421010862E-20 schnell -5.421010862.

Ohne Ahnung von BB zu haben sage ich mal, dass das Schwachsinn ist, dem Computer ist die dezimale Schreibweise recht egal.

Uhh, dazu sag ich jetzt mal lieber nix.
Dicker has written
Und nu Schluss, ohne Source stochern wir doch eh nur im Dunkeln herum

Korrekt, DC wird sich schon drum kümmern.

old Re: Bug Thread

bizzl
User Off Offline

Quote
Mc Leaf has written
Dicker has written
Mc Leaf has written
Wahrscheinlich ist der Exponent-Anteil bei der Konvertierung verloren gegangen, so wird bspw. aus Sin180=-5.421010862E-20 schnell -5.421010862.

Ohne Ahnung von BB zu haben sage ich mal, dass das Schwachsinn ist, dem Computer ist die dezimale Schreibweise recht egal.

Uhh, dazu sag ich jetzt mal lieber nix.

Tue nicht so als wüsstest du es besser
Man kann beim Konvertieren innerhalb der Float-Typen den Exponent nicht verlieren, und bei einer Konvertierung in einen non-Floattyp geht viel mehr verloren.

old Re: Bug Thread

Mc Leaf
Super User Off Offline

Quote
bizzl has written
Tue nicht so als wüsstest du es besser
Man kann beim Konvertieren innerhalb der Float-Typen den Exponent nicht verlieren, und bei einer Konvertierung in einen non-Floattyp geht viel mehr verloren.

Entschuldigung! Ich fand nur Dickers argumentationsweise in dem Moment sehr geil... Dass es dem PC sowieso egal ist, ist kein besonders gutes, geschweige rationales Argument... Nix, für ungut.

Naja, und ansonsten würde ich nicht so klugscheißern, wenn ich mich nicht wenigstens schonmal ansatzweise mit diesem Thema hätte auseinandersetzen müssen.

Bei der Gleitkommadarstellung werden nunmal Mantisse und Exponent getrennt gespeichert. Dass der Exponent (weshalb auch immer, das muss DC checken; vermutlich bei besonders kleinen Zahlen...?) verloren gegangen sein könnte, ist bei den diskutierten Ergebnissen nur naheliegend, und keine Klugscheißerei!

old Re: Bug Thread

bizzl
User Off Offline

Quote
Mc Leaf has written
Bei der Gleitkommadarstellung werden nunmal Mantisse und Exponent getrennt gespeichert. Dass der Exponent (weshalb auch immer, das muss DC checken; vermutlich bei besonders kleinen Zahlen...?) verloren gegangen sein könnte, ist bei den diskutierten Ergebnissen nur naheliegend, und keine Klugscheißerei!

schon klar. Aber der einzige Fall wo das passieren könnte wäre bei der umwandlung Float<->String, und dann wäre der Fehler unumgänglich und jedwege Lösung unbrauchbar
(Btw, ein ablösbarer Exponent fällt nur bei sehr kleinen Zahlen an, du kannst dir dein vermutlich sparen )

old Re: Bug Thread

Mc Leaf
Super User Off Offline

Quote
bizzl has written
Mc Leaf has written
Bei der Gleitkommadarstellung werden nunmal Mantisse und Exponent getrennt gespeichert. Dass der Exponent (weshalb auch immer, das muss DC checken; vermutlich bei besonders kleinen Zahlen...?) verloren gegangen sein könnte, ist bei den diskutierten Ergebnissen nur naheliegend, und keine Klugscheißerei!

schon klar. Aber der einzige Fall wo das passieren könnte wäre bei der umwandlung Float<->String, und dann wäre der Fehler unumgänglich und jedwege Lösung unbrauchbar
(Btw, ein ablösbarer Exponent fällt nur bei sehr kleinen Zahlen an, du kannst dir dein vermutlich sparen )

In diesem Falle kommt meine andere Lösung zum tragen: Man überprüft vor der Stringkonvertierung einfach, ob der zu konvertierende Wert eine bestimmte Schwelle (wo der Fehler auftritt, bspw. 10E-5) unterschreitet, falls ja, dann wird einfach der Wert 0 (zum konvertieren) zurückgegeben (Pseudocode erspare ich mir mal). Aber wie gesagt, DC muss erstmal schauen, was den Fehler verursacht.
To the start Previous 1 2 … 32 33 34 … 58 59 Next To the start
Log in to replyAllgemein overviewStranded II overviewForums overview