Fehler in den Funktionen StrToFloat und FloatToStr

[Euklid]

... und dieser lässt sich sehr einfach reproduzieren.

Code: Alles auswählen

s:=FloatToStr(-0.000000000000001/10);

Ergibt für s='-0' statt '-1E-16'.

Wenn man das gleich mit positivem Vorzeichen probiert:

Code: Alles auswählen

s:=FloatToStr(0.000000000000001/10);

erhält man korrekt s='1E-16'

Habe diesen Bug bereits dem Bugtracker hinzugefügt: http://www.freepascal.org/mantis/view.php?id=8747" onclick="window.open(this.href);return false;

[monta]

Liegt das nicht an der Zahl der signifkanten Ziffern eines Doubles? Zumindets sind das ja 15 bzw. 16

Somit wäre die negative Zahl zu lang und würde , da sie über die 15 hinaus geht auf 0 gerundet, weil die 16. Stelle nicht mehr verarbeitet wird.
Ich glaub fast, das ist also kein Bug, sondern liegt an der Länge, aber wozu brauch man das?...die Physiker wieder

[Euklid]

Stimmt, das könnte durchaus damit zusammenhängen. Nehme aber trotzdem an, dass es ein Bug ist:

Code: Alles auswählen

s%u3a=FloatToStr%u28-0.000000000000001/1000%u29;

ergibt nämlich auch s='-0', während das ganze mit positivem Vorzeichen '1E-18' ergibt.

Bei der neusten Version Lexarts tritt ein Fehler auf, der zum Abbruch führt, wenn man die Funktion sin(1/x^2) im maximierten Fenster zeichnet. Nach 1,5-stündiger Suche kam ich zum Schluss, dass dies kein Fehler in unseren Quelltext ist, sondern eben dieses Verhalten der FloatToStr *grr*

Denn Lexart interpretiert dieses '-' vor der Null falsch und macht dann Syntaxfehler.

Naja, habe das Problem provisorisch mit einem Workaround gelöst....

Viele Grüße, Alexander

[monta]

Ah, ist im Bugtracker ja schon erledigt, kann ich auch bestätigen.

Ich hab auch FPC2.1.3 und da ging es gerade.

[schnullerbacke]

Da hat @monta Recht,

das liegt aber noch an einem weiteren Problem. Bei der Umwandlung von Reals beliebigen Typs in einen String wird ab einer bestimmten vom Realtyp vorgegebener Stelle einfach abgeschnitten. Dadurch entfällt dann an dieser Stelle der Wert 0 und damit wird das Ergebnis = 0. Das hat erkennbar keinen Exponenten zur Basis 10 mehr und du bekommst eben -0 zurück, was für sich schon falsch ist. -0 gibt es nämlich nicht.

Wenn du das genau haben willst, bleibt dir nur die Faktorisierung und spätere Umwandlung in einen String. Und @monta, das stört eigentlich die Kaufleute weit mehr, da gehen dann nämlich schnell mal beim Runden kleine Zinsbruchstücke verloren, das mögen die nicht so gerne. Und wenn man sich Euklids Beispiel ansieht, dann sind das ja nun nicht so furchtbar viele NK-Stellen, das sollte eigentlich problemlos klappen, die -0 deutet das ja auch an. Nur die FloatToStr kann da also die schuldige sein.

@Euklid

Sicherer ist das mit FormatStr() zu machen, dort kannst du die Stellenzahl und die Darstellungsart als Parameter angeben. Der oben gezeigte Fehler tritt dann zumindest sehr viel später auf.

[monta]

Kaufleute müssen also auch die 2.1.3 nehmen, obwohl ich das praktisch finde, wenn ich den Zins zahlen muss

[Euklid]

Ah, ist im Bugtracker ja schon erledigt, kann ich auch bestätigen.

Ich hab auch FPC2.1.3 und da ging es gerade.

Mann, was sind die fix. Läuft der FPC 2.1.3 ähnlich stabil, wie der 2.0.4? Ein Umstieg wäre dann eine Überlegung wert.

[monta]

Also ich arbeite seit etlichen tagen mit FPC 2.1.3 in Kombination mit Laz 0.9.22 und das ganze läuft super.

Hatte eigentlich nen 23er-Snapshot installiert, der aber rumzickte und partout nicht wollte. Dann hab ich die 22er von Laz aus dem SVN drüber gepackt, weil ich den neuen FPC behalten wollte und in den stabilen Snapshots ja nur der FPC 2.0 ist.
Seit dem hab ich keinerlai Probleme und es läuft bestens.

Muss allerdings dazusagen, dass ich das leider nur für Win sagen kann. Bei Suse hab ich noch den 2.0er.

[schnullerbacke]

Wo hast du denn den 22er SVN her, ich find das Dings immer nicht?

[monta]

Von:

Code: Alles auswählen

http://svn.freepascal.org/svn/lazarus/tags/lazarus_0_9_22" onclick="window.open(this.href);return false;

und hinten einfach die Versionsnummer austauschen bei Bedarf.

[Christian]

Das -0 nicht existiert ist Quatsch rein Technisch existiert es Kaufmännisch muss man das mitbehandeln. Wurde auf der FPC Mailingliste mal richtig breitgetreten fragt mich jetzt aber nicht nach details da müsst ihr selber nachlesen. Glaub es ging sogar um das selbe Thema kann sein das der Patch in 3 Tagen wieder draussen ist.

[Euklid]

Das -0 nicht existiert ist Quatsch rein Technisch existiert es Kaufmännisch muss man das mitbehandeln.

Kenne mich nur ein bisschen in der Mathematik aus, da ist definiert: Eine Zahl ist negativ, wenn sie kleiner 0 ist.

Wurde auf der FPC Mailingliste mal richtig breitgetreten fragt mich jetzt aber nicht nach details da müsst ihr selber nachlesen. Glaub es ging sogar um das selbe Thema kann sein das der Patch in 3 Tagen wieder draussen ist.

Naja, dann macht die FloatToStr aber massive Rundungsfehler, wenn sie -1E-16 zu -0 aufrundet...
... wäre dann unlogisch, dass sie 1E-16 nicht zu 0 abrundet.

[schnullerbacke]

@Euklid

Eben, FloatToStr ist nicht wirklich geeignet wenn es genau sein soll. FormatStr wurde deswegen bei TP 6.0 meine ich eingeführt. Bei dieser Funktion wird die Umwandlung durch Faktorisierung gemacht, was erheblich größere NK-Stellen zulässt. Selbst beim normalen real sollten über 300 NK-Stellen möglich sein, wie dein Beispiel zeigt, stimmt das aber für FloatToStr nicht. Die -0 entsteht dadurch, daß das Sign-Flak entsprechend gesetzt ist. Das sind eben die kleinen Macken der schönen Computer-Welt.

@Christian

-0 gibt es in der Mathematik eindeutig nicht, man kann sich gemäß der Infinitesimalrechnung der Null lediglich von den negativen oder positiven Zahlen aus nähern, 0 bleibt aber 0. So gibt es auch nur eine Definition der ganzen Zahlen:

G = {x| x 0}
(gelesen: G ist die Menge aller x für die gilt (|) x 0)

Sonst müßte es heißen x <= -0. Alle anderen Betrachtungen sind Unfug und mathematischer "Lötzinn".

[Christian]

@Schnuller
lies dir durch was ich schreibe dann brauchst du es nicht nochmal wiederholen und mich fälschlicherweise korrigieren.