+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: Chatting and Socializing (https://staging.qb64phoenix.com/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://staging.qb64phoenix.com/forumdisplay.php?fid=2)
+--- Thread: String comparison oddity...[SOLVED] (/showthread.php?tid=738)
String comparison oddity...[SOLVED] - Pete - 08-05-2022
Can anyone explain the logic here?
Code: (Select All)
a$ = "11.2": b$ = "11.1": PRINT a$ > b$, 11.2 > 11.1 ' Both True - Okay
a$ = "-11.2": b$ = "11.1": PRINT a$ > b$, -11.2 > 11.1 ' Both False - Okay
a$ = "11.2": b$ = "-11.1": PRINT a$ > b$, 11.2 > -11.1 ' Both True - Okay
a$ = "-11.2": b$ = "-11.1": PRINT a$ > b$, -11.2 > -11.1 ' [True (Error)] / False NOT OkaySo testing out number comparison using STRING$() instead of the very limited VAL() function. What i discovered is string$() comparison does a great job, even on very large numbers, decimals included, until you get to comparing two negative string numbers. Note in the last comparison the string evaluation is true and should be false for [-11.2 > -11.1] as it is in the numeric variable comparison.
Pete
RE: String comparison oddity... - bplus - 08-05-2022
It's the difference in lengths QB64 compares -1 to space + "1" (if you don't _trim$) for positive 1 or Compare 33 to 3+nothings might be OK but neg reverses
Could try right alignment of numbers in a fixed size string buffer and skip Val but Val is probably faster, oh but Val won't work for the big strings!
RE: String comparison oddity... - SMcNeill - 08-05-2022
Except as strings, -11.2 *is* greater than -11.1. You're not comparing numeric values, but instead string (ASCII) values.
RE: String comparison oddity... - SMcNeill - 08-05-2022
Asking about the logic, it's alphabetical.
A before B before C...
1 before 2 before 3...
Compare character by character with -11.2 and -11.1
- vs - is SAME
1 vs 1 is SAME
1 vs 1 is SAME
decimal vs decimal is SAME
2 is GREATER than 1.
Result is -11.2 is greater than -11.1 *as strings*.
RE: String comparison oddity...[SOLVED] - Pete - 08-05-2022
(08-05-2022, 06:19 PM)bplus Wrote: It's the difference in lengths QB64 compares -1 to space + "1" (if you don't _trim$) for positive 1 or Compare 33 to 3+nothings might be OK but neg reverses
Could try right alignment of numbers in a fixed size string buffer and skip Val but Val is probably faster, oh but Val won't work for the big strings!
Both are the same lengths, and it happens here when both strings of the same length are negative.
So I get it now...
It compares the neg signs as a string, and the are equal. It then goes on to compare each digit of the string, and when it reaches "2" of a$ it is greater than "1" of b$, so it reports this, which would be correct.
So what I need to do is strip of the neg signs and write a routine to deal with inverting the results. The others with only one neg sign work because the asc value of the neg sign makes it smaller than the either the decimal point or a period.
I should have thought this one through on my own, but a big thanks for the reply.
Pete
Edit: Steve, I was replying to Mark while you were posting. I'm reading your reply now, but as you can see from my reply to mark, I got it.
RE: String comparison oddity...[SOLVED] - bplus - 08-05-2022
Yeah Steve nailed it! I am a bit distracted in gooey stuff.
RE: String comparison oddity...[SOLVED] - Pete - 08-05-2022
Yes, but Steve's post wasn't up while I was responding to yours, and yours got my head cleared to look at it in in a different way. So screw Steve! (Just kidding, I always appreciate his detailed analyses... especially just before my paycheck is signed.)
Pete
<3 (_|_)