![]() |
|
Replacement for VAL with &H, &B, &O - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1) +--- Forum: Prolific Programmers (https://qb64phoenix.com/forum/forumdisplay.php?fid=26) +---- Forum: SMcNeill (https://qb64phoenix.com/forum/forumdisplay.php?fid=29) +---- Thread: Replacement for VAL with &H, &B, &O (/showthread.php?tid=3634) |
Replacement for VAL with &H, &B, &O - SMcNeill - 04-24-2025 Code: (Select All)
If you guys weren't aware, VAL has some issues with &H, &B, &O. The values are always unsigned, whereas QB45 and QB64 defaults to signed values unless specified. And the above leads to a second issue as VAL ignores any type symbols, and *only* returns unsigned values. So I've plugged around and made my own little HBO string conversion routine. This *should* return the same values for us as if we typed them into the IDE directly. &HFFFF = -1.... not 65535. (If you want 65535, then add the unsigned suffix or designate it as a long/int64.) I'm not certain who else might need something like this, but for parsing strings and trying to make results match, this is an essential tool. &HFFFF - 1 <--- This should equal -2. Code: (Select All)
If you run the little snippet above, you'll see that it prints -2... but VAL prints 65534. If you're trying to process a string, your math is going to be wrong using VAL. It *shouldn't* be with this routine. This should return the same value you'd get if you typed the result into the IDE directly. I don't swear it works 100% in all cases until I can test it more, but it seems to hold up and do as it should with the minor testing I've tried so far. VAL and &H, &B, &O has just about murdered me this last few days. I'm glad to get this replacement sorted out for my own use, even if nobody else in the world ever makes use of it.
RE: Replacement for VAL with &H, &B, &O - Petr - 04-25-2025 This is an interesting thing. I'll look into it when I'm at my computer in a few hours, but I'm interested in a simple option: Can the data type be determined using Mem.Element or Mem.Type? If so, can I read the decisive bit of the data type to distinguish Signed or Unsigned? If so, all I need to do is add the negative value/2 of the maximum value of the data type to the positive output Val if it's a sign data type. Is this solvable in this way? Basically, I'm asking if it's possible to distinguish data types using Mem, similar to how data types are determined when processing sound with the MemSound function. I'm interested in this for speed, so I want to avoid converting to a string and back. RE: Replacement for VAL with &H, &B, &O - SMcNeill - 04-25-2025 @Petr https://qb64phoenix.com/forum/showthread.php?tid=75 -- See this instead. Use Mem.Type for that info.
RE: Replacement for VAL with &H, &B, &O - Petr - 04-26-2025 Thanks Steve, I'll look into it. RE: Replacement for VAL with &H, &B, &O - madscijr - 04-26-2025 Forgive my ignorance, but what are &H &B and &O? Is there some bug where VAL doesn't work on long variables named H, B or O? But more importantly, if VAL ignores type symbols and only returns unsigned, what good is it? It sounds broken. In the past, I assumed VAL would correctly cast to whatever type the target variable was? Should we just use _CAST for that? RE: Replacement for VAL with &H, &B, &O - SMcNeill - 04-26-2025 &H is HEX &B is Binary &O is Octal So if you just say FFFF, that's a variable called FFFF -- but &HFFFF is the number -1. (It's a signed integer and in hex, a signed integer of FFFF is -1.) X = FFFF << Assigning the variable FFFF's value to X. X = &HFFFF& << Assigning the long hex value of FFFF to X. (65535, in this case.) Same with Binary. 10 = ... well, 10. It's a normal decimal number. &B10 = 2, represented as a binary number. &B101 = 5, and so on. So VAL will work with your variables, but it doesn't work exactly the same as the &H, &B, &O variations do directly from the IDE. PRINT &HFFFF << -- this will print -1 PRINT VAL("&HFFFF") <<-- this will print 65535. Note that in hex, both -1 *and* 65535 are represented by FFFF -- depending on if you have a signed integer or an unsigned integer that you're casting the value to. Both are *correct* answers, but they're not *consistent* -- which is what this little routine works to fix for us. It doesn't mix signed and unsigned and keeps consistent results for us. Think SQR(4).... Both 2 *and* -2 are proper answers to that SQR(4), though we usually only ever deal with the positive result. In this case it would be like saying: PRINT SQR(4) <--- prints 2. PRINT VAL("SQR(4)") <--- prints -2. Both are technically correct, but the results aren't consistent with each other and that can be a real PITA if you're comparing direct values vs string parsed values. RE: Replacement for VAL with &H, &B, &O - madscijr - 04-26-2025 Gotcha, thanks for explaining! |