Datentyp/Konzept: viele Nachkommastellen



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



  • @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.


  • Mod

    @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


  • Puh....
    Ich glaube, ich würde mir die Arbeit nicht machen und das einfach als string verpacken. Wenn ihr euch auf das EN-US Format einigen könnt (mit Punkt als Dezimaltrenner) bist du doch beliebig genau. Oder man kann bei der Anfrage angeben, in welchem Format man die Antwortet erwartet, dann seid ihr immer auf der sicheren Seite.



  • @It0101
    Ist dein Problem eher ein Ausgabeformat-Problem?

    Ein XML Gedanke: Warum nicht die Daten an deine Clients folgendermaßen weiterleiten?

    <rates name="BMW" timebase="Day" unit="euro" ref_unit="Dollar" ref_conv="YYY"/>
      <rate date="XXXX" low="XXX" high="XXX" open="XXX" close="XXX" vol="XXX"/>
    </rates>
    

    Unter den Elementen "rate" stehen alle von dir eingelesen Rohdaten. Unter dem Attribut "ref_unit" die Referenzwährung und unter "ref_conv" dein aktueller Umrechnungsfaktor.

    Keine Konvertierung notwendig, außer vielleicht bei Attribut date, sofern man es benötigt.



  • @Quiche-Lorraine
    Der Grundgedanke ist gut, aber bei 2Mio Wertpapieren wäre das eine XML-Datei, die sogar der Höllenfürst noch fürchtet. aber wie gesagt: Der Grundgedanke, dem Client Context-Informationen zum Wertpapier mitzugeben, ist nicht so verrückt. Zumindest als einmalig Info ( daily oder so ). Nur in dieser Overheadigkeit von XML sicherlich nicht so gut zu verschmerzen. 🙂

    Bei im Schnitt 200.000 Update/sec (overall) verbietet sich das aber in meinem Fall jegliche Contextinformationen an ein Update zu hängen.


Anmelden zum Antworten