Datentyp/Konzept: viele Nachkommastellen
-
@SeppJ sagte in Datentyp/Konzept: viele Nachkommastellen:
Gibt es da im professionellen Finanzumfeld nicht irgendwelche Regeln, Gesetze, oder Normen, nach denen gerechnet (Rundungsregeln!) werden muss?
Das kommt auch darauf an, was für ein Finanzumfeld das denn genau ist. Wenn du z.B. selbst (High Frequency?) Trader bist und deine Software dich bzw. deine Firma beim Kaufen/Verkaufen beraten soll (oder den Trade gleich durchführen soll), dann brauchst du da keine Rechenregeln zu beachten (wohl aber natürlich andere Regeln wie z.B. dass bestimmte Handelsstrategien nicht zulässig sind -- und dass dir die Börsen auch gerne mal fehlerhafte Daten liefern, Regeln hin oder her; habe ich mir jedenfalls sagen lassen). Rundungsregeln klingen eher nach Bankenumfeld. Aber nichts genaues weiß ich auch nicht
und insbesondere nichts zum Problem von @It0101.
-
@SeppJ sagte in Datentyp/Konzept: viele Nachkommastellen:
Gibt es da im professionellen Finanzumfeld nicht irgendwelche Regeln, Gesetze, oder Normen, nach denen gerechnet (Rundungsregeln!) werden muss? Ich dachte immer, dass das der Grund ist, dass dort noch die BCD und dessen Nachfolger/Varianten leben. Wir können dir da keine Rechtsberatung geben, müsstest du so etwas nicht selber wissen? Jedenfalls was die Anforderungen angeht, über die programmatische Umsetzung können wir dich dann beraten.
Es gibt in der Konten/Depotführung/Abwicklung tatsächlich genaue Regeln, wie gerechnet werden muss. Das ist aber nicht der Bereich in dem ich arbeite. Ich bin in der Kursinfrastruktur beschäftigt, d.h. ich beschaffe Kurse von externen Anbietern und stelle sie firmenintern für diverse Clients zur Verfügung. Was die dann damit machen ist mir rille, aber die Daten dienen den verschiedensten Zwecken. Ich bin also keinen Regeln unterworfen, muss nur lediglich sicherstellen, dass alles schnell sein Ziel erreicht und dabei keine Daten verloren gehen.
Und wenn ich alles lasse wie bisher mit wenigen NKS und dann BitCoins transportiere, dann werde ich vermutlich hauptsächlich gerundete Nullen transportieren, daher schaue ich mich bereits jetzt nach Konzepten um, wie man sowas exotisches lagern und transportieren kann.
-
@It0101 sagte in Datentyp/Konzept: viele Nachkommastellen:
Ich bin in der Kursinfrastruktur beschäftigt, d.h. ich beschaffe Kurse von externen Anbietern und stelle sie firmenintern für diverse Clients zur Verfügung.
Gehe ich dann recht in der Annahme, dass du hierfür eine Datenbank ala MongoDB nutzt?
Wenn ja, wie sieht das Schema aus? Genauer, welcher Datentyp wird für die Kursdaten (Low, High, Open, Close, Volume,..) benutzt? Und welche Einheiten haben diese?
Und wie sieht das Ganze auf der Datenfeed-Seite aus?
-
@Quiche-Lorraine sagte in Datentyp/Konzept: viele Nachkommastellen:
@It0101 sagte in Datentyp/Konzept: viele Nachkommastellen:
Ich bin in der Kursinfrastruktur beschäftigt, d.h. ich beschaffe Kurse von externen Anbietern und stelle sie firmenintern für diverse Clients zur Verfügung.
Gehe ich dann recht in der Annahme, dass du hierfür eine Datenbank ala MongoDB nutzt?
Nein. Es ist Realtime. Keine Datenbanken.
Und wie sieht das Ganze auf der Datenfeed-Seite aus?
Jedes mal anders. Es gibt unterschiedliche Anbieter, die unterschiedliche Protokolle verwenden. An den Stellen gäbe es dann auch noch Anpassungsbedarf sobald ich mir eine Lösung für die NKS überlegt habe. Logischerweise müssen wir das Konzept dann auf allen Feeds einsetzen, egal von der jeweiligen Datenquelle nur maximal 4NKS kommen oder 18NKS.
-
@It0101 sagte in Datentyp/Konzept: viele Nachkommastellen:
Jedes mal anders. Es gibt unterschiedliche Anbieter, die unterschiedliche Protokolle verwenden. An den Stellen gäbe es dann auch noch Anpassungsbedarf sobald ich mir eine Lösung für die NKS überlegt habe. Logischerweise müssen wir das Konzept dann auf allen Feeds einsetzen, egal von der jeweiligen Datenquelle nur maximal 4NKS kommen oder 18NKS.
Wo ist eigentlich dein numerisches Problem? Welcher Feed liefert 18 Nachkommastellen?
Musst du Kursdaten in der Einheit X in die intern verwendete Einheit umrechnen? Zum Beispiel: Yen in US-Dollar?
Hast du ein Problem mit der Umrechnung bei Währungen mit Hyperinflation?
-
Auf den meisten Plattformen ist
sizeof(double) == sizeof(long double), das betrifft mittlerweile auch Intel, da die 80387 FPU nicht mehr genutzt wird, und stattdessen SSE bzw. AVX genutzt wird. Was es gibt sind Softwarelösungen für quadprecision, die dann zum Teil mit dem Datentyplong doubleaktiviert werden. Die einzige Plattform, die quadprecision in Hardware konnte war HP-PA. Allerdings sind Floats immer problematisch, weil sie für Währungen nicht der beste Datentyp ist.Nachtrag:
Damit man besser weiß um was es geht die üblichen Definitionen in einem x86-64 Compiler. In diesem Fall hier istlong doubledas x87 Extended FP-Format.__float128ist eine Softfloat Implementierung durch die libquadmath.float double long double __float128 sizeof 4 8 16 16 binary digits mantissa 24 53 64 113 decimal digits mantissa 6 15 18 33 minimum exponent -125 -1021 -16381 -16381 maximum exponent 128 1024 16384 16384 minimum 10 exponent -37 -307 -4931 -4931 maximum 10 exponent 38 308 4932 4932 minimum 1.175e-38 2.225e-308 3.362e-4932 3.362-4932 maximum 3.403e+38 1.798+308 1.190e+4932 1.190e+4932 epsilon 1.192e-07 2.220e-16 1.084e-19 1.926e-34 Wie Du sehen kannst, würde x87 FPU Code gegenüber
doublenicht viel bringen, da die Matisse nur 3 Dezimalstellen länger ist. Wirklich sinnvoll wäre nur das quadprecision Format.
-
@It0101 sagte in Datentyp/Konzept: viele Nachkommastellen:
ich muss mich zeitnah mit dem Thema 20 Nachkommastellen ( provokant formuliert ), wegen Arbeit mit Kryptowährungen ( z.B. Bitcoin ) auseinandersetzen. Die Werte des Bitcoin sind zwar in einem üblichen Zahlenbereich, die Mengen/Volumen sind aber aktuell und auch zukünftig sehr sehr klein und somit muss die Anzahl der Nachkommastellen sehr hoch sein. 20 ist sicherlich übertrieben, aber in die Richtung soll es bei mir gehen.
Java hat Big Decimal mit konfigurierbarer Anzahl an Nachkommastellen. Sowas gibt es bestimmt auch für C++. Schau dich mal dort um: https://stackoverflow.com/questions/4798777/is-there-a-c-equivalent-to-javas-bigdecimal
-
Aber wie schon gesagt: All die Fließkommatypen sind so gar nicht auf Rechnungen mit diskreten Geldbeträgen ausgelegt. Die sind darauf ausgelegt, dass man damit sinnvoll Werte über 600 Größenordnungen hinweg im gleichen Programm benutzen kann und das Ergebnis "so ungefähr" passt, wobei "so ungefähr" im Sinne des wissenschaftlichen Rechnens zu verstehen ist. Und das auch nur, solange man sich mit Numerik auskennt.
-
Ist das Ganze nicht eher ein Thema für Fixed Floating Point? Dafür gibt es doch die MPFR Library.
-
@SeppJ sagte in Datentyp/Konzept: viele Nachkommastellen:
Aber wie schon gesagt: All die Fließkommatypen sind so gar nicht auf Rechnungen mit diskreten Geldbeträgen ausgelegt. Die sind darauf ausgelegt, dass man damit sinnvoll Werte über 600 Größenordnungen hinweg im gleichen Programm benutzen kann und das Ergebnis "so ungefähr" passt, wobei "so ungefähr" im Sinne des wissenschaftlichen Rechnens zu verstehen ist. Und das auch nur, solange man sich mit Numerik auskennt.
Bei den üblichen Rechnereien mit Geldbeträgen wird doch nur addiert und subtrahiert bzw. Prozentrechnung verwendet. Also ne Division, bei der irrationale Zahlen auftreten können, kommt normalerweise nicht vor, oder? Wäre ja auch doof. Wer bezahlt den Rundungsfehler?
-
@Foulpelz sagte in Datentyp/Konzept: viele Nachkommastellen:
@SeppJ sagte in Datentyp/Konzept: viele Nachkommastellen:
Aber wie schon gesagt: All die Fließkommatypen sind so gar nicht auf Rechnungen mit diskreten Geldbeträgen ausgelegt. Die sind darauf ausgelegt, dass man damit sinnvoll Werte über 600 Größenordnungen hinweg im gleichen Programm benutzen kann und das Ergebnis "so ungefähr" passt, wobei "so ungefähr" im Sinne des wissenschaftlichen Rechnens zu verstehen ist. Und das auch nur, solange man sich mit Numerik auskennt.
Bei den üblichen Rechnereien mit Geldbeträgen wird doch nur addiert und subtrahiert bzw. Prozentrechnung verwendet. Also ne Division, bei der irrationale Zahlen auftreten können, kommt normalerweise nicht vor, oder? Wäre ja auch doof. Wer bezahlt den Rundungsfehler?
Weiß ich halt nicht, was It0101 vor hat. Aber auch mit vermeintlich einfachen Rechnungen kann man überraschende Ergebnisse bekommen. Zum Beispiel wenn 0.1 + 0.1 - 0.2 nicht gleich 0 ist.
-
@Foulpelz sagte in Datentyp/Konzept: viele Nachkommastellen:
Bei den üblichen Rechnereien mit Geldbeträgen wird doch nur addiert und subtrahiert bzw. Prozentrechnung verwendet.
Im Bereich von Aktien sucht man auch nach Einstiegssignalen, also den Zeitpunkt ab welchem man einsteigen soll und wie man einsteigen soll.
Hierfür gibts eine Reihe von Indikatoren. So gibt es den SMA, einen gleitenden Mittelwert oder auch den EMA, einen exponentiell gleitenden Mittelwert.
-
@SeppJ sagte in Datentyp/Konzept: viele Nachkommastellen:
Weiß ich halt nicht, was It0101 vor hat. Aber auch mit vermeintlich einfachen Rechnungen kann man überraschende Ergebnisse bekommen. Zum Beispiel wenn 0.1 + 0.1 - 0.2 nicht gleich 0 ist.
Das ist jetzt gerade keines meiner Probleme aber durchaus eines in der Finanzwirtschaft. Z.B. beim Nulldurchgang, bzw. beim exakten erreichen von 0 ( Stücken im Depot ).
-
@Foulpelz sagte in Datentyp/Konzept: viele Nachkommastellen:
Also ne Division, bei der irrationale Zahlen auftreten können, kommt normalerweise nicht vor, oder?
Hä? Bei einer Division von rationalen Zahlen kommen auch wieder rationale Zahlen raus. Irrationale Zahlen bekommt du z.B. beim Wurzelziehen, wenn die Wurzel nicht aufgeht. Oder wenn du eine irrationale Zahl durch rationale Zahl teilst.
@It0101 willst du die Werte nur intern weiterleiten oder auch damit wie auch immer geartet "rechnen"?
-
@wob sagte in Datentyp/Konzept: viele Nachkommastellen:
Hä? Bei einer Division von rationalen Zahlen kommen auch wieder rationale Zahlen raus.
Ich kündige meine Konten immer zu Zeitpunkten, die ein vielfaches von Pi sind. Die Zinsberechnungen, die da losgetreten werden, sind meine Variante von Bobby Tables... SCNR
-
@wob sagte in Datentyp/Konzept: viele Nachkommastellen:
@Foulpelz sagte in Datentyp/Konzept: viele Nachkommastellen:
Also ne Division, bei der irrationale Zahlen auftreten können, kommt normalerweise nicht vor, oder?
Hä? Bei einer Division von rationalen Zahlen kommen auch wieder rationale Zahlen raus. Irrationale Zahlen bekommt du z.B. beim Wurzelziehen, wenn die Wurzel nicht aufgeht. Oder wenn du eine irrationale Zahl durch rationale Zahl teilst.
@It0101 willst du die Werte nur intern weiterleiten oder auch damit wie auch immer geartet "rechnen"?
Irrational war der falsche Begriff. Ich meine sowas wie 1/3, das unendlich viele Nachkommastellen hat.
-
@Foulpelz sagte in Datentyp/Konzept: viele Nachkommastellen:
@wob sagte in Datentyp/Konzept: viele Nachkommastellen:
@Foulpelz sagte in Datentyp/Konzept: viele Nachkommastellen:
Also ne Division, bei der irrationale Zahlen auftreten können, kommt normalerweise nicht vor, oder?
Hä? Bei einer Division von rationalen Zahlen kommen auch wieder rationale Zahlen raus. Irrationale Zahlen bekommt du z.B. beim Wurzelziehen, wenn die Wurzel nicht aufgeht. Oder wenn du eine irrationale Zahl durch rationale Zahl teilst.
@It0101 willst du die Werte nur intern weiterleiten oder auch damit wie auch immer geartet "rechnen"?
Irrational war der falsche Begriff. Ich meine sowas wie 1/3, das unendlich viele Nachkommastellen hat.
Du liegst so richtig und doch so daneben. Das Problem liegt doch gerade darin, dass Geldbeträge im Dezimalsystem angegeben werden, aber viele endliche Dezimalzahlen im binären System unendliche Brüche sind. 0.1 ist im Binärsystem etwas, das auf 0b1100-Periode endet. Was dann eben gerundet werden muss, weil man nicht unendlich viele Stellen speichern kann, und daher ungleich 0.1 ist. Schlimmer: Der Rundungsfehler hängt dann auch noch von den genauen Interna des gewählten Datentypen ab!
Dazu braucht 0.1 nicht das Ergebnis einer Rechnung zu sein!
-
@wob sagte in Datentyp/Konzept: viele Nachkommastellen:
@It0101 willst du die Werte nur intern weiterleiten oder auch damit wie auch immer geartet "rechnen"?
Ich selbst bin nur der "Transporter". Ich muss die werte von diversen Lieferanten entgegennehmen und dann weitertransportieren. Diverse Clients rechnen aber auch mit den Werten, das unterliegt aber nicht mehr meiner Verantwortung
-
@It0101: Dann verstehe ich nicht, warum du überhaupt einen Datentyp bzgl. der Nachkommastellen benötigst, weil doch ein Byte-Array (beliebiger Größe) ausreichen würde, also
vector<uint8_t>.
Es kommt dann eher darauf an, welche Datentypen du von den Lieferanten bekommst und wie du sie weitertransportieren mußt, d.h. ob du selber Umrechnungen durchführen mußt (was aber dann auch eine Berechnung wäre!).Vllt. wäre mal ein konkretes Beispiel sinnvoll?!
-
@Th69 sagte in Datentyp/Konzept: viele Nachkommastellen:
@It0101: Dann verstehe ich nicht, warum du überhaupt einen Datentyp bzgl. der Nachkommastellen benötigst, weil doch ein Byte-Array (beliebiger Größe) ausreichen würde, also
vector<uint8_t>.
Es kommt dann eher darauf an, welche Datentypen du von den Lieferanten bekommst und wie du sie weitertransportieren mußt, d.h. ob du selber Umrechnungen durchführen mußt (was aber dann auch eine Berechnung wäre!).Vllt. wäre mal ein konkretes Beispiel sinnvoll?!
Naja ich muss unterschiedlichste Codierungen unserer Datenquellen auf ein einheitliches Format vereinigen. D.h. ich muss die Eingangsformate konvertieren, auf irgendwas noch zu bestimmendes. Ich tendiere, genau wie du, aktuell zu einem 8Bit * n-Datenblock. Das hätte den Vorteil dass man im späteren Verlauf die Codierung noch ändern kann und dass sie so in der Form auch konvertierungslos über Sockets weitergetragen werden kann. Jedoch habe ich mich noch nicht entschieden, in welcher Form die Eingangsdaten in das uint8-Array codiert werden und darum geht's mir im eigentlichen.
Wir bekommen Daten in folgender Form:
- Dezimal als String ( also z.B. "18.93" )
- Dezimal, als Mantisse-Exponenten-Darstellung, sprich ein int64_t und ein uint_32t
