Anregungen und Vorschläge zu PROFAN
Hier können Vorschläge für künftige PROFAN-Versionen, Ausgestaltung der PROFAN-Seiten und -Foren, etc. gemacht werden.

| Suchen
Seiten: 1 2 | Zurück zur Übersicht

Autor | Thema: Fehler in HEX$
Thorsten
| 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)
Andreas Miethe
| 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
Thorsten
| 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 ....
Frank Abbing
| Datum:21.05.02 20:19 |
Hi, du irrst dich da, Thorsten. Andreas Werte sind schon richtig (außer das minus). Gruß, Frank
Frank Abbing
| 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
Thorsten
| 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 !!!!
Frank Abbing
| 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
Sven Schmidts
| 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!
Thorsten
| 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 ....
Roland G. Hülsmann
| 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
Thorsten
| 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.
Sebastian König
| 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
Thorsten
| 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.
Frank Abbing
| 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
Frank Abbing
| 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
Frank Abbing
| Datum:24.05.02 20:10 |
Hallo Roland, wäre nett, wenn ich eine Antwort bekommen würde... Gruß, Frank
Roland G. Hülsmann
| Datum:27.05.02 09:05 (rgh-soft@t-online.de) |
>> Stimmt doch alles, oder ? So weit ich das überblicke: JA! Gruß Roland
Roland G. Hülsmann
| 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
Frank Abbing
| 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
Sven Schmidts
| Datum:27.05.02 21:37 (schmidts@flat2serv.de) |
Kann ein Byte -1 sein ??? 8x0=0 ;)

Seiten: 1 2 | Zurück zur Übersicht

| Ein kostenloses WebMart Forum WebMart Homepage Tools kostenlos |