EDV-mathematische Frage [Erledigt]

[Jan]

Hallo,

ich habe eine Frage an die Mathe-Cracks hier: Ich habe das Problem, das ich Adressen umrechne in Zahlenwerte. Das klappt natürlich sehr einfach. Die Formel dafür ist:

Fall 1: Adresse Typ x.y.z
Zahlenwert := x*2048 + y*256 + z

Fall 2: Adresse Typ x.y
Zahlenwert := x*2048 + y

Dabei gilt:
x kann die Werte 1 bis vermutlich 999 haben.
y und z können die Werte 0 bis vermutlich 999 haben.

Und jetzt mein Problem: Wie bekomme ich aus dem Zahlenwert wieder die ursprüngliche Adresse heraus? Vor Allem weil ich nie weiß, ob ob die Adresse Typ 1 oder Typ 2 ist. Wobei ich aber sagen muß das bislang alle Adressen den Typ 1 hatten, aber man weiß ja nie was da noch kommen könnte ...

Jan

[komnick]

Hallo Jan,

leider kannst du unter diesen Voraussetzungen nicht vom Zahlenwert eindeutig auf x,y,z schließen.
Denn du bekommst beispielsweise für (x=2,y=0,z=0) denselben Zahlenwert wie für (x=1,y=8,z=0).
Für Eindeutigkeit dürfte y nur die Werte 0-7 und z nur die Werte 0-255 annehmen.

Wäre das allerdings der Fall, würde gelten:
x = INT(Zahlenwert/2048)
y = INT((Zahlenwert-(2048*x))/256)
z = Zahlenwert-(2048*x)-(256*y)

Deinen zweiten Typ habe ich dabei bisher noch gar nicht betrachtet. Dieser führt zu dem zusätzlichen Problem, dass auch beispielsweise (x=1,y=0,z=1,Typ=1) denselben Zahlenwert hat wie (x=1,y=1,Typ=2).

Gruß,
Martin

[Tom]

Der Modulus gibt Dir den Rest aus einer Divisionsoperation. In Xbase++ ist "%" der Modulus-Operator:

? 2049 % 2048 // Antwort: 1, nämlich der Rest aus 2049 geteilt durch 2048.

Ich würde auf den ersten Blick sagen, dass Du Probleme bei der Unterscheidung bekommen kannst, weil 2048 ein Vielfaches von 256 ist (nämlich das Achtfache). Wenn y Acht ist und z Null ist und x 1, gibt das 4096. Wenn x Zwei ist und Y Null bekommst Du auch diesen Wert.

[Tom]

Ah. Überschneidung mit Martin. Trotzdem stimmt's.

[Tom]

Du kannst übrigens einfach die Gra-Funktionen benutzen.

GraMakeRGBColor nimmt ein Array aus drei Werten, die jeweils zwischen 0 und 255 liegen dürfen. Daraus wird ein Wert ermittelt, der maximal 335.554.431 beträgt. Die Gegenfunktion hierzu heißt GraGetRGBIntensity und liefert wieder das Array (x,y,z) zurück: {255,255,255}.

Edit: Ich habe übersehen, dass die Einzelwerte teilweise bis 999 gehen dürfen. Deshalb scheitert das auch nach Deinem Ansatz, weil der Exponent dann mindestens um eins höher sein muss, sonst überschneiden sich die Ergebnisse verschiedener Teilwerte.

[Jan]

Hallo Martin und Tom,

Danke für die schnellen Antworten. Um das noch nachzureichen: x, y, und z sind immer INT.

Tom, ja, genau so ein wie von Dir angesprochenes Problem hatte ich befürchtet. Deswegen hatte ich gehofft, das es da eine feste Regel für geben könnte. So muß ich mir mal all die mir bekannten Adressen (die bei Weitem nicht alle möglichen sind!) ansehen, ob es da eventuell passende Ausschlüsse gibt.

Jan

[Jan]

Hallo Tom,

das ist ein interessanter Ansatz. Leider bekomme ich damit Probleme. Ich habe gerade einen Zahlenwert 3080 zurück bekommen. Leider gibt GraGetRGBIntensity(3080) mir ein NIL zurück. Ansonsten wäre das eine super einfache Lösung.

Jan

[Tom]

x darf zwischen 0 und 999 liegen.
y darf zwischen 0 und 999 liegen.
z darf zwischen 1 und 999 liegen.

Der aus y ermittelte Wert muss null oder mindestens tausend sein, sonst gibt es Überschneidungen mit x.
Der aus z ermittelte Wert muss größergleich 1.000.000 sein, sonst gibt es Überschneidungen mit y.

Der Rückweg ist dann vergleichsweise einfach. Durch eine Million geteilt und mit Int() abgeschnitten ergibt z. Der Rest durch tausend geteilt und mit Int() abgeschnitten ergibt y. Der Rest davon ist x.

[Tom]

Leider gibt GraGetRGBIntensity(3080) mir ein NIL zurück.

Ja, schulljung. 8-Bit-RGB beginnt ab 16777216 (das Ende des 7-Bit-Farbraums). Die müsstest Du auf Deinen Anfangswert addieren. Ansonsten - siehe letztes Posting von mir.

[Jan]

Hallo Tom,

oha, da hab ich ja was losgetreten.

Ich habe mal schnell Deinen letzten Nachtrag getestet. GraGetRGBIntensity(16777216 + 3080) ergibt ein {8, 12, 0}. Das kann nicht richtig sein, denn manuell berechnet wäre die Lösung {1, 4, 8}. Oder hab ich schon wieder was übersehen?

Jan

[Tom]

Hallo, Jan.

Das geht ohnehin so nicht, weil Dein Werteraum viel höher ist. z muss mit 1.000.000 multipliziert werden, y mit 1.000. Dann ist der Rückwärts-Rechenweg ganz einfach. Martin und ich haben's unabhängig voneinander erklärt.

[brandelh]

Ich frage mich, warum du das machen musst bzw. wer die Regeln festlegt.

Warum z.B. x und y nicht immer gleich verschlüsseln, wenn dann z = 0 ist ist es halt so ?

Oder geht es dir um die RGB Farben ?

GraMakeRGBColor( <aRGB> ) --> nRGBColor | NIL

macht eine Umrechnung der Art. Bei einem Zahlenraum von 0/1 bis 999 warum multiplizierst du mit 2048 ?

Code: Alles auswählen

x=1 * 1.000.000 + // max 999 * 1.000.000 => 999.999.999 // 9 Stellen !
y=2 * 1.000 +
z=3 * 1
=> 1002003 (dezimal !)
warum nicht über Strings ?
cWert := right(strZero(1002003,15,0),9) // so hat man sicher alles in Ziffern, auch wenn es nicht 15 sein müssten ;-)
x := val(substr(cWert,1,3))
y := val(substr(cWert,4,3))
z := val(substr(cWert,7,3))

[Jan]

Hubert,

nein, es geht eindeutig nicht um RGB! Das hatte Tom nur ins Spiel gebracht weil das die Rückrechnung vereinfachen würde. Man muß das nicht mehr manuell machen, sondern es gibt schon ein Xbase++-Funktion dafür. Das würde hier nur nur ein wenig zweckentfremdet verwendet werden.

Und die Multiplikatoren habe ich mir nicht ausgesucht. Das ist von der sendenden Anlage so vorgegeben.

Jan

[brandelh]

ok, dann steh ich nicht mehr auf dem Schlauch

nach deinen Vorgaben, kann man Typ 1 nicht von 2 unterscheiden !
Am Besten man betrachtet das BIT-Weise und eliminiert die unerwünchsten mit

BAnd( <nVa1>, <nVal2>, [<nVal3>,...] ) -> nBitwiseAnd

wobei wenn z 999 sein kann, dann würde es sich ab 256 überschneiden, wenn y mit 1 anfängt.

Deine Formel macht aus meiner Sicht nur Sinn, wenn:

z von 0 bis 255 geht, braucht 8 Bit, dann wäre y*256 vor ihm sicher, denn dann würde das erste Byte zu z gehören,
im Kopf ist das aber übel, ich lade mal ein Programm ... 4 weitere Bit für y - durch 2048 für y reserviert sind bevor es zu x übergeht.
Das muss man entweder in HEX oder besser alles binär ausrechnen, dann sieht man wo es hingeht.

Fall 1: Adresse Typ x.y.z
Zahlenwert := x*2048 + y*256 + z

Fall 2: Adresse Typ x.y
Zahlenwert := x*2048 + y

Dabei gilt:
x kann die Werte 1 bis vermutlich 999 haben.
y und z können die Werte 0 bis vermutlich 999 haben.

Wie gesagt, das kommt mir nach Bit-Schieben vor und da geht es immer um 0 bis 255.

[Tom]

Das hatte Tom nur ins Spiel gebracht weil das die Rückrechnung vereinfachen würde.

Aber auch nur, wenn man es bereits für die Hinberechnung verwendet. Wenn ich Dich richtig verstehe, kommt die Codierung der Adressen aus einem anderen System und muss von Dir so hingenommen werden. Wenn das so ist, ist die Doku falsch, das System falsch - oder Du gibst eines von beiden falsch wieder. Die skizzierte Anordnung ist nicht eindeutig. Irgendwas fehlt da.

Ansonsten hat Martin den Rechenweg genau beschrieben. Das Ergebnis ist nur nicht eindeutig. Kann es auch nicht sein.

Adresse 1 unterscheidet sich von Adresse 2 dadurch, dass Y bei Adresse 2 null ist. In diesem Fall hat man Adresstyp 2 und wird Y zu X. Möglich, dass das Codierungssystem ansonsten dafür sorgt, dass keine Adressen geliefert werden, die uneindeutig sind. Ich gehe aber eher davon aus, dass Du irgendwas nicht ganz korrekt wiedergibst.

[brandelh]

Ich gehe aber eher davon aus, dass Du irgendwas nicht ganz korrekt wiedergibst.

ich vermute eher, dass die Dokumentation sehr dürftig ist und er raten muss

Wie zuvor bei deinem "Abfrageproblem" würde ich in solchen Fällen zuerst mal mit SET ALTERNATE ein Protokoll einschalten.
Dann die Antworten (hier also die gelieferten Daten) sammeln und wie schon beschrieben als HEX oder BIN Wert darstellen (man kann die Bits bei LONG ja so schön abfragen !)

Code: Alles auswählen

Bits:
nWert := VomSystem()
cWert := ""
for x := 0 to 31
   cWert += " "+iif(nWert(x),"1","0")
next
etc. 

[brandelh]

Ich habe mal im Basic Compiler die 2^x Reihe ausdrucken lassen ... es ist schon so lange her

Code: Alles auswählen

das wird durch multiplikation von 256 reserviert (8 Bit, 1 Byte):
 0             1
 1             2
 2             4
 3             8
 4             16
 5             32
 6             64
 7             128 => 0 bis 255
hier folgt dann die zweite Variable ab Byte 8 (von 0 gezählt, mit Xbase++ Basis 1 => 9)
 8             256
 9             512
 10            1024
hier wäre die nächste Grenze zu ziehen
 11            2048
 12            4096
 13            8192
 14            16384
 15            32768
...

um nun den niedrigsten Anteil zu lesen, löscht man die oberen Bits so:
nAndY := 0
nAndY[9] := .t.
nAndY[10] := .t.
nAndY[11] := .t.

nAndX ... das ist Fleißarbeit

z := BAnd( nWert , 255 ) => 01010110101101010 band 00000000000000000000000011111111 ( 255 ) => 01101010 => 106
y := BAnd( nWert , nAndY ) / 256
x := BAnd( nWert , nAndX ) / 2048 => Bitweises verschieben der Stellen, dezimal wären es andere Werte.

[Tom]

nach deinen Vorgaben, kann man Typ 1 nicht von 2 unterscheiden !

Doch. Y ist in diesem Fall null. Es wird zu Z.

[Tom]

Zerlegung mathematisch:

Code: Alles auswählen

* nValue ist der Adresswert
lAdressType := 1
x := Int(nValue/2048) // das stimmt in jedem Fall
nValue -= (x*2048)
y := Int(nValue/256)
nValue -= (y*256)
z := nValue
IF y = 0
 lAdressType := 2
 y := z
 z := 0
ENDIF

[brandelh]

nach deinen Vorgaben, kann man Typ 1 nicht von 2 unterscheiden !

Doch. Y ist in diesem Fall null. Es wird zu Z.

So wie ich Jans ersten Beitrag lese, kann es sein, dass sowohl Y als auch Z gleich 0 sind.
In diesem Fall kann man die Adresse nicht voneinander unterscheiden, wobei ich nicht weis ob das dann relevant wäre

Auf jeden Fall sehe ich mir solche Sachen gerne binär an, da kann man dann sehen was überhaupt belegt wird und was nicht.

[Tom]

So wie ich Jans ersten Beitrag lese, kann es sein, dass sowohl Y als auch Z gleich 0 sind.

So, wie ich Jans ersten Beitrag lese, hat er keine Ahnung, welchen Wertebereich die einzelnen Komponenten annehmen können. Es gibt ja auch noch andere Probleme als null in X oder Y. Siehe erste Antworten. Um jedenfalls nach seiner Anleitung einen Wert wieder zu zerlegen, wäre der Code von mir, glaube ich, richtig. Ich sehe auch nicht, inwieweit Deine Zerlegung da helfen sollte.

[Tom]

y und z können die Werte 0 bis vermutlich 999 haben.

Ich nehme an, dass y zwischen null und sieben liegen darf, und z darf maximal 255 sein. Dann funktioniert das System.

[AUGE_OHR]

hi,

man kann doch Konstanten (#define) addieren und wieder "zerpflücken" ... wäre das nicht der Lösung Ansatz ?

[Tom]

Jan bekommt nur den codierten Wert.

[AUGE_OHR]

Jan bekommt nur den codierten Wert.

schon klar, es geht um das "zerpflücken" von solchen Werten.