Bitweise aus Datei lesen, Große Zahlen in Array zerlegen
-
Zeh Mau schrieb:
Öhhhh, sind wir schon soweit, dass CPUs mit 512 Bit rechnen können?
Mir war zuletzt 128 Bit bekannt.
Trotzallem, deine CPU muss 512 Bit verarbeiten können, folglich muss es auch entsprechende Datentypen geben.
Mit long long sind wir bei 64 Bit, eine Multiplikation ergibt damit 128 Bit.
Ich denke, du musst nun eigene Bibliotheksfunktionen schreiben, damit du deinen Wertebereich kontrollieren kannst.
Na dann, viel Spaß.
du hast mich nicht verstanden... denn genau das versuche ich ja! also eine sehr große zahl zerlegt in 16bit häppchen in ein array ablegen und dann damit rechnen!
also z.b. u = große zahl1, v = große zahl2
for(i=0; i<SIZE; i++) { result[i] = u[i] + v[i] + carry; }
mir gehts aber nicht um die rechenoperationen, sonder wie ich eine große zahl z.b. 256 Bit aus einer Datei lese, zerlege und in das Array schreibe
-
Ja dann mußt du dir ein Konzept überlegen:
Beispielsweise:
Lese einen string ein (deine große Zahl) und separiere anschließend byte für byte aus diesem string heraus und mach das, was du vorhast :xmas2:
-
Zeh Mau schrieb:
Ja dann mußt du dir ein Konzept überlegen:
Beispielsweise:
Lese einen string ein (deine große Zahl) und separiere anschließend byte für byte aus diesem string heraus und mach das, was du vorhast :xmas2:
super antwort *gg*
also ehrlich genau da liegt ja mein problem wenn ich byteweise wie oben beschrieben:
85 concat 19 concat 67 ist nicht 851967also deinen Rat kann ich bisher verzichten sry :p
bitte oben erst lesen dann posten danke :xmas1:
-
BigNum schrieb:
--> also ist 12 concat 65535 = 851967
Ja, 12*(1<<16)+65535 ist 851967.
Die einzelnen unsigned shorts kannst du lesen und schreiben, indem du jeweils zwei Bytes zusammenfügst bzw. auseindernimmst:
byte HiByte=read(file,1); byte LoByte=read(file,1); unsigned short n=(HiByte<<8)|LoByte; // HiByte=n>>8; LoByte=n&255; write(file,&HiByte,1); write(file,&LoByte,1);
-
Sage ich doch
"separiere anschließend byte für byte aus diesem string".
-
Nanyuki schrieb:
BigNum schrieb:
--> also ist 12 concat 65535 = 851967
Ja, 12*(1<<16)+65535 ist 851967.
Die einzelnen unsigned shorts kannst du lesen und schreiben, indem du jeweils zwei Bytes zusammenfügst bzw. auseindernimmst:
byte HiByte=read(file,1); byte LoByte=read(file,1); unsigned short n=(HiByte<<8)|LoByte; // HiByte=n>>8; LoByte=n&255; write(file,&HiByte,1); write(file,&LoByte,1);
danke für die antwort, die mir zu denken gibt und wohl auch der richitg ansatz ist
allerdings will ich ja quasi die zahl 851967 in der "zu-lesenden" datei einlesen, und daraus die zahlen 12 und 65535 erzeugen und diese dann in zahlarray[0] = 65535 und zahlarray[1] = 12 schreiben und nicht andersrum
hmmm hast du nochmal bisschen ausführlichere erläuterung zu deinem ansatz?
greetz BigNum
-
Nanyuki schrieb:
byte HiByte=read(file,1); byte LoByte=read(file,1); unsigned short n=(HiByte<<8)|LoByte; // HiByte=n>>8; LoByte=n&255; write(file,&HiByte,1); write(file,&LoByte,1);
also nochmal wenn ich zwei bytes auseinander nehmen will..
sagen wir die zahl 37 also hb= 3 und lb=7 (meintest du doch so oder?)dann hätte ich durch
n =(3<<8)|7;
hb = n >> 8 -->3
lb = n&255; --> 7das ist natürlich dann nicht richtig da 3 concat 7 nicht 37 ist ..
irgendwie steh ich auf der Leitung *wein*
-
Du mußt dich mal mit den verschiedenen Basissystemen auseinandersetzen.
Du hast also eine (große) Zahl im Dezimalsystem vorliegen (0123456789) und diese möchtest du in ein anderes Zahlensystem (bei dir 65536) überführen.Dann bleibt dir nichts anderes übrig als die normale Division durchzuführen (so wie du es von der Schule kennst), nur eben auf (Teil-)Strings.
851967 : 65536 = 12 (Rest 65535) 65536 ----- 196607 131072 ------ 65535
Du mußt also mindestens intern für's Rechnen 65536*65536 Zahlen verwenden können, d.h. 4 Byte.
-
Vielen Danke für die Antwort!!!
Nur versteh ich nicht ganz wie ich es anstelle wenn die Zahl dann wirklich groß ist und ich dann mehrer Hi/Lows bekomme...
also z.b.:
24542673594 = 101 - 1011011011011011- 0111101010111010
nach den ziffern von hinten zerlegen:
73594 / 65536 = 1 Rest 8058-> 1 und 8058
-----------------
10000000000000000 -> 1
00001111101111010 -> 8058
-----------------
10001111101111010 -> 73594245426 / 65536 = 3 Rest 48818
-> 3 und 48818
--------------------
111000000000000000
1011111010110010
--------------------
111011111010110010hier stimmt es dann schon nicht da bei 48818 die führende 1 zu viel ist
ausserdem bekomme ich ja nun 4 Teile (1,8058,3, 48818) wie bekomm ich daraus dann die wirklichen 3 Teile zu:
24542673594 = 101 - 1011011011011011- 0111101010111010ich hab glaub zu viel über den mist nachgedacht, das sich eine Denkblockade aufgebaut hat
-
hat jemand nochmal einen "Schubs" für mich?
-
Ich fürchte du mußt dir eine Routine schreiben, die große Zahlen dividieren
kann, und solange dividieren, bis nur noch ein Rest bleibt:Z.B. so:
24542673594 : 65536 = 374491 Rest: 31418 374491 : 65536 = 5 Rest: 46811 5 : 65536 = 0 Rest: 5 31418 => 0111101010111010 46811 => 1011011011011011 5 => 0000000000000101
D.h. Du benötigst eine Funktion, die gegeben einen String a und einen Dividend
d (hier sollte ein int reichen), dir einen String q (Quotient) und den
Rest r (auch hier würde ich wieder eine int oder short nehmen) zurückgibt.(q,r) = f(a, d)
Ich hoffe, ich konnte dir hiermit weiter helfen. Wie genau diese Funktion
aussehen könnte, oder ob es schon für dein Problem exisiterende Funktionen
gibt, weiß ich noch nicht.Gruß mcr
-
gibts doch alles schon fertig: http://www.cs.sunysb.edu/~skiena/392/programs/bignum.c
#####################
#####################
#####################
#####################
#####################
#####################
#####################
#####################
#####################
#####################
#####################
#####################
-
bigint-freak schrieb:
gibts doch alles schon fertig: http://www.cs.sunysb.edu/~skiena/392/programs/bignum.c
Wenn ich das richtig sehe eben nicht. Denn was hier gesucht wird ist eine Funktion die einen großen Integer in ASCII-Repräsentation in eine binäre Struktur quetscht. Das verlinkte Programm liest nur "normale" ints ein und rechnet mit diesen über die normalen Grenzen hinaus.
-
huch? ja, stimmt. aber vielleicht das hier: http://search.cpan.org/src/GARY/Math-BigInteger-1.0/bn.c
#######################
#######################
#######################
#######################
#######################
#######################
#######################
#######################
#######################
#######################
#######################
#######################