Forums Bug Reports /filter sort bug

Since a long time ago I've known that /filter has trouble sorting rather large numbers, even if those numbers can still be interpreted validly in an if statement. I did a search and could not find this reported, so I guess I simply forgot to report it in all this time.

Observe the following example:



After issuing this, the window @@ will contain the filtered results. You'll notice that the 40521140400 is first in the list followed by 719036000000, which of course is not correct because:

//if (719036000000 < 40521140400) echo -a true

does not echo.

I was wondering to report this as a feature suggestion or a bug, but choose for the latter, since these numbers are not big enough yet for mIRC to become any sort of problem. $calc can manage them fine, so can an if comparison, so I don't see why /filter shouldn't be able to handle them.

Btw, currently I am zeropadding all numbers and doing an alphabetic sort as a workaround, but I would prefer to be able to have it work in the regular way.

mIRC 6.16, Windows XP+SP2

Wierd bug, i tried some varrying numbers and couldnt seem to find any regularity to where / why some are in the wrong position.



You could use the -a options and use an alias to correctly sort them, but I guess if its down to size and time, zero padding and even unpadding would be faster than using scripted high/low/equal checks.

--edit-- removed the last sentence, since your obviously just showing an example (i wasnt thinking overly hard tonighht)

-a is out of the question for me, it's far too slow for the amount that I'm filtering (and I'm doing it quite often).

Zero padding as I have it currently is ok because they only need to be padded once when a number is added, and unpadding is a matter of using a $calc on it, but it's still a workaround for something that could be improved imo. As you might have guessed, this is for a database of player's statistics, which need to be easily filtered to create top statistics.

I wish I had reported this earlier (on 6.14 I already noticed this), though I totally forgot about it.