QB64 Phoenix Edition v3.11.0 Released!

[bplus]

does _rgb32 ever return a negative?

does Point(x, y) ever return a negative?

I never use &H except for colors therefore I am NOW OFFICIALLY CLAMMERING for _Unsigned Long to be consistent with colors.

I have said before and will say again if you want neg values use -&H, -&B, -&O just exactly like we do with decimal bases. Be consistent!

You just talked me out of updating to 3.11 because you say you are Not using _Unsigned as default for the other bases.

Switching back and forth from _unsigned to NOT really sucks!

When in doubt be consistent, handle other number bases just like we do decimal.

Well this all adds to the argument to get away from using Const all together but then others are arguing for getting way from SHARED variables all together. (That one I really disagree!)
But there are those who say we are too comfortable in our lifestyles already, that it is good to live outside the comfort zone. ; - ) )

I can live with typing Const with a suffix, I only have to do it once.

[SMcNeill]

You just talked me out of updating to 3.11 because you say you are Not using _Unsigned as default for the other bases.

3.10 was the only version which was returning unsigned values for us with CONST.  (Unless you go back to various SDL versions and shortly after.)  Ever since we cloned off from the old team's v2.0.2, CONST has returned signed values.

As for everything else -- they're the same as they've always been.  We've just now started to notice that VAL("&H_number") returned an unsigned value.  QB45 used to return signed values.  DATA returns signed values (I think).  Using them in a variable will return signed values.  CONST is now once again returning signed values.  (As I mentioned; it was only 3.10 which broke that when we fixed something else.)

Test out your old version and test out the new version, and see where you find any changed results.  Everything prior to 3.10 will return the same values that it does now in 3.11.  3.10 was the outlier and got fixed.  

I think you misunderstood:  I'm not saying that we're changing anything to use unsigned as default; I'm saying that some things already use unsigned, and some use signed values -- and it's been that way since forever, it seems.  We're just now noticing behavior which has been in the language for ages.
  
Which is why I'm warning you:  If you want predictable results, always take the time to add that suffix to your &HBO values.  You'll never have issues with &H12345678&&, as you've manually declared it as an unsigned integer64.  Now, &H12345678 may return a signed value, or an unsigned value to you, depending on where/how you end up calling it and using it in your program -- and it's been that way for ages and ages.

Upgrade.  Don't upgrade.  Doesn't matter -- you're still going to end up with different places which will return different values on you.  Just like you always have, and just never noticed in the past.

[SMcNeill]

Code: (Select All)

Print &HFFFF

Const foo = &HFFFF

Print foo

Data &HFFFF

Read foo2

Print foo2

foo3$ = "&HFFFF"

Print Val(foo3$)

For example, the above prints:

-1
-1
65535
65535

Input and Line Input return... I dunno, but it'll be one of those two values...
GET returns... I dunno...

Every place in QB64 seems to handle these functions differently. If you want consistent results, add the suffix yourself and then you'll never need to worry about it.

[bplus]

Forget what I said about upgrading. I just upgraded to 3.10 and am not eager again to do it again and rationalizing not to do it again to myself.

Misunderstanding? yeah, wouldn't be first time.

So now I am curious does POINT( ) or _RGB32() every return a negative?

I think Point does if your Const &H was assumed neg when you drew something with it or no they just won't match! The screen will take your negative &H and convert it to a positive?

I remember something causing a problem when comparing a Point off the screen to a color &H value that was not typed and drawing with the Const color. I even posted it to this forum but damned if I can find it with the Search tool this forum has.

[RhoSigma]

does _rgb32 ever return a negative?

does Point(x, y) ever return a negative?

I never use &H except for colors therefore I am NOW OFFICIALLY CLAMMERING for _Unsigned Long to be consistent with colors.

I have said before and will say again if you want neg values use -&H, -&B, -&O just exactly like we do with decimal bases. Be consistent!

You just talked me out of updating to 3.11 because you say you are Not using _Unsigned as default for the other bases.

Switching back and forth from _unsigned to NOT really sucks!

When in doubt be consistent, handle other number bases just like we do decimal.

Well this all adds to the argument to get away from using Const all together but then others are arguing for getting way from SHARED variables all together. (That one I really disagree!)
But there are those who say we are too comfortable in our lifestyles already, that it is good to live outside the comfort zone. ; - ) )

I can live with typing Const with a suffix, I only have to do it once.

Using -&H etc. isn't bulletproof either, a%=-&HFFFF, so what is it? To be absolutely correct following your logic it must be 1, as &HFFFF seen as a INTEGER (16bit) is already -1 (cause the MSB is set) and the minus sign would negate that value. So -&HFFFF = 1 ??? That's odd, even it's true.

[bplus]

does _rgb32 ever return a negative?

does Point(x, y) ever return a negative?

I never use &H except for colors therefore I am NOW OFFICIALLY CLAMMERING for _Unsigned Long to be consistent with colors.

I have said before and will say again if you want neg values use -&H, -&B, -&O just exactly like we do with decimal bases. Be consistent!

You just talked me out of updating to 3.11 because you say you are Not using _Unsigned as default for the other bases.

Switching back and forth from _unsigned to NOT really sucks!

When in doubt be consistent, handle other number bases just like we do decimal.

Well this all adds to the argument to get away from using Const all together but then others are arguing for getting way from SHARED variables all together. (That one I really disagree!)
But there are those who say we are too comfortable in our lifestyles already, that it is good to live outside the comfort zone. ; - ) )

I can live with typing Const with a suffix, I only have to do it once.

Using -&H etc. isn't bulletproof either, a%=-&HFFFF, so what is it? To be absolutely correct following your logic it must be 1, as &HFFFF seen as a INTEGER (16bit) is already -1 (cause the MSB is set) and the minus sign would negate that value. So -&HFFFF = 1 ??? That's odd, even it's true.

That's bcause you are sticking to old bit paradigm. Sure be consistence to old computer bit math but in Real math FFFF base 16 is the big number and gets bigger with every F you add onto it. You could only make it negative by putting a - sign to it.

Can you imagine doing that with decimal math? It would be confusing as hell 9999 = -1 ha!

[SMcNeill]

POINT returns a DOUBLE.   _RGB32 returns an _UNSIGNED LONG.

Same as always. 

[RhoSigma]

Code: (Select All)

Print &HFFFF

Const foo = &HFFFF

Print foo

Data &HFFFF

Read foo2

Print foo2

foo3$ = "&HFFFF"

Print Val(foo3$)

For example, the above prints:

-1
-1
65535
65535

Input and Line Input return... I dunno, but it'll be one of those two values...
GET returns... I dunno...

Every place in QB64 seems to handle these functions differently. If you want consistent results, add the suffix yourself and then you'll never need to worry about it.

Reading a value from file using INPUT #1,numvar and if the value is written as &H/&O/&B number inside the file will also result in 65535 as its mostly same logic as in DATA is used. This is as far as the given variable type is larger than the input, same is true for INPUT numvar, but here the input logic will also prevent exceeding the var type size, try INPUT a%%, compile and then try enter &FFFF and it will stop accepting more than 2 F's.

[SMcNeill]

Sure be consistence to old computer bit math but in Real math FFFF base 16 is the big number and gets bigger with every F you add onto it.

Except... QB64 is a progamming language where you write programs for the computer. It's got to work in "computer bit math". Your PC doesn't run on base-10 at the end of the day, you know.

And if the only digits you had available for you were 0 through 9, it wouldn't be odd to designate a range for negative numbers.

0 = 0
1 = 1
2 = 2
3 = 3
4 = 4
5 - 5
6 = -4
7 = -3
8 = -2
9 = -1

You can now represent a range from -4 to 5 with the only digits available for you: 0 to 9.

Hex is just 0 to 9 and ABEDEF.... There's no - included in its character set. Your -&H is nothing more than a subtraction operation, and it could very well screw up your expected outcome of a calculation.

For example:

&HFFFF ^ 2

Normally this is (-1) ^ 2, which would give you 1.

-&H1 ^ 2 (this is how you suggest writing it).

- 1 ^ 2 ... you do exponents over subtraction so that = -1.

It's not the same thing at all. You'd more or less have to completely rewrite the rules of math for it to work like you're wanting.

[bplus]

-&H1 ^ 2 (this is how you suggest writing it).

This is (-1)^2

This is subtract one: - &H1

a minus sign next to base letter indicates it's a negative number whereas a space or + sign indicates a positive value in my way of thinking for numbers beyond base 10 consistent with base 10 designations.

You look at the number and see the absolute value then read a - or (space or +) attached to left side to tell which side of 0 it resides on a number line.