Long-Array als Dezimalzahl im String darstellen

[STARGÅTE]

Tachchen,

ich befasse mich gerade (wieder mal) mit großen zahlen.
Und nun frage ich mich wie ich zB eine zahl die in zB in 8 Longs steht in das 10er System übertragen kann.

Die Longs kann auf einfache Weise ins Hex-System bringen.
Sodass ich zB "FF FF FF FF" habe.
Diese "Blöcke" kann ich dann als Strings an einander reihen und erhalte so die "wirkliche" Zahl allerdings im 16er System.
Wie komme ich dann aber ins 10er System ?

Jede Stelle * 16^Stelle zu nehmen und dann zu addieren geht ja leider nur solange wie 16^Stelle auch noch ein Ergebnis liefer, was jedoch bei 16^16 endet (QUAD-Overflow).

Mir ist bekannt das es bereits viele "BigInteger"-Libs, -DLLs gibt, aber ich möchte halt selber auch was entwicken ...
scheitere aber nun an der ausgabe in "Unser" System.
Denn Fakultät von 100 will keiner in Hex sehen ^^

[AND51]

Och Martiiiiiiiin...
Als du den Changelog der 4.xx Version gelesen hast, hast du doch gelesen, dass Val() nun auch Binär- und Hex-Zahlen unterstützt:

Code: Alles auswählen

Debug Val("51")
Debug Val("%101")
Debug Val("$FF")

Na, erinnerst du dich?

[Kaeru Gaman]

das hat doch aber mit seinem problem nix zu schigge...

[STARGÅTE]

jo AND51, das ist mir schon beakannt geht aber nur bis QUADs (also 16-stellige HEX)
aber die zahlen sind meist größer.

Ich habe mir nun mal die ersten 16^n angeguckt:

Code: Alles auswählen

                    1
                   16
                  256
                 4096
                65536
              1048576
             16777216
            268435456
           4294967296
          68719476736
        1099511627776
       17592186044416
      281474976710656
     4503599627370496
    72057594037927936
  1152921504606846976

Dort sind regelmäßigkeiten zu erkennen:
Hinten immer 6, davor immer (n*4-3)%10 usw.
Ich könnte also die Ziffer einer 16^n mit einem Algo bestimmen der nur von n und der Ziffenposition abhängt, und damit dann den Stellenwert multiplizieren und an der jeweiligen Stelle im String zu addieren.
UNd diese ganzen Zahlen dann im 10er system addieren. Dauert aber bestimmt eine ewigkeit um dann eine Zahl als String auszugeben...
Aber vllt habt ihr ja eine andere Idee, oder sogar die Lösung...

[X360 Andy]

Eine weitere regelmäßigkeit wäre das die wenn man die 2 ersten Zahlen einer Reihe addiert die erste Zahl der 3ten Reihe rauskommt (1 + 1 = 2 ) ( 2 + 4 = 6 ) .... (Vieleicht auch Zufall )

Bringt dir vieleicht nichts, wollte es trotzdem loswerden

[Kaeru Gaman]

also, eine andere möglichkeit wäre, dass du deine Bytes im "Decimal Mode" nutzt.
ich weiß nicht, in wieweit es dafür in heutigen Chips Einstellungen gibt...
beim 6501 hatte die CPU noch ein Flag was die ASM Kommandos direkt im Dec-Mode operieren ließ.

im Dec-Mode wird jedes Nibble nur 0-9 gezählt, nicht 0-15.
also, der Overflow und das setzen des ersten Bits im nächsten Nibble erfolgt schon nach der 9, nicht nach $F.
damit kann man natürlich nur wesentlich kleinere Zahlen mit einer bestimmten anzahl bytes speichern,
64bit geht dann nicht bis 2^64-1 sondern nur bis 10^16-1,
aber dafür entspricht jedes Nibble genau einer Dezimalziffer,
und man kann eine beliebig große Anzahl Speicherbytes direkt in einen Dezimalen String übersetzen.

[helpy]

==> BCD (Binary Coded Decimal)

[STARGÅTE]

ah oke, also war meine darmalige herrangehensweise:
- In eine LONG nur Zahlen bis 9999 9999 speichern zu lassen und dann einene Übertrag zu machen obwohl die LONG noch platz hätte, garnicht so falsch ...

danke helpy für den Link, mal angucken ...

[helpy]

Nur, wenn der Prozessor das Rechnen mit BCD-Zahlen nicht unterstützt, dann ist musst Du das Rechnen mit BCD-Zahlen selbst programmieren, das ist dann jedenfalls langsamer als das "binäre" Rechnen.

Die Darstellung der Zahl im dezimalen Zahlensystem ist natürlich einfacher/schneller, wenn diese im BCD-Format vorliegen. Große Zahlen im binären Format als dezimale Zahlen darzustellen, braucht im Vergleich dazu sicher um einiges länger.

Da muss man sich dann wohl entscheiden, was man macht ... keine Ahnung was nun effektiver ist! ... hängt sicher auch von der Anwendung ab!