Avoiding PartialOrd problems by introducing fast finite floating-point types

[kornel]

@burakumin

I understand your usecase but I suppose me and other people here consider that your proposition for fixing this issue is not satisfying.

Are you referring to the proposition that NaN/Inf is caught via debug assertions and in release mode it's left up to programmer not to produce these values?

@burakumin

is that really impossible for the cases you're mentioning to create a numeric type (let's call it for example ff32) that really excludes NaN and Inf ?

It is possible, and often it is done: via fixed-point arithmetic.

However, floats are usually more convenient to use: f32 has plenty of precision, and the "floating" part is perfect for linear light. OTOH u16.16 while sufficient, requires care and converting to u32, u48.16, etc. Most CPUs also happen to have separate integer and float ALUs, so an algorithm that's part integer part float may use the CPU fully and end up faster than purely-integer algorithm.