Berechnungsfehler

[Jens01]

Zitat:

Ergebnis: RohreProKreis = 3,79999995231628
Wie kommt es dazu? Das korrekte Ergebnis wäre 3,8

Ist doch richtig gerechnet!

Mache RohreProKreis := RoundTo(RohreProKreis, -2)
Man muss sich daran gewöhnen, dass nicht genau der erwartete Wert erscheint, sondern der ungefähr erwartete. Man benutzt eine Maschine zum Rechnen und die hat Tolerenzen. Die Toleranzen muß man bewerten und damit umgehen. Wie im Maschinenbau.
Spannend wird es erst, wenn Du Werte vergleichen willst. Sowas wie "if Wert = 0 then .."

[Lemmy]

Zitat von himitsu:

Wobei "Rundungsfehler" hier garnicht zu vermeiden sind, egal wie groß man den Fließkommadatentyp wählt.

Die Ursache dafür ist aber kein Rundungsfehler sondern eine Speicherungenauigkeit bei Fließkommawerten. Das sind 2 unterschiedliche Dinge und sollte man tunlichst nicht verwechseln.

Zitat von Jens01:

Mache RohreProKreis := RoundTo(RohreProKreis, -2)

ganz toll...
http://docwiki.embarcadero.com/Libra...m.Math.RoundTo

Du fütterst einen Extended rein, bekommst einen Extended raus. Ändert genau gar nichts. Ok, es mag seht oft ein gerundetes ERgebnis raus kommen, aber es gibt halt auch Werte die hier wieder mit dem Speicherfehler aus der Funktion kommen. (und ja: Ich hatte das Thema schon oft mit Entwicklern die vom Glauben abgefallen sind, weil bei RoundTo hin und wieder eben nicht der auf 2 Stellen genaue Wert raus kommt sondern was anderes).

Wenn Du RoundTo verwendest, dann solltest Du das ganze einem Currency zuweisen (wenn es dir wichtig ist mit genau 2 Nachkommastellen weiter zu rechnen)

[Jens01]

@Lemmy
Ja hast recht.
Gedanklich habe ich das aus Ausgabe bzw letztes Ergebnis angesehen:
StrRohreProKreis := RoundTo(RohreProKreis, -2).ToString

Wenn man es als Zwischenergebnis nutzt, würde ich eh mit dem Wert so weiterrechnen.
Bei technischen Berechnungen bringt dies Extended doch nichts. Ich nutze sogar bei FEM-Berechnungen Double-Werte.

[Lemmy]

Zitat von Jens01:

@Lemmy
Bei technischen Berechnungen bringt dies Extended doch nichts. Ich nutze sogar bei FEM-Berechnungen Double-Werte.

keine Frage... wenn Du mit Koordinaten zu tun hast, kommst Du daran nicht vorbei, weil die 4 Nachkommastellen vom Currency einfach zu wenig sind, wenn du mit 1.000 multiplizieren musst - da hast Du dann schon Fehler im Dezimeterbereich Es kommt halt immer darauf an...

[himitsu]

[QUOTE]Die Ursache dafür ist aber kein Rundungsfehler sondern eine Speicherungenauigkeit bei Fließkommawerten. Das sind 2 unterschiedliche Dinge und sollte man tunlichst nicht verwechseln.[QUOTE]
OK, aber wenn man es so sieht, dann wird es beim Speichern auf den nächsten Wert "gerundet", den der Typ speichern kann.

[matashen]

Auch mal kurz mein süßer Senf dazu

Es liegt einfach da dran das digital zum Beispiel kein drittel kennt und damit 0,3333333 speichert und irgendwann das "unendlich" fehlt (unendlich kennt dein System nicht). Bei weiteren Berechnungen treten eben hier Ungenauigkeiten auf. Das muss dann dein Code ausgleichen mit Runden an der passenden Stelle.

[Medium]

Und dem wäre noch hinzuzufügen, dass binär Perioden an anderen Stellen auftauchen als bei dezimal. Zum Beispiel ist 0,2 als Float niemals exakt darstellbar, da es immer in einer Periode mündet. Egal wie genau der Typ ist den man wählt.