AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Genauigkeit von Datentypen

Ein Thema von PaddyVII · begonnen am 25. Feb 2015 · letzter Beitrag vom 26. Feb 2015
Antwort Antwort
Seite 3 von 3     123   
mm1256

Registriert seit: 10. Feb 2014
Ort: Wackersdorf, Bayern
642 Beiträge
 
Delphi 10.1 Berlin Professional
 
#21

AW: Genauigkeit von Datentypen

  Alt 26. Feb 2015, 13:13
Muss?
Currency = 4 Nachkommastellen
....oooops....sorry. Verwende Currency nie und hatte was von 2 Nachkommastellen in Erinnerung
Gruss Otto PS: Sorry wenn ich manchmal banale Fragen stelle. Ich bin Hobby-Programmierer und nicht zu faul die SuFu zu benutzen
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#22

AW: Genauigkeit von Datentypen

  Alt 26. Feb 2015, 14:22
Muss?
Currency = 4 Nachkommastellen
....oooops....sorry. Verwende Currency nie und hatte was von 2 Nachkommastellen in Erinnerung
Es gibt Länder/Währungen da hat es mehr als 2 Nachkomma-Stellen und die wären ja hübsch angeschmiert. Von daher gab es bei der Definition des Datentyps eine gewisse Weitsicht und man hat dort 4 Stellen vorgesehen.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.071 Beiträge
 
Delphi 12 Athens
 
#23

AW: Genauigkeit von Datentypen

  Alt 26. Feb 2015, 14:44
Andere brauchen mit ihrem Quarter nur eine viertel Nachkommastelle.

Und dann noch bissl zum Rechnen, Positionsweise MwSt. usw.

Knapp 9 Billiarden Euro, auf einen tausenstel Euro genau ... da hätte man ruhig noch für ein/zwei Nachkommastellen mehr Platz gehabt.
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.

Geändert von himitsu (26. Feb 2015 um 14:49 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#24

AW: Genauigkeit von Datentypen

  Alt 26. Feb 2015, 15:28
Andere brauchen mit ihrem Quarter nur eine viertel Nachkommastelle.

Und dann noch bissl zum Rechnen, Positionsweise MwSt. usw.

Knapp 9 Billiarden Euro, auf einen tausenstel Euro genau ... da hätte man ruhig noch für ein/zwei Nachkommastellen mehr Platz gehabt.
Ich vermute mal, dass die Bedeutung des Datentyps Currency etwas verkannt/nicht erkannt wird.

Das ist ein Datentyp für eine Währungs-Buchung. Und ich kenne niemanden, der seine Buchhaltung auf Mikro-Cent führt. Während einer Berechnung eines Buchwertes da nimmt man diese Mikro-Cents mit, aber irgendwann kommt ein Buchwert heraus und der ist dann im EURO-Raum auf 2 Stellen nach dem Komma gerundet (ohne jetzt auf die speziellen Rundung-Arten eingehen zu wollen).

Bei einer Rechnung z.B. erfolgt die Festlegung des Buchwerts auf Positions-Ebene. Jede Position hat also einen festgelegten Buchwert und der ist dann vom Typ Currency .

ArtikelPreisMengeBerechneter-WertBuch-Wert
Gold1214,15($/oz.tr.)1(g)1214,15($/oz.tr.) / 31,1034768(g/oz.tr.) * 1(g) = 39,035828946299663($)39,04($)
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)

Geändert von Sir Rufo (26. Feb 2015 um 22:50 Uhr)
  Mit Zitat antworten Zitat
mensch72

Registriert seit: 6. Feb 2008
838 Beiträge
 
#25

AW: Genauigkeit von Datentypen

  Alt 26. Feb 2015, 21:47
Für Anwendungen im Börsenumfeld, wo es durchaus Kurse/Preise auf 8! Nachkommastellen genau gibt, wenn es was mit YEN oder in "1/128" gestuften US Werten zu tun hat...

Wir verwenden dafür einen eigenen 64Bit "FixComma" Datentyp mit 9! Nachkommastellen, welcher Summen und Differenzen absolut rundungsfehlerfrei in Int64 rechnet. Auch speichern wir in dieser Anwendung nur solche Ganzzahl-Int64-Zahlen in Files/Tabellen.

Das Grundprinzip ist simpel: alle Werte sind quasi mit 1'000'000'000 multipliziert und man schafft so alles bis +/- 9'223'372'036','854'775'808 in einem Int64 ganzzahlig unterzubringen.

- Da Delphi ja überladene Operatoren unterstützt, haben wir uns so unseren Eigenen Datentyp auch mit den passenden Funktionen versehen, damit wir ohne Genauigkeitsverlust durch Typumwandlungen auch direkt damit rechnen können und vergleichen können... 11mal -0,11 von 1,21 abgezogen ergibt da wirklich =0
- Per "AsString" als Read/Write Property haben wir auch quasi ein eigenes "FixCommaToStr" bzw. "StrToFixComma" gleich mit eingebaut
- für "Single", "Double" & "Extended" haben wir per eigener impliziter Typumwandlung gleich die passende Epsilon-Rundung eingebaut, um bei "krummen" Eingangswerten die eigentlich gemeinte Zahl zu bestimmen
- für 32Bit Delphi haben wir per Inline-ASM und Coprozessornutzung eine sehr schnelle 128Bit genaue Multiplikation/Division realisiert, weil man da jeweils ein um Faktor 1'000'000'000 falsches Resultat bekommt was sich nur mit 128Bit Ganzzahlgenauigkeit völlig rundungsfehlerfrei berechnen lässt

Der "Zauber" sind einige 100 Quelltextzeilen, aber wenn man sich daran gewöhnt hat mit Kommazahlen ganz normal zu rechnen und zu vergleichen, dann will man es nicht mehr missen.
Egal welche Programmiersprache, ohne eigene selbst geprüfte Routinen/Operationen für Kommazahlen und Datum/Zeit mag ich vor allem im Finanzbereich nicht mehr arbeiten.
Der vorhandene Currency-Type konnte uns nicht überzeugen. Standardlösungen für beliebig "große" Zahlen schieden wegen der Verarbeitungsgeschwindigkeit aus.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 3 von 3     123   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:30 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz