Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
String comparison oddity...[SOLVED]
#5
(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.
Reply


Messages In This Thread
String comparison oddity...[SOLVED] - by Pete - 08-05-2022, 06:00 PM
RE: String comparison oddity... - by bplus - 08-05-2022, 06:19 PM
RE: String comparison oddity...[SOLVED] - by Pete - 08-05-2022, 06:34 PM
RE: String comparison oddity... - by SMcNeill - 08-05-2022, 06:21 PM
RE: String comparison oddity... - by SMcNeill - 08-05-2022, 06:27 PM
RE: String comparison oddity...[SOLVED] - by Pete - 08-05-2022, 07:16 PM



Users browsing this thread: 1 Guest(s)