Große Zahlen in Arma

  • Hey, ich bins mal wieder.

    Ich möchte gerne große Zahlen nutzen. Allerdings werden die nach 7 Stellen ungenau.
    Hat jemand eine Idee wie die Genauigkeit erhöht werden kann?

    In SQF? Geht nicht. Aber wozu? Vlt. geht was du willst ja anders.

    Es geht darum, die Statistiken von Spielern, aber auch ID´s in der Datenbank zu speichern und wieder auszulesen. Zusätzlich sollen diese auch in Arma einsehbar sein.
    Wenn man aus einer großen Zahl einen String macht um diesen darzustellen, wird leider die Zahl anders dargestellt (z.B. "1.23457e+006").


    Die Genauigkeit ist vorallem für die ID´s notwendig, da ansonsten die Einträge nicht klar zugeordnet werden können (wobei ich mir dafür möglicherweiße eine Lösung überlegt habe).
    Bei den Statistiken wäre es schade wenn diese ungenau sind.


    Eine Möglichkeit die ich sehe, ist die Zahl als String zu behandeln, den String in Abschnitte zu teilen, mit denen Arma wieder umgehen kann und diese Abschnitte in Zahlen zu wandeln.
    Oder die Abschnitte gleich als mehrere Spalten in der Datenbank speichern.


    Mit diesen kleineren Zahlen kann man wieder rechnen und muss nur bei einem Übertrag aufpassen.


    Außer euch fällt noch eine Lösung ein, die einfach er ist.


    Gruß

  • @Henne Wo kommen diese IDs denn her und warum brauchst du mehr als 10 Millionen? Soviele Spieler gibt es doch gar nicht. Und könnte man stattdessen nicht generell Strings benutzen, welche dann auch Buchstaben enthalten und daher nicht allzu lang werden?


    @vPzBtl33_Bix Der SQF und Konfig NUMBER Typ ist intern im Single floating point-Format. Es gibt immer nur 7 exakte signifikante Stellen. Wo das Komma ist, ist dabei eher egal. Man kann also 1234567 darstellen, oder 123,4567 oder 0,1234567, aber nicht 12345,12345.

  • @Henne da es so klingt als ob du eh schon planst eine extension zu nutzten warum nicht einfach gewisse werte nur dort tracken bzw behandeln und dann nur als string nach arma zurück geben bzw in arma nur als string anzeigen damit sollte man ansich keine probleme haben

  • Also wenn ich die Aussage

    Wenn man aus einer großen Zahl einen String macht um diesen darzustellen, wird leider die Zahl anders dargestellt (z.B. "1.23457e+006").

    richtig verstehe, geht es hier nicht um die Genauigkeit der Zahlen, sondern darum dass Arma die Zahlen ab einer bestimmten Größe in wissenschaftlicher Schreibweise darstellt. Ist das korrekt?


    Falls ja sollte man sich mit sowas hier hier helfen können:


    Der Code ist nicht getestet, sollte aber theoretisch funktionieren :11_unknown:

  • @Raven Das hilft hier aber auch nicht, denn selbst wenn die großen Zahlen ohne diese Exponentennotation dargestellt werden, rundet Arma trotzdem. Dann hat auf einmal als Input eine Zahl und ihr Nachfolger den gleichen Wert als Output. Das ist dann alles aber keine eindeutige Id mehr.
    Da könnte er ja gleich den toFixed-Befehl nutzen.


    Edit2:
    z.B:

    Code
    1. 10000000000 == 10000000001 // true
    2. 10000000000 toFixed 0 // "10000000000"
    3. 10000000001 toFixed 0 // "10000000000" [!]
  • Hallo Zusammen.


    Ich bin jetzt kein großter Arma-Scripter, aber wenn man sich die Arma-Doku mal genauer anschaut, dann steht da drinnen, dass Arma nur einen einzigen Zahlen-Datentyp kennt.


    Nämlich: "Number"


    Siehe -> https://community.bistudio.com/wiki/Number


    Leider ist es etwas verwirrend, dass Arma die Zahl in diesem Datentyp intern als "single precision floating point number" abspeichert.



    Diese Art die Zahl im Arbeitsspeicher abzuspeicher ist eher für wissenschaftliche Berechnungen entworfen worden, benötigt nur 4 Byte Speicherplatz, kann dann damit zwar extreme Größenordnung abbilden, erkauft wird das aber damit, dass die Genauigkeit der abgespeicherten Zahl bei 23 Bit begrenzt ist. Das heist die größte darstellbare Ziffernfolge ist 8.388.607. Bei allen Zahlen die größer als diese Zahl sind (oder mehr Nachkommastellen hat, und dabei ist es unerheblich wo in der Zahl das Komma steht) werden die hinteren Ziffern statt dessen nur mit Nullen gefüllt.


    (Korrektur: Es muß "24 Bit" und "16.777.216" heißen ... siehe Diskusion weiter unten)


    Siehe -> https://en.wikipedia.org/wiki/…ion_floating-point_format




    Dies führt besonders bei der Berechnung und Darstellung großer Geldbeträge immer wieder zu unerklärlichen Rechenfehlern, auf die selbst gestandene Programierer von Warenwirtschaftssystemen immer wieder hereinfallen.


    Wenn man mit wirklich große Zahlen mit vielen Nachkommastellen mathematisch korrekt rechnen will, dann sollte man dazu andere Datenformate wie z.B. "Decimal" verwenden. Leider existiert dieser Datentyp in Arma nicht, weshalb einem dort keine andere Möglichkeit bleibt, als entweder Funktionen dafür selber zu schreiben, oder über den Umweg z.B. von externen Funktionen z.B. einer MYSQL-Datenbank (sofern im Arma-Projekt bereits eingebunden) diese Rechen- und Speicheroperationen auszulagern.



    Gruß Robert

  • Hey,
    ich danke allen für diese Diskussion.


    Nach einer langen Diskussion innerhalb des Teams haben wir uns dazu entschieden, mit der ungenauigkeit zu leben. Da der Aufwand größer als der nutzen wäre.
    Für die ID´s ist uns dann doch eine andere Möglichkeit eingefallen, wie es möglich ist die Einträge zu identifizieren.




    Ich wünsche allen eine schöne Woche.


    Grüße

  • Falls ja sollte man sich mit sowas hier hier helfen können:

    Dafür gibt es den toFixed script befehl.


    Das heist die größte darstellbare Ziffernfolge ist 8.388.607.

    Huh? Also bei mir steht -16.777.216 bis 16.777.216
    Wo hast du die 8 millionen her?


    Wo kommen diese IDs denn her und warum brauchst du mehr als 10 Millionen?

    Die Antwort darauf wäre möglicherweise hilfreich.
    Wenn du die ID's nur für die Datenbank brauchst kannst du sie doch gleich als strings umherreichen.


    Mit einem Intercept basiertem Mod könnte man einen BigNumber typen erstellen der solch große Zahlen verarbeiten kann. Aber da wäre es einfacher diese einfach in strings zu speichern.
    ID's addiert oder subtrahiert man doch eh nicht.

  • Da die ID's von der Datenbank mithilfe von AUTO_INCREMENT erstellt werden, ist die Umwandlung zu Strings mit zusätzlichem Aufwand verbunden.


    Wie bereits geschrieben haben wir eine Lösung. Wir nehmen eine andere Spalte zu Hilfe, die gemeinsam zur Identifikation dienen.
    Dadurch ist zwar nicht ausgeschlossen, dass die Grenze erreicht wird. Für uns aber mehr als unwahrscheinlich.

  • Sobald du zwei getrennte Floats zur Identifizierung benutzt, kannst du über 100 Milliarden Spieler unterscheiden. Das sollte reichen^^


    8 Millionen als Obergrenze sind auf jeden Fall nicht korrekt. Es sind die 16 Millionen. Das ist ja auch ein Grund, warum ARRAYs auf 10kk Elemente begrenzt sind:

    Since Arma 3 v1.55.133789 arrays are limited to maximum of 9,999,999 (sometimes 10,000,000) elements

    Mit nur 8 Millionen würde man ja dann immer noch nicht eindeutig Elemente aus dem Array mit select und param herauslesen können.

  • Hallo Zusammen,


    das mit den von mir postulierten 8.388.607 ist leider falsch gewesen. Ich hatte vorschnell die in der "single precision floating point number" gepeicherten 23 Bit mit 223 gerechnet, und das sind 8.388.608 -1 wegen der Null, die ja auch noch dargestellt werden muss.


    Ich hatte dabei aber übersehen, dass man mit den Exponenten in der "floating point number" noch ein weiteres Bit hinzu mogeln kann. Nennt sich "most significant digit" oder auch "hidden bit"



    Siehe -> https://en.wikipedia.org/wiki/Significand



    Demnach ist, wie schon dedmen schrieb, der richtige Wertebereich +/- 224 = +16.777.216 bis -16.777.216



    Aber an der Ungenauigkeit von Fließkomma-Zahlen bei höheren Werten ändert das nix.



    Gruß Robert