Forcing unsigned calculations

[TheBigBasicQ]

How did u calculate that number?

[Zack]

The Windows XP calculator...Decimal, Hexadecimal, Octal, annnnnnd...BINARY!!!

[TheBigBasicQ]

How many bits did you consider?

[na_th_an]

SINGLEs are floating point numbers, so your calculations will be screwed. For this kind of stuff you better use integer numbers. You can check the CVI command to transform from a STRING*1 to a integer:

Code:

DIM myString AS STRING *1

...

myValue% = CVI (myString + CHR$(0))

That will convert your 8 bits character into a 16 bits number (always positive) without altering it at all. To get it back to string, use MKI$ and get the first character of the two characters string returned:

Code:

myString = LEFT$( MKI$(myValue%), 1)

[Zack]

Hmm...Hold that thought, Nath...
Would this work to ignore (meanwhile discarding the negation) the top half of the word (1 integer=1 word):

Code:

encchar$=chr$((---here we do our encryption---)) AND 65280)

To me, that seems right...but...am I right?

[Mango]

nate wrote:

SINGLEs are floating point numbers, so your calculations will be screwed.

Zack et al...this is of fundamental importance to understand. While the SINGLE data-type occupies 4-bytes, the bitwise operators won't work with floating point data-types. In languages that allow casting, you can force bitwise manipulations on floating point data, but there are no guarantees that the result will be a valid float.

Zack, my point, that you may or may not get yet is this...while it may be fun to shuffle bytes around, these are toy applications. You need to move the data around in native-word-size chunks, otherwise, you are wasting valuable computing time that could, if tapped, make your crypto algo that much more secure. For example, if your alg runs on a 32-bit machine and you are dealing in bytes that cost a 32-bit word, a clever attacker with an equivalent machine would have a 4x computing advantage against you even before he starts looking for weaknesses in your algs. So...you should develop your algs to work with LONG ints...so that when you make something good, you can port it to CPP to work with native 32-bit ints.

Cheers.

[Hard Rock]

In fact if you use only logic operators, it does'nt matter if integers are signed or unsigned. That is important only if you use arithmetic
(for example if you use x2 to shift left and \2 to shift right). In that cases you must catch the cases where sign bit exists or changes. It's somewhat tricky....

Really? I have to run some tests again, in C i had large trouble with using signed integers for my LZW code, and upon closer examination, it seemed that the issue was once i shifted the sign bit to being set,right shifting then ignored the signed bit and only shifted the others, giving me very obscure and usless numbers.

Im doing a port to Java now, and i dropped it for now, but ill have to look it up again. Worst case scenerio i can always do one shift, and check if its a negative number, and if so remove it and then do the rest of the math

[na_th_an]

The prob is that << and >> perform logic shifts which screw the sign bit. << and >> should only be used with unsigned data. Many languages (Java, for example) have arithmetic shifts that respect the sign bit. I dunno if C supports them, most likely yes. They are <<< and >>>. Can anybody check? I can't by the mo'.

[Hard Rock]

Many languages (Java, for example) have arithmetic shifts that respect the sign bit

Sweet. Maybe it wont be so difficult to port it after all.

And thanks for clearing that up, so it was the signed int at fault.

[Zack]

No, actually...I don't quite understand what you are saying. :-? I'm a little lacking on my full understanding of this low-level bit stuff.
Anyway, am I right in saying that I would AND the integer in my stated above fashion?