Datentyp/Konzept: viele Nachkommastellen



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



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

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

    Natürlich, aber XML hilft das Format zu definieren.

    Denn ich vermute dein Problem könnte durch ein sauber definiertes Format gelöst werden. Denn bisherige numerische Probleme konnte ich immer durch eine andere Darstellung (z.B. Grad (Winkel) -> Grad + Minute + Sekunde) lösen.

    Und später, wenn das Format steht, kann man ja noch alles in Binärformat übertragen.



  • Die großen Crypto CEXes wie Binance und Huobi verwenden JSON als Ausgabeformat, das ist etwas kompakter als XML. Ist das eine Option?



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

    @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!

    Mir gings um's Teilen. Das sollte beim Rechnen mit Geldbeträgen nicht auftreten, ohne dass eine Rest entsteht, Als Laie würde ich alles in Cent rechnen. +,-.* sind kein Problem, aber / schon. Naja, das Problem ist wohl so alt wie das Bankgewerbe.


  • Mod

    @Foulpelz sagte in Datentyp/Konzept: viele Nachkommastellen:

    @SeppJ sagte in Datentyp/Konzept: viele Nachkommastellen:

    @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!

    Mir gings um's Teilen. Das sollte beim Rechnen mit Geldbeträgen nicht auftreten, ohne dass eine Rest entsteht, Als Laie würde ich alles in Cent rechnen. +,-.* sind kein Problem, aber / schon. Naja, das Problem ist wohl so alt wie das Bankgewerbe.

    Häh? Nein? Du hast das Problem nicht im geringsten verstanden. Da die Erklärung schon da steht, spare ich mir weitere Versuche. Man muss sie nur lesen. Jedenfalls steht nichts dort, was zu deinem Kommentar passt.



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

    @Foulpelz sagte in Datentyp/Konzept: viele Nachkommastellen:

    @SeppJ sagte in Datentyp/Konzept: viele Nachkommastellen:

    @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!

    Mir gings um's Teilen. Das sollte beim Rechnen mit Geldbeträgen nicht auftreten, ohne dass eine Rest entsteht, Als Laie würde ich alles in Cent rechnen. +,-.* sind kein Problem, aber / schon. Naja, das Problem ist wohl so alt wie das Bankgewerbe.

    Häh? Nein? Du hast das Problem nicht im geringsten verstanden. Da die Erklärung schon da steht, spare ich mir weitere Versuche. Man muss sie nur lesen. Jedenfalls steht nichts dort, was zu deinem Kommentar passt.

    doch, doof ist zB, wenn einer 7€ durch 12 Monate teilen will. Dann haste nen Rest von 0,33333... Cent. Was macht man damit? Bekommt das die Bank?



  • Da hier wieder was Aktivität ist, wollte ich noch kurz ein paar (bisher glaube ich nicht erwähnte) Stichworte in den Raum werfen:

    IEEE 754 Decimal floating point von geeigneter Breite (via Library) vielleicht als Option zur Zahlenrepräsentation und sowas wie Protocol Buffers oder FlatBuffers, wenn eine kompaktere Alternative zu XML oder gar JSON als Austauschformat benötigt wird. Ob und was davon für deine Anforderungen brauchbar ist, musst du selbst entscheiden, @It0101.


Log in to reply