| |
| |
|
Jac
de
Lad | Konvertiert eine Dezimalzahl in ein anderes Zahlensystem (ähnlich Hex$, Oct$ und so), nur dass die Basis frei wählbar ist (geht bis 36, nach Hexidezimal werden einfach die restlichen Buchstaben des Alphabets verwendet). Und darunter die Umkehrfunktion.
Keine Ahnung ob irgendjemand irgendwann davon Nutzen haben kann und wird...ach ja, und man kann die Zeichen naturalmente beliebig erweitern oder ändern...!
KompilierenMarkierenSeparieren
proc ConvertBase
Parameters x&,b&
declare y$,z&,l%
l%=Int(Ln(x&)/Ln(b&))
whileloop l%,0,-1
z&=x&&^&Loop
If GT(z&,0)
y$=y$+Mid$("123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ",z&,1)
Sub x&,z&*b&^&Loop
else
case Neq$("",y$):y$=y$+"0"
endif
wend
Return y$
endproc
proc ConvertToDec
Parameters y$,b&
declare l%,e&
l%=Len(y$)
whileloop 1,l%
e&=e&+Instr(Mid$(y$,&Loop,1),"123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ")*b&^(l%-&Loop)
wend
Return e&
endproc
Jac
PS: Mich würde mal interessieren, was ihr davon haltet. Aber bitte ehrliche Anworten, ehrlich gesagt habe ich selbst dafür eigentlich keine sinnvolle Anwendung... |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 24.01.2006 ▲ |
|
| |
|
|
Timotheus | Erweitere deine Proceduren einfach auf alle 256 Chrs des Computer-Alphabets. Das minimiert die Speicherung von Zahlen um ein beträchtliches. Ich benutze eine ähnliche Prozedur immer um Zahlen dessen Dimensione ich nicht kenne an bestimmten Stellen auszulesen, die immer einen bestimmten Platz in einem String oder Bereich einnehmen sollen. Das hat Beispielsweiße bei der Zahl 300 beim auslesen den Vorteil, das ich erstmal beispielsweiße nur 3 Bytes reservieren muss, in der Reihenfolge: Chr$(0) + Chr$(1) + Chr$(44), anstatt per die selbe Zahl: MkStr$(0,Len(Str$(256*256*256))-3) + 300.
Timo |
|
| |
| |
| |
|
|
Jac
de
Lad | Ehrlich gesagt verstehe ich nur Bahnhof und habe keine Ahnung, was du meinst! 
Jac |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 24.01.2006 ▲ |
|
| |
|
|
Timotheus | Ja, OK. Ich drück mich mal wieder viel zu kompliziert aus. 
Ich miente lediglich, das man mit solchen Verfahren Zahlen die man in Strings übergibt extrem komprimieren kann.
Normal:
16777215 (8 Zeichen)
Hexadeximal:
FFFFFF (6 Zeichen)
256-Chr Methode:
Chr$(255) + Chr$(255) + Chr$(255) (3 Zeichen)
Hier macht sich das vieleicht noch nicht bemerkbar, aber besonders wenn man Riesenzahlen benutzt muss man sowiso auf Strings umstellen, und das ist eine exzellente Komprimierung.
Timo |
|
| |
| |
| |
|
|
Michael
Wodrich | [quote:9550d698e5]Das hat Beispielsweiße bei der Zahl 300 beim auslesen den Vorteil, das ich erstmal beispielsweiße nur 3 Bytes reservieren muss, in der Reihenfolge: Chr$(0) + Chr$(1) + Chr$(44), anstatt per die selbe Zahl: MkStr$(0,Len(Str$(256*256*256))-3) + 300.
[/quote:9550d698e5]
Auf meinem Rechner belegt der String 300 auch nur 3 Bytes.
Anstatt folgendes??? Wer kommt auf so eine verworrene Idee?
(Habe es mal aufgelöst)
KompilierenMarkierenSeparieren
Chr$(0) + Chr$(1) + Chr$(44)
Also hast Du schlicht die Binärform der Zahl als String dargestellt. Die Reihenfolge MSB...LSB hatte mich zuerst ein wenig irritiert.
Schöne Grüße
Michael Wodrich
MSB = most significant bit
LSB = least significant bit
Das Umrechnen in Zahlen einer anderen Basis kann z.B. per Einfach-Verschlüsselung benutzt werden. Es läßt sich ja jederzeit umkehren (wenn man die Basis kennt und weiß, daß es sich um eine Zahl handelt). |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 25.01.2006 ▲ |
|
| |
|
|
Jac
de
Lad | Ich peil das immer noch nicht. Kann jemand von euch den Quelltext umschreiben?
@Michael: Sag mal, gibts per die Funktionen auch eine Verwendung? Mir fällt jedenfalls keine ein...
Jac  |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 25.01.2006 ▲ |
|
| |
|
|
Michael
Wodrich | Der ein Posting weiter oben angezeigte Quelltext sollte nur die verwendete Formel schrittweise auflösen (jede Zeile ist eine Auflösung mehr). Und am Ende steht dann als Ergebnis:
Wenn Du einen Wert als 3-Zeichen-Binärwert darstellst dann ist das kürzer als wenn Du einen String auf 8 Zeichen Länge mit Nullen auffüllst.
Also vergiß es einfach, denn der erzeugte Binärstring wird nicht sonderlich lesbar sein.
Schöne Grüße
Michael Wodrich
Chr$(0) + Chr$(1) + Chr$(44)
aufgelöst: (0*256 + 1) * 256 + 44 ergibt 300 |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 25.01.2006 ▲ |
|
| |
|
(811)
Deutsch
English
Français
Español
Italia