String comparison oddity...[SOLVED]

[Pete]

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 Okay

So 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

[bplus]

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!

[SMcNeill]

Except as strings, -11.2 *is* greater than -11.1. You're not comparing numeric values, but instead string (ASCII) values.

[SMcNeill]

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*.

[Pete]

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.

[bplus]

Yeah Steve nailed it! I am a bit distracted in gooey stuff.

[Pete]

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 (_|_)