+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11)
+--- Forum: Announcements (https://qb64phoenix.com/forum/forumdisplay.php?fid=18)
+--- Thread: QB64 Phoenix Edition v3.11.0 Released! (/showthread.php?tid=2376)
RE: QB64 Phoenix Edition v3.11.0 Released! - bplus - 01-07-2024
Can you imagine teaching kids to count in base 16 with this!
Quote:0 = 0
1 = 1
2 = 2
3 = 3
4 = 4
5 - 5
6 = -4
7 = -3
8 = -2
9 = -1
Yikes!
RE: QB64 Phoenix Edition v3.11.0 Released! - bplus - 01-07-2024
Look I know I am not going to change computer science with this stuff, just saying if you want consistency between number bases this is the way I would go. You don't need 2 sets of rules for base 10 and NOT base 10.
Sorry this isn't even about QB64pe versions... we'd have to go back in time and waste 1 decmal place for the sign.
RE: QB64 Phoenix Edition v3.11.0 Released! - SMcNeill - 01-07-2024
(01-07-2024, 07:06 PM)bplus Wrote:Quote:-&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.
So you'd have to start writing things such as 3 - -&H1?
3 - &H1 would be different than 3 -&H1? (Which would error out I guess, because you were typing fast and missed that space?)
Or do you have to start writing it as 3 - (&H1), just to be safe?
How the heck is that any easier to keep straight and use?
Why not make it &H-1? Put that minus on the inside of that $H? Of course, you're no longer dealing with base-16 then, but dealing with base-16-plus-sign...
RE: QB64 Phoenix Edition v3.11.0 Released! - mdijkens - 01-07-2024
To be honest I've never been really interested if &h represented itself as a positive or negative decimal number. It's just a decimal representation that hardly never is relevant for your program.
Always when I used &h in my code it was for better readability of that specific value.
Mostly used for example with things like:
Color &hFF008080
SendCommand Chr$(&hFA)
If StatusBits And &h08 Then
I normally expect a program language to automatically type-cast to the needed format.
For example if Color function was defined something like 'void Color (uint32_t fcolor, uint32_t bcolor)' it would not matter what &hFFFFFFFF represents decimally because it would be type-casted to unsigned long.
Same would go for Chr$(uint8_t)
etc.
Not sure if this helps for a future way forward?
RE: QB64 Phoenix Edition v3.11.0 Released! - bplus - 01-07-2024
Quote:Why not make it &H-1? Put that minus on the inside of that $H? Of course, you're no longer dealing with base-16 then, but dealing with base-16-plus-sign...
Sure OK! if it makes things easier or -1 base 16? versus 1 base 16 on the other side of 0 on a number line.
RE: QB64 Phoenix Edition v3.11.0 Released! - zaadstra - 01-07-2024
Nice!
How to program:
PRINT "Parent directory full path: "; _FULLPATH$("../") src:
if you want your.bas be working for Win and for Linux/Mac? I mean, the slash ...
RE: QB64 Phoenix Edition v3.11.0 Released! - zaadstra - 01-07-2024
(01-07-2024, 01:22 PM)mdijkens Wrote: I've been playing a bit more with hex values
Both print -1 nowCode: (Select All)Print &hFFFF
Print &hFFFFFFFF
But
Still print 65536 and 4294967295Code: (Select All)Print Val("&hFFFF")
Print Val(&hFFFFFFFF")
While QBX (7.1, I don't have QB 4.5 anymore) prints -1 and -1
I still have 4.5 if you want it.
RE: QB64 Phoenix Edition v3.11.0 Released! - a740g - 01-08-2024
(01-07-2024, 11:09 PM)zaadstra Wrote: Nice!
How to program:
PRINT "Parent directory full path: "; _FULLPATH$("../") src:
if you want your.bas be working for Win and for Linux/Mac? I mean, the slash ...
QB64-PE will auto-correct slashed based on the platform.
For example, the above code will return the directory name with a forward slash on macOS and Linux. And it will return the directory name with a backslash on Windows.
See example 2 in _FILES$ - QB64 Phoenix Edition Wiki for a way to manually handle path separators based on the OS.
RE: QB64 Phoenix Edition v3.11.0 Released! - RhoSigma - 01-08-2024
(01-08-2024, 12:37 AM)a740g Wrote:(01-07-2024, 11:09 PM)zaadstra Wrote: Nice!
How to program:
PRINT "Parent directory full path: "; _FULLPATH$("../") src:
if you want your.bas be working for Win and for Linux/Mac? I mean, the slash ...
QB64-PE will auto-correct slashed based on the platform.
For example, the above code will return the directory name with a forward slash on macOS and Linux. And it will return the directory name with a backslash on Windows.
See example 2 in _FILES$ - QB64 Phoenix Edition Wiki for a way to manually handle path separators based on the OS.
Guess his question did rater target on the input string than on the result. If the input string uses backslashes like in windows on a LNX/MAC system, is it handled correctly or errors the backslash on LNX/MAC. That's indeed not detailed in the wiki, you just detail the result's behavior on different OS's.
But assume it works as in all other file related commands.
RE: QB64 Phoenix Edition v3.11.0 Released! - a740g - 01-08-2024
(01-08-2024, 08:18 AM)RhoSigma Wrote:Yeah. You are correct. All our filesystem and file I/O functions and statements that take a file / path name does the auto-correct.(01-08-2024, 12:37 AM)a740g Wrote:(01-07-2024, 11:09 PM)zaadstra Wrote: Nice!
How to program:
PRINT "Parent directory full path: "; _FULLPATH$("../") src:
if you want your.bas be working for Win and for Linux/Mac? I mean, the slash ...
QB64-PE will auto-correct slashed based on the platform.
For example, the above code will return the directory name with a forward slash on macOS and Linux. And it will return the directory name with a backslash on Windows.
See example 2 in _FILES$ - QB64 Phoenix Edition Wiki for a way to manually handle path separators based on the OS.
Guess his question did rater target on the input string than on the result. If the input string uses backslashes like in windows on a LNX/MAC system, is it handled correctly or errors the backslash on LNX/MAC. That's indeed not detailed in the wiki, you just detail the result's behavior on different OS's.
But assume it works as in all other file related commands.