&H calculation logic??

[SMcNeill]

A brief example of what's going wrong with the CONST issue that bplus pointed out in the other topic:

Code: QB64: [Select]

1. Dim i As _Unsigned _Integer64
2. i = &HFF '255
3. Print i, "should be 255"
4.  
5. i = &HFFFF '65535
6. Print i, "should be 65535"
7.  
8. i = &HFFFFFF '16777215
9. Print i, "should be 16777215"
10.  
11. i = &HFFFFFFFF '4294967295
12. Print i, "should be 4294967295"
13.  
14.  

Without any sort of forced type specified for &H, shouldn't the value always be unsigned?  What's with this deal of it giving signed byte, then signed integer, then signed long, then signed integer64 results?  If you look close &HFFFF is the exact same value as &HFFFFFFFF -- that can't be right!  Can it??

If this is working as intended for &H values, can someone write us up an explanation to document this behavior?  The variable type that we're assigning values to doesn't change from start to finish above, but the values we get from our &H numbers certainly jumps from one extreme to the other.

I just can't sort out why &HFFFF would become 18-quad-zillion-and-2, rather than a simple 65535.

[SMcNeill]

Oddly enough, digging into the source in qb64.bas, it appears that this is an intentional and intended behavior??

Code: QB64: [Select]

1.             'if no valid extension context was given, assume one
2.             'note: leading 0s have been culled, so LEN(hx$) reflects its values size
3.             e$ = "&&"
4.             If Len(hx$) <= 8 Then e$ = "&" 'as in QBASIC, signed values must be used
5.             If Len(hx$) <= 4 Then e$ = "%" 'as in QBASIC, signed values must be used

The above comes from where we convert &H values into numbers, and it means that:
&HFFFF is negative.
&H10000 is positive.
&HFFFFFFFF is negative.
&H100000000 is positive.
&HFFFFFFFFFFFFFFFF is negative.

Someone should teach counting to our schoolkids using that type of logic!  "If you'll loan me &10000 dollars, I'll happily pay you back &HFFFFFFFF!" 

[RhoSigma]

IMHO, that's correct and correctly intended built into QB64. Since I do programming started back then on the C64 then Amiga500 and finally PCs, one thing I commonly found in almost every manual:

The highest, or speaking correctly the most significant bit (MSB) of an integer number is the so called sign bit. For bytes this is bit #7, for words (integer) #15, for longs #31 and for long longs #63. Whenever that bit is set, the number is to be interpreted as negative unless an explicit type suffix is used to designate it as unsigned.

Unfortunately many people programming todays don't studied informatics or learnd the basics of the binary number system and that causes issues to those people, when they expect a certain result and don't get it. But this is not the fault of the binary system or the sign bit as defined in applicable standards, it's JUST unsufficient knowlege about the internals.

So please don't mess up QB64 its handling of &H/&O/&B numbers, rather encourage people to learn the binary basics, before start complaining about.

And keep in mind:
If you play with bits, then always expect to get bitten....

[SMcNeill]

It just seems off to me that we'd assume that 4 hex are integers, 8 hex are longs, and anything larger are integer64s.

If we're counting in int64, using &H, here's what we get:

Print &H7FFF 'prints 32767
Print &H8000 'prints -32768
Print &HFFFF 'prints -1
Print &H10000 'prints 65535
Print &HFFFFFFFF 'prints -1

We instantly say that 4 hex is an integer, but 5 to 8 hex is a long, and more than 8 hex is an integer64. 

Without any sort of suffix to the value, why wouldn't we count it as always being an integer64, since that's our greatest variable type?  If we want to make it an integer, for example, then all we have to do is assign that value to an integer.  As it is, it means that our hex values aren't going to represent what we'd think they'd actually represent for us over half of the time.

When dealing with longs, what value would you expect FFFF to represent?  I'd expect it to be 65535...  Instead, it's negative one!

Code: QB64: [Select]

1. i& = &HFFFF
2. Print i&, Hex$(i&)

&HFFFF = &HFFFFFFFF.   And that's supposed to be right somehow??

(And even if we make that value &H0000FFFF, to make certain that we hold 8 spots for a long value, those leading zeros get truncated off and we still end up with the -1 that represents an integer value.

If this behavior is the way it's supposed to be, then it's something which needs to be well documented in the wiki somewhere. 

[bplus]

It just seems off to me that we'd assume that 4 hex are integers, 8 hex are longs, and anything larger are integer64s.

If we're counting in int64, using &H, here's what we get:

Print &H7FFF 'prints 32767
Print &H8000 'prints -32768
Print &HFFFF 'prints -1
Print &H10000 'prints 65535
Print &HFFFFFFFF 'prints -1

We instantly say that 4 hex is an integer, but 5 to 8 hex is a long, and more than 8 hex is an integer64. 

Without any sort of suffix to the value, why wouldn't we count it as always being an integer64, since that's our greatest variable type?  If we want to make it an integer, for example, then all we have to do is assign that value to an integer.  As it is, it means that our hex values aren't going to represent what we'd think they'd actually represent for us over half of the time.

When dealing with longs, what value would you expect FFFF to represent?  I'd expect it to be 65535...  Instead, it's negative one!

Code: QB64: [Select]

1. i& = &HFFFF
2. Print i&, Hex$(i&)

&HFFFF = &HFFFFFFFF.   And that's supposed to be right somehow??

Yes thank you. If you want a negative number (n < 0) use the minus sign! I know too simple! ;-))

[SMcNeill]

I guess here's my biggest problem with what we have, illustrated in one simple line of code:

Code: QB64: [Select]

1. Print Val("&HFFFF"), &HFFFF  

The VAL of "&HFFFF" is different than &HFFFF.  One is a signed integer, the other is... whatever VAL is... 

Which is the proper answer for us?  OR are they both proper somehow?  I would think VAL("&HFFFF") would be the same as &HFFFF, but it's not -- not unless we want to convert bases first somehow!  :P

[bplus]

Code: QB64: [Select]

1. Print Val("&HFFFF"), -&HFFFF  
2.  

[jack]

this works

Code: QB64: [Select]

1. Dim i As _Unsigned _Integer64
2. i = &HFF~&&
3. Print i
4. i = &HFFFF~&&
5. Print i
6. i = &HFFFFFF~&&
7. Print i
8. i = &HFFFFFFFF~&&
9. Print i
10.  

[RhoSigma]

We instantly say that 4 hex is an integer, but 5 to 8 hex is a long, and more than 8 hex is an integer64. 

Without any sort of suffix to the value, why wouldn't we count it as always being an integer64, since that's our greatest variable type?  If we want to make it an integer, for example, then all we have to do is assign that value to an integer.  As it is, it means that our hex values aren't going to represent what we'd think they'd actually represent for us over half of the time.

Well, guess that depends on POV, I have never questioned this behavior in 30 years, I found it that way almost everywhere, so I assumed it as standard and worked with it. However, if you ask why it is as it is, then I'd guess it's for historical reasons. We first had 8bit computer architecturs, then 16bit, 32bit and now 64bit, and the programming languages probably always tried to waste as little memory as possible, so if a value fits into a byte, then its a byte, then a word, long...., and with it interpreting the respective sign bit for the smallest possible data type.