PureBoard

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 ^^

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:Na, erinnerst du dich?

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

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

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

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.

==> BCD (Binary Coded Decimal)

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

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!