Ich denke hier ist es eher angemessen, als im Bug-Hunt zu posten. Anhand des Handbuches war mir schon klar, dass bei Berechnungen mit Multiplikation & Division bei sehr hohen bzw. sehr niedrigen Zahlen Abweichen auftreten können. Ich verwende solche math. Berechn. um Zahlen auf eine Nachkommastelle zu runden. Hier der Code:

Code:

---

var test=0.55;
test = int(10 * (test + 0.05)) / 10;   

---

Dieser Code sollte normalerweise den Wert der Zahl von 0.55 auf 0.6 aufrunden (achtung: außerdem wurden nachfolgende Kommastellen abgetrennt) . In diesem Fall wird als Endwert 0.5 ausgegeben. Das hängt dadurch zusammen, dass die Engine beim Multiplizieren von 0.6 und 10 den Wert "5.996" ausgibt und dann der Rest nach dem Komma abgetrennt wird.

Lösung: Beim Erhöhen der Test-Variable anstatt 0.05 um 0.051 erhöhen.

Vorschlag: Eigentlich wurden im obigen Code keine extrem hohe und extrem niedrige Zahlen verwendet (aus dem Manual ), deshalb finde ich sollte dies evtl. verbessert werden. Zumindest in C-Lite. Selbst der Windows-Taschenrechner kann das besser, möglicherweise aber langsamer.

Sie haben den Grund fuer das Problem richtig erkannt. Lite-C oder irgendeine andere Programmersprache kann hier jedoch nicht helfen, sondern nur sorgfaeltiger Umgang mit Festkomma Variablen. Drei Nachkommastellen bedeuten, dass jede Zahl um 0.001 ungenau ist, und wenn Sie das mit 10 multiplizieren, liegt die Ungenauigkeit schon bei 0.01.

Danke für den Tip, dass es bei anderen Programmiersprachen auch so ist.

Hier eine kleine Info zu Gleitpunktzahlen; aufgrund meines Studiums bin ich da gerade voll im Stoff :

Der Typ float ist ungenau bei sehr großen und bei sehr kleinen Werten. Er ist geeignet, wenn ein Bruchteil benötigt wird, aber kein größerer Präzisionsgrad gefordert ist. Der Typ double ermöglicht Zahldarstellungen, die gegenüber dem Typ float die doppelte Genauigkeit besitzen. In der Regel wird der Typ double verwendet.

float: −3.4*10-38 bis +3.4*10+38 (ergibt ungefähr 6 bis 7 signifikante Dezimalziffern Genauigkeit), belegt 4 Bytes

double: −1.7*10-308 bis +1.7*10+308 (ergibt ungefähr 15 signifikante Dezimalziffern Genauigkeit), belegt 8 Bytes

Wie bei ganzen Zahlen, so kann auch bei Gleitpunkt-Zahlen nur eine endliche Ziffernzahl gespeichert werden. Eine Gleitpunkt-Zahl besitzt allgemein folgende Form:

a = ±m * b±e (z.B. 16.875 * 10-1)

m wird als Mantissenteil (auch Bruch genannt), b als Basis und e als Exponent bezeichnet. Diese Form wird Gleitpunkt-Darstellung (floating point) oder halblogarithmische Darstellung genannt. Die Bezeichnung Gleitpunkt kommt daher, dass durch die Wahl des Exponenten die Lage des Punktes bzw. Kommas festgelegt wird und durch Änderung des Exponenten verschoben werden kann.

Durch die begrenzte Stellenzahl für den Mantissenteil gehen Stellen verloren, d.h. an Stelle der exakten Werte wird mit Näherungswerten gerechnet. Da nur mit Näherungswerten gerechnet wird, folgt natürlich, dass es sich bei den Ergebnissen auch nur um Näherungswerte handeln kann. Die Abschätzung der Fehler, die sich aus den Operationen mit Zahlen ergeben, ist in den meisten Fällen sehr schwierig. Die meisten Computersysteme wandeln Dezimalzahlen in das Zweiersystem um. Auch einfach erscheinende Zahlen wie 0.1 werden dabei gerundet und deshalb ungenau. Ohne Rundungsfehler wird aber z.B. 0.125 als 2-3 dargestellt.

Durch die begrenzte Stellenanzahl für eine Gleitpunktzahl in einem Computersystem - insbesondere beim Mantissenteil - sind die Addition von Zahlen sehr unterschiedlicher Größe und die Subtraktion von dicht benachbarten Zahlen (Auslöschung) zu vermeiden. Wegen der Überlaufgefahr soll keine Division durch Werte in der Nähe von Null vorgenommen werden. Abfragen auf Gleichheit (==) von zwei Gleitpunktzahlen sind verboten. Stattdessen ist auf einen tolerierbaren Differenzbetrag e abzufragen (abs(x - y) < e).

Erst mit liteC (oder jetzt in Verbindung mit einer DLL) ist es möglich, durch die Typisierung von Variablen die Genauigkeit bei mathematischen Operationen zu erhöhen. Zur Zeit kann man in CScript das nur durch eine ausgewählte Reihenfolge der Operationen erzielen.

Nur damit keine Missverstaendnisse entstehen: Vars sind keine Gleitkommazahlen, sondern Festkommazahlen.

Richtig, und da Festkommazahlen noch eingeengter sind, ist es wahnsinnig heikel damit wild rumzurechnen. Ich wollte das Grundproblem erörtern.

naja, vielleicht möchte ja jemand so eine dll programmieren...

Code:

---

template <class PT, class DT> PT _makeContainer(PT* v)
{
	return (*v = (PT)(new DT));
}
template <class PT, class DT> _delContainer(PT* v)
{
	v = dynamic_cast<DT*>(*v)) ? 0 : v;
}
template <class PT, class DT> DT _getValue(PT* v)
{
	return (DT _v = dynamic_cast<DT*>(*v)) ? _v : DT(0);
}
template <class PT, class DT> DT _setValue(PT* v, DT w)
{
	if (DT* _v = dynamic_cast<DT*>(*v)) {
		*_v = w;
	}
}
// ...
DLLFUNC var getDoubleContainer(void)
{
	return _makeContainer<var, double>(new int);
}
// ...

---