Datentyp/Konzept: viele Nachkommastellen



  • Hallo zusammen

    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.

    Das bedeutet, dass ich das interne Konzept meines Servers überdenken muss, denn allein auf "double" für den Transport von Daten kann ich nicht mehr vertrauen. Nun gibt es aus meiner Sicht zwei Möglichkeiten:

    1. Verwendung von (long) long double
    2. Verwendung eines eigenen Datentypen zur Abbildung von Mantisse und Exponent, oder ähnlichen Konzepten.
    3. Verwendung von Strings ( zum Transport/Speichern)

    Wie steht ihr dazu? Ich habe weder mit dem einen, noch mit dem anderen Konzept hinreichende Erfahrungen. Das Konzept der ausschließlichen Arbeit mit ganzen Zahlen finde ich aber durchaus interessant. Wobei wir nicht wirklich viel rechnen, sondern die Daten hauptsächlich transportieren.

    gruß Tobi


  • Mod

    Du musst zuallererst deine eigenen Anforderungen genau formulieren, anstatt Lösungsansätze in den Raum zu werfen, die vielleicht gar nicht zu deinen Anforderungen passen. Beispielsweise ist das Modell der Zahlendarstellung mit Mantisse und Exponent in erster Linie dazu da, im Computer so eine Art Zahlenkontinuum darzustellen. Das wäre aber eine sehr ungewöhnliche Anforderung, wenn es um das Rechnen mit Geldbeträgen geht, wo man es normalerweise mit exakten, diskreten Werten zu tun hat. Höchstwahrscheinlich sind deine Ansätze 1 und 2 also vollkommen untauglich für die Problemstellung, egal wie viele Stellen man nutzt.

    Daher: Was sind deine genauen Anforderungen? Und hast du dir diese genau überlegt? 20 Stellen Genauigkeit für Größen aus der Realwelt klingt unwissenschaftlich. Die genauest bekannten Dinge auf der Welt, sind auf ca. 15 Stellen bekannt. Ebenso gibt es ca. 10^15 Satoshis, die kleinste Bitcoineinheit. Wo also kommen noch 5 zusätzliche Größenordnungen her?



  • Auf der ETH Chain werden uint256 als Datentyp verwendet, dazu kommt dann die Definition der Nachkommastellen. Da sind, je nach Token, 18 Nachkommastellen gängig.



  • @It0101 sagte in Datentyp/Konzept: viele Nachkommastellen:

    wegen Arbeit mit Kryptowährungen

    Warum rechnest du nicht mit Satoshis?

    Und wenn du größere Bereiche benötigst, dann könntest du auch die CryptoPP Integer Class nutzen.

    Pass aber auf dass du nicht mit Kanonen auf Spatzen schießt.

    PS:
    Unter Visual Studio gilt: (long) long double = double



  • Haltet euch bitte nicht an der 20 so fest. Das war nur provokant in den Raum geworfen. Wir arbeiten stand heute im Börsenumfeld mit 6 NKS ( bei der Kursinfrastruktur ). Nur wird das eben für die Zukunft nicht ausreichen, daher wollen wir vorsorgen und jetzt im Zuge der Neuentwicklung unseres wichtigsten Servers gleich mit berücksichtigen, dass mehr NKS bald ein Thema werden können.

    Mit Satoshis kann ich vermutlich nicht arbeiten, weil wir eben nicht NUR Bitcoin-Tickdaten transportieren (werden) sondern hauptsächlich natürlich den ganzen normalen Aktien/Fonds/Derivate-Kram. Ich will nur eben eine Lösung, die beides halbwegs elegant ( und performant ) abbilden kann.


  • Mod

    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.

    PS: BCD ist natürlich ein googlebares Stichwort, falls dir das echt nichts sagen sollte. Vielleicht ist das aber mittlerweile auch zu veraltet und man nutzt jetzt DPD und ähnliches, oder halt normale Integers, mit einer (mir unbekannten aber gewiss gesetzlich geregelten) Subcenteinheit.



  • @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 Datentyp long double aktiviert 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 ist long double das x87 Extended FP-Format. __float128 ist 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 double nicht 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


  • Mod

    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?


  • Mod

    @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"?


Log in to reply