Floating point traits roundtable

Similar arguments don't hold when going from, for example, imaginary to complex because of infinity. I first read about this distinction in D's motivation to have a separate imaginary type. Specifically,
(1 - ∞ i) i = ∞ + i
but the seemingly equivalent statement written as complex-complex multiplication gives
(1 - ∞ i) (0 + i) = ∞ + NaN i
so that upgrading the imaginary i to a complex number was detrimental to the computation.

1 Like

edit: I was originally trying to reply, but I did not understand the problem.
Possibly my memories about eigen decomposition are too old.

Well ∞ is not a real number. Having ∞ as real or imaginary part of your complex number will cause problems, as it isn't a valid complex number.

That's true (sorry, bad terminology on my part). But my point is addressing the sentiment you expressed here:

If you are intending to address floating point "number" representations which include infinity and NaN for practical numerical applications, your statement above should not ignore the implications of their existence.

I see that you omitted division for Integer. It's clear why: integers are not closed under division, and even though we have a programmatic convention to handle it (i.e. floor division) this shouldn't be a property of the number system itself.

But I also see that you included non-natural exponentiation for Real. If you omit integer division because it's not closed, you have to omit real roots for the same reason if you want to remain consistent.

I feel like trying to shoehorn the complex number hierarchy onto the Rust type system isn't going to be that useful in the end.

Bikeshedding: should FloatingPoint be the name for the general trait that handles fixed-point types? They have a point, but the point isn't floating, it's fixed, that's the point (pun intended). Maybe Real. Or perhaps Point but this can be confusing and ambiguous.

Honestly, I personally treat fixed points similarly to integer. The representations have effectively the same limitations -- each representation is a fixed-precision integer multiple of a fixed unit and supports neither infinity nor NaN. One of them just has a few more multiplicative inverses than the other.

1 Like

I would really prefer to start with a trait only for the primitive floating
point types. I would rather call it PrimFloat or similar to denote this.
Once we have consensus on that we can think of adding a new trait that
extends this to the standard complex types and then maybe another trait
that extends this to fixed precision floats in general. But I really would
like to have these 3 independent traits anyways.

1 Like