Page 1 of 1

Sollution to handling unsigned integers! (no new type needed

Posted: Wed Dec 16, 2009 6:37 am
by Joakim Christiansen
Working with servers would be a lot more easy if PB were to support unsigned integers! And no, no need to make a new data type and bla bla (which I know scares the developers), why not just let us CONVERT the value into being signed? If it is not too high we wont have a problem! (And yes if in doubt, a unsigned long CAN currently be saved in a long, it just wont be READ right; it is treated like a signed long)

Code: Select all

signedLong.l = uLongToLong(ulong.l)
But what's even better is that we could just put it in a quad!

Code: Select all

quad.q = uLongToQuad(ulong.l) ;No problem if it's put in a quad!!
The same could also be done for the other unsigned types, so please think about it!

Re: Sollution to handling unsigned integers! (no new type needed

Posted: Wed Dec 16, 2009 7:39 am
by Kaeru Gaman
the only difference between signed and unsigned is the interpretation of the Most Significant Bit.
with unsigned, it is plus MSB-Value, with signed it is minus MSB-Value.
for type word this means, either +32768 or -32768.
when you recieve a value, it has several bits set or not, but it will be the same, no matter if you interprete it signed or unsigned.

every unsigned value can loslessly be put into a signed variable, because they are just the same, only the interpretation differs.

Code: Select all

a.w = %1001010110101101
b.l = %1001010110101101
Debug a
Debug b

c.w = -27219
d.w =  38317

Debug Bin(c,#PB_Word)
Debug Bin(d,#PB_Word)
when you want to recieve an unsigned Long, just recieve a Long, it will be the correct value.

only when you want to display it, you'll need to display the MSB as positive value not as negative,
so you should use a bigger container, quad in this case, to make it a value-bit and no longer the sign-bit.
when transferring the value, use the bit operator & to make sure this will happen.

Code: Select all

a.l = %10010101101011011001010110101101

Debug a
Debug Bin( a, #PB_Long )

b.q = a & $FFFFFFFF

Debug b

Debug Right( Bin( b, #PB_Quad ), 32 )
you can put the &-Operation into a Macro, if you want it to look like a function.

Code: Select all

Macro LongToULong( _LVal_ )
 ( ( _LVal_ ) & $FFFFFFFF )
EndMacro
some uLongToLong is just not needed, as you saw above, you can just put the unsigned value into the signed variable, the bits will be set correctly.

you can see this when you e.g. try to assign 260 to a Byte:
the parser will tell you that a Byte has to be -128 to 255,
that means, both signed or unsigned can be assigned without problems.

Re: Sollution to handling unsigned integers! (no new type needed

Posted: Wed Dec 16, 2009 7:49 am
by freak
> And no, no need to make a new data type and bla bla (which I know scares the developers)

yeah, right :roll:

Re: Sollution to handling unsigned integers! (no new type needed

Posted: Wed Dec 16, 2009 7:56 am
by Thorium
Some nativ operators for unsignt would nice. You currently cant compare high values. For example -1 > 0 is false for signed but should be true for unsigned. I actualy had some bugs releated to that problem. You would not need a new datatype for that, just a second set of operators.

Re: Sollution to handling unsigned integers! (no new type needed

Posted: Wed Dec 16, 2009 9:52 am
by Kaeru Gaman
two new datatypes ( uLong + uQuad ) would be easier than a new set of operators, I presume... :o

Re: Sollution to handling unsigned integers! (no new type needed

Posted: Wed Dec 16, 2009 9:59 am
by Thorium
Kaeru Gaman wrote:two new datatypes ( uLong + uQuad ) would be easier than a new set of operators, I presume... :o
The purebasic team allready decided to not include unsignt long and quad into purebasic because of performance problems in expressions. If i understood it right. So a second set of operators would be a alternativ. That would enable the programer to decide how variable are treated. The compiler would not need to decide it. Which is what the pb developer want to avoit.

Re: Sollution to handling unsigned integers! (no new type needed

Posted: Wed Dec 16, 2009 10:37 am
by Mistrel
Wouldn't "<<" and ">>" be considered viable alternative operators, which already exist? :?

Re: Sollution to handling unsigned integers! (no new type needed

Posted: Wed Dec 16, 2009 5:08 pm
by Thorium
Mistrel wrote:Wouldn't "<<" and ">>" be considered viable alternative operators, which already exist? :?
No. That are operators for bit shifting not for comparing.

Re: Sollution to handling unsigned integers! (no new type needed

Posted: Wed Dec 16, 2009 5:49 pm
by Demivec
Kaeru Gaman wrote:only when you want to display it, you'll need to display the MSB as positive value not as negative,
so you should use a bigger container, quad in this case, to make it a value-bit and no longer the sign-bit.
when transferring the value, use the bit operator & to make sure this will happen.
@Kaeru Gaman: just a small note, you can display values as unsigned using StrU(value,type). This allows you to display even a quad as unsigned and allows you to do so without putting the value into a larger container.

Re: Sollution to handling unsigned integers! (no new type needed

Posted: Wed Dec 16, 2009 6:35 pm
by Kaeru Gaman
thnx Demivec.
I often happen to forget this function.