Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
QB64 Phoenix Edition v3.11.0 Released!
#32
While I'm sure I can adjust either way, this business about signed hex creates a real problem with consistency.

In order to make signed hex, or signed binary, work correctly by default, you have to make assumptions about word length. So for example, &hffff &hffffffff only returns a -1 if we all agree that we'll only use exclusively 16-bit or 32-bit signed numbers. Try 8-bit or other word lengths and this won't work.

So here's the deal. Don't know about everyone else, but in my work I use 6, 8, 12, 24-bit numbers, to name just a few, all of the time. Sometimes they are signed, other times they are unsigned. So to me, having a consistent way for this to work saves me having to check this out every single time I encounter a different length of number.

And crucially, the only "consistent way" for this to work is to always assume unsigned, and then let the user accommodate the sign, if necessary, in his program.

Here are some inconsistent results as of now:

-------------------
In each case, the binary number is all 1s.

8-bit:  255 (I think we can agree, 8-bit numbers are commonplace?)
Using Val(): 255

16-bit: -1
Using Val(): 65535

12-bit:  4095
Using Val(): 4095

24-bit:  16777215
Using Val(): 1.677722E+07

32-bit: -1
Using Val(): 4.294967E+09
-----------------------

That's the problem, as I see it. Mind you, the way Val works now, for me, is perfect! But as Steve ominously said, it's "wrong"(???)

Aaargh.
Reply


Messages In This Thread
QB64 Phoenix Edition v3.11.0 Released! - by a740g - 01-03-2024, 05:45 PM
RE: QB64 Phoenix Edition v3.11.0 Released! - by bert22306 - 01-08-2024, 10:27 PM



Users browsing this thread: 8 Guest(s)