Autor | Thema: Fehler in HEX$ | | Datum:21.05.02 17:26 
(mrk@mrk-soft.de) | |
Hi Roland,
HEX$() hat einen Fehler.
Die Zahl: -455270209 sollte ergeben: E4DD20BF,
herus kommt aber: -1622DF41.
An Delphi kann es nicht liegen, da wird korrekt gewandelt,
was macht Profan den da schon wieder !!!!
Inwieweit ist ein BUGFIX für Profan 7.5 möglich !!!
print hex$(-455270209)
|
| | Datum:21.05.02 18:01 
(andreas@andreas-miethe.de) | |
Hallo Thorsten,
E4DD20BF ist 3839697087
-455270209 ist -1B22DF41
Das wird mit Profan auch richtig dargestellt.
Ich konnte da keinen Fehler finden.
Gruss
Andreas
|
| | Datum:21.05.02 20:06 
(mrk@mrk-soft.de) | |
>Das wird mit Profan auch richtig dargestellt.
>Ich konnte da keinen Fehler finden.
Falsch,
HEX: E4DD20BF ist DEZ: -455270209
selbst mein Einfacher CASIO fx-100 Taschenrechner weiss das,
und kommt zum selben Ergebniss, Delphi selber ebenfalls auch.
-1B22DF41 ist übrigens soweiso absoluter Quark ....
|
| | Datum:21.05.02 20:19 
| |
Hi,
du irrst dich da, Thorsten. Andreas Werte sind schon richtig (außer das minus).
Gruß, Frank
|
| | Datum:21.05.02 20:23 
| |
Hi nochmal.
Es liegt an der Rechenmethode.
E4DD20BF als unsigned Long -> 3839697087
E4DD20BF als signed Long -> -455270209
Quasi jeder Base-Converter arbeitet aber mit unsigned Longs.
Gruß, Frank
|
| | Datum:21.05.02 21:14 
(mrk@mrk-soft.de) | |
Frank,
Nein, das ist NICHT richtig. Denn dann würde JEDER
Taschenrechner, der in der Lage ist, auf der BASE
Grundlage zu rechnen, (z.b ein Casio fx-100D), ein flsches Ergebniss liefern und alle Mathematiker und Informatiker
würden mit flaschen Werten Rechnen, nach deiner Aussage.
(auch der Sharp Taschenrechner hier kommt zum gleichen
Ergebniss)
Beispiel: Taschenrechner umgestlelt auf BASE, Dann auf Modus
DEZIMAL gestellt, die Zahl -455270209 eingegeben, dann
die Taste HEX gedrückt und zurückgegeben wird: E4DD20BF.
Umgekert, HEX eingegeben, und Taste DEZ (für Dezimal)
gedrückt, heraus kommt wieder -455270209.
2ter Test: Delphi 6.0, Enterprise Edition, kleines Test-
Programm, -455270209 umwandeln lassen in HEX, heraus kamm
auch hier E4DD20BF.
3ter Test: Visual Basic 5.0, ein Kollege hat ein kleines
Test-Programm gemacht, das ebenfalls den HEX Wert ermittelte,
heraus kam auch hier bei -455270209 der Wert: E4DD20BF
4ter Test: aus dem Internet habe ich mir ein Test-PRG
geholt, das ebenfalls diesen Wert umrechnete, der Autor
schrieb, er hätte das in C++ geschrieben, auch hier kommt
der obige Wert heraus.
So, nur Profan ist da als EINZIGES nun anderer Meinung !!!
Also sollten sich dann alle Informatiker lieber Profan
Instalieren anstastt mit einem Taschenrechner zu arbeiten !!!!
|
| | Datum:21.05.02 21:29 
| |
Hi,
ich kann dir zwei Base-Converter schicken, die standartmäßig vorzeichenlose Long-Integer umrechnen.
Da ich persönlich aber nie mit so großen negativen Hexzahlen rechne, ist es mir ziemlich egal.
Ich gebe dir aber recht,
$FFFFFFFF ist in meinen Augen -1 und nicht 4294967295.
Gruß, Frank
|
| | Datum:21.05.02 23:29 
(schmidts@flat2serv.de) | |
"Delphi 6.0, Enterprise Edition" (musst Du Geld haben) zur Berechnung von Hex$ ... Das nenne ich mal "Mit Kanonen auf Spatzen schiessen". ;)
PS: Hallo Rolfi!
|
| | Datum:22.05.02 21:30 
(mrk@mrk-soft.de) | |
>"Delphi 6.0, Enterprise Edition" (musst Du Geld haben) zur
>Berechnung von Hex$ ... Das nenne ich mal "Mit Kanonen auf
>Spatzen schiessen". ;)
Hi Sven,
Mit ner Flinte "Treff" ich ja nicht so gut, und Kanonen
sind halt einfacher zu Handhaben ....
|
| | Datum:22.05.02 15:12 
(rgh-soft@t-online.de) | |
Hallo Thorsten,
PROFAN macht (zumindest an dieser Stelle) keinen Fehler.
Die Umwandelfunktionen, also auch @Hex$, erwarten als Parameter einen longint und keinen unsigned longint. Das heißt: das erste Bit wird als Vorzeichenbit gewertet und daher reicht der Wertebereich von -2^31 bis +2^31 (=2.147.483.648), entsprechend in Hexdarstellung von -7FFFFFFF bis 7FFFFFF. Auch die Hex-Zahlen sind hier mit einem Vorzeichen behaftet.
Nun zu Deiner Zahl -455270209:
455270209 ist 1B22DF41.
-455270209 ist dann eben -1B22DF41.
Natürlich hast Du mit E4DD20BF auch recht. Das wäre die Hexdarstellung der Zahl ohne Vorzeichen, liegt aber außerhalb des Wertebereichs der Longints (siehe oben). Andererseits kann PROFAN auch mit solchen Werten in gewisser Weise umgehen:
PRINT $E4DD20BF
PRINT -$1B22DF41
In beiden Fällen wird -455270209 ausgegeben. Und wenn man nun nicht auf Longints (mit Vorzeichen) beschränkt wäre und Unsigned Longints (Longints ohne Vorzeichen; Wertebereich 0 - 2^32 = 4.294.967.295) hätte, dann würde E4DD20BF auch als positiver Wert dargestellt, nämlich als 3.839.697.087, wie Andreas sehr richtig festgestellt hat.
Ich weiß, das klingt alles etwas verwirrend. Man sollte sich lediglich merken, daß die Umwandlungsroutinen in PROFAN normale Longints (mit Vorzeichen!) verwenden.
Gruß
Roland
|
| | Datum:22.05.02 16:40 
(mrk@mrk-soft.de) | |
Hallo Roland,
Danke für die Antwort, dachte mir sowas schon, nur löst sich
damit das Problem leider ja so nicht. Solche Zahlen kommen
übrigens bei einer CRC32 Prüfsumme zustande (ist in der TCP
DLL als Routiene NEU hinzugekommen), und die DLL gibt halt den
Wert als Long Zurück. Bei der Umwandlung nach einer HEX Zahl
kommen da jetzt nur ebend falsche Werte heruas !!
Um das Problem mit Profan zu umgehen, hab ich ne kleine MINI
DLL erstellt, (grad mal 6 KB gross), wo der Dezimal Wert dann
als HEX-Wert (richtig !!!) umgewandlet wird.
Naja, wird den in absehbarer Zeit da ein Update in Profan
geben, den wie gesagt, jeder einfache Taschenrechner gibt
hier die Umwandlung als unsigned longint in HEX Format aus.
|
| | Datum:22.05.02 19:15 
(feedback@sekoenig.de) | |
Hallo,
wahrscheinlich kann Dir die API-Funktion wsvprintf(), die der Funktion sprintf() der C-Laufzeitbibliothek nachempfunden wirde, weiterhelfen. Damit können u.a. 32bit-Integer (Longs) in vorzeichenlose Hexadezimale Zahlen umgewandelt werden. Hier ein kurzes Beispiel:
DEF wvsprintf(3) !"USER32","wvsprintfA"
declare output#,format#
dim output#,64
dim format#,64
declare num&
let num& = -455270209
string format#,0 = "%X" 'X = hex. uppercase
wvsprintf(output#,format#,Addr(num&))
cls
print "Dez.:",num&
print "Hex.:",@string$(output#,0)
print "Mit Tastendruck beenden!"
waitkey
'---Aufräumen;
dispose output#
dispose format#
end
Ich hoffe, ich konnte Dir weiterhelfen.
MfG
Sebastian
|
| | Datum:22.05.02 21:54 
(mrk@mrk-soft.de) | |
Hi Sebastian,
genau richtig, hatte zwars schon in der API geschaut, nur
auf diese Funktion wäre ich nicht gekommen.
Hab das ganze als Procedure in der INC der TCP.DLL
hinterlegt, um nun auch den richtigen HEX-Wert der CRC
Summe zu ermitteln.
|
| | Datum:22.05.02 20:00 
| |
Hallo.
Roland: "Ich weiß, das klingt alles etwas verwirrend. Man sollte sich lediglich merken, daß die Umwandlungsroutinen in PROFAN normale Longints (mit Vorzeichen!) verwenden."
Leider trifft das aber nicht auf Integer und Bytes zu, wie die unteren Zeilen beweisen, hat mich schon des öfteren fast zur Verzweiflung gebracht...
Word bereich#,0=-1000
Word bereich#,2=-2000
Word bereich#,4=-3000
Word bereich#,6=-4000
Print Word(bereich#,0)
Print Word(bereich#,2)
Print Word(bereich#,4)
Print Word(bereich#,6)
Als Ergebniss kommt jedenfalls nicht -1000, -2000,-3000,-4000 zurück...
Gruß, Frank
|
| | Datum:22.05.02 21:34 
(frankabbing@12move.de) | |
Hallo Roland,
eine neue Funktion der ProSpeed.dll wird Compute() sein. Ich will nur sicher gehen, das meine Angaben in der Anleitung korrekt sind, kannst du das mal bitte durchsehen:
Compute (B,A,F,+,-,*,/,S)
Wendet einfache Rechenoperationen an allen oder einigen Long-Integer (optional auch Integer oder Bytes) in einem Bereich an.
B : Long - Bereichsvariable (Speicheradresse)
A : Long - Anzahl Bytes in B, die mit Compute() neu berechnet werden sollen
F : Long - Flag, welches Zahlensystem verwendet wird: 1 = Byte / 2 = Integer / 4 = LongInt
+ : Long - Dieser Wert wird zu jeder Zahl im Bereich addiert
- : Long - Dieser Wert wird zu jeder Zahl im Bereich subtrahiert
* : Long - Dieser Wert wird mit jeder Zahl im Bereich multipliziert
/ : Long - Jede Zahl im Bereich wird mit diesem Wert dividiert (Nachkomma-Stellen werden abgeschnitten)
S : Long - Nach jeder Zahl so viele Bytes überspringen, normalerweise 0
Ergebnisse: Long - 0
Mit Compute() können viele Zahlen gleichzeitig addiert, subtrahiert, mulipliziert und/oder dividiert werden.
Hierbei ist einstellbar (in F), ob die Zahlen im Bereich B Bytes, Integer oder LongInt's sein sollen. Eine 1 bedeutet, alle Zahlen werden als
Bytes behandelt. Bei 2 werden alle Zahlen als Integer behandelt und bei 4 als LongInteger.
In S kann angegeben werden, ob jede Zahl im Bereich neu berechnet werden soll, oder ob nach jeder Zahl eine gewisse Anzahl Bytes
uebersprungen werden sollen.
+, -, * und / können alle gleichzeitig angewendet werden, oder einzeln oder sonstwie kombiniert, die Reihenfolge, sollte mit allen vieren
gerechnet werden, ist immer: multipizieren - dividieren - addieren - subtrahieren.
Wenn in F bestimmt wird, das Bytes oder Integer benutzt werden (1 oder 2), muß beachtet werden, das Profan Bytes und Integer in
Bereichen immer als vorzeichenlos behandelt, also nur mit positiven Zahlen rechnet. Negative Zahlen erhalten so also falsche Werte. Bei
Long-Integer ist das nicht so, diese werden immer vorzeichenbehaftet behandelt und liefern auch bei negativen Zahlen ein richtiges
Ergebniss.
Bytes können nur innerhalb der Zahlen 0 - 255 operieren, Integer innerhalb der Zahlen 0 - 65535. Long-Integer können mit Zahlen von
-2.147.483.648 bis 2.147.483.647 rechnen.
Stimmt doch alles, oder ?
Gruß, Frank
|
| | Datum:24.05.02 20:10 
| |
Hallo Roland,
wäre nett, wenn ich eine Antwort bekommen würde...
Gruß, Frank
|
| | Datum:27.05.02 09:05 
(rgh-soft@t-online.de) | |
>> Stimmt doch alles, oder ?
So weit ich das überblicke: JA!
Gruß
Roland
|
| | Datum:27.05.02 08:54 
(rgh-soft@t-online.de) | |
Hallo Frank,
das ist richtig: Die Funktionen @word und @byte verwenden WORD und BYTE und diese sind Vorzeichenlos. Es handelt sich aber lediglich um ein Darstellungsproblem. Um das Vorzeichen wieder herzustellen, muß vom Ergebnis 2^16 (65536) bzw. 2^8 (256) abgezogen werden. Beispiel:
Print Word(bereich#,0)-65536
Wenn man häufiger mit solchen Werten umzugehen hat, lohnt sich die Definition entsprechender Funktionen:
def signedw(1) int(if(&(1)>32767,&(1)-65536,&(1)))
def signedb(1) int(if(&(1)>128,&(1)-256,&(1)))
Das sieht dann so aus:
Print signedw(Word(bereich#,0))
Ein Byte mit Vorzeichen wäre der Typ "ShortInt" (-128 bis 127), ein Word mit Vorzeichen der Typ "SmallInt" (-32768 bis 32767).
Man mag jetzt einwerfen: Bei @long ist es aber anders! Das ist richtig, liegt aber darin begründet, das Delphi 2 den Typ "Unsigned Long" nicht kennt. PROFAN ist in Delphi2 geschrieben.
BTW: Fensterhandles und ähnliches sind ja "Unsigned Long". Das stört aber nicht, da es hier nur um die Darstellung (mit oder ohne Vorzeichen) geht. Würde man ein Fensterhandle oberhalb des LongInt-Bereiches ausgeben (etwa 3.000.000.000) oder würde man damit rechnen, würde es natürlich negativ sein. Aber man rechnet ja nicht mit Handles, sondern man übergibt diese typischerweise an andere Funktionen. Und diese interprtetieren das entsprechende Bitmuster schon korrekt als "Unsigned Long".
In der Hoffnunmg, einige Unklarheiten beseitigt und nicht allzuviele neue geschaffen zu haben
Roland
|
| | Datum:27.05.02 16:48 
| |
Hallo Roland,
danke für die ausführliche Erklärung.
Klar weiß ich, wie ich vorzeichenlose Zahlen in vorzeichenbehaftete umrechnen kann.
Es ging mir auch nur um die Darstellung und darum, keine falschen Sachen in meine Anleitung zu bringen (Milli/Mikro usw. ;-))).
Vorzeichenbehaftete Words und Byte sind eh meistens nicht sinnvoll, außer vielleicht -1.
Gruß, Frank
|
| |
|