This isn't accurate. It's true for positive numbers, and when comparing a positive to a negative, but false for comparisons between negative numbers. Standard floating point uses sign-magnitude representation, while signed integers these days use 2s-complement. On negative numbers, comparisons are reversed between these two encodings. Incrementing a float as if it were an integer will, in ordinary circumstances, get you the next one larger in magnitude, but with the same sign -- i.e., you go up for positives but down for negatives. Whereas with signed integers, you always go up except when there's an overflow into the sign bit.

A more correct version of the statement would be that comparison is the same as on sign-magnitude integers. Of course, this still has the caveats you already mentioned.

▲

adgjlsfhk1 5 days ago | parent | next [-]

One of the unambiguously nice things about Posits (unlike floats) is that they use a 2s compliment scheme which makes it actually true for all values that they sort like integers.

▲

Sniffnoy 5 days ago | parent [-]

I was going to say "well, you've still got NaR", but apparently that's been defined to sort less than all other posits? Huh, OK.

	▲	adgjlsfhk1 4 days ago \| parent [-]
		yeah. having a total order just makes everything so much nicer. total order is one of the defining properties of the reals, and realistically if the user calls sort (or puts one in a B-tree), you have to put the NaNs at one side or the other (unless you're C/C++ and allow that to launch the nukes)

▲

ridiculous_fish 5 days ago | parent | prev [-]

You're right, thank you for the correction.