Re^6: Problem with a sort result: weird subtraction behaviour?

Discipulus, rdfield, you are both correct: This is a problem with long integers.

What I don't understand is: Why are the integers correctly remembered, correctly displayed, but incorrectly compared to 0 ? Because, let's face it, it's the core of the problem:

When it's a "small" number, it is correctly evaluated as positive, negative, or null.

When it is a "big" number, then there may be problems in evaluating the sign. Much like if some bit from the big number was used as a sign bit, or whatever, where the real good practice would merely be to check the sign at the start of the number string...

I mean, if it starts with a "+" or a digit, then it's positive. If it starts with a "-", it's negative. We keep that "sign", unless all digits are 0 -> in which case it is merely null.

Did I miss something, there ?

Comment on Re^6: Problem with a sort result: weird subtraction behaviour?

Replies are listed 'Best First'.
Re^7: Problem with a sort result: weird subtraction behaviour? by choroba (Cardinal) on Jan 27, 2016 at 18:47 UTC
The problem is that the code that implements the behaviour is in C. There's no number string, there are different integer types with different byte sizes. ($q=q:Sq=~/;[c](.)(.)/;chr(-\|\|-\|5+lengthSq)`"S\|oS2"`map{chr \|+ord }map{substrSq`S_+\|`\|}3E\|-\|`7**2-3:)=~y+S\|`+$1,++print+eval$q,q,a, [download]	[reply] [d/l]