Is the Real trait is too broad? (or too specialized)

[omalaspinas]

I think it would be beneficial to have traits for functions (exp, sin, pow, ...) that are separate from numbers (partialOrd, Signed, ...). For example, when one wants to use complex numbers (since ComplexNumbers are now implementing a lot of the alga traits now) it is not uniquely defined how to order them. Nevertheless it would be great to be able to have the exp, log, ... functions in a trait without requiring them to be ordered in any way. It would be an equivalent of the Num, NumOps trait of the num_trait crate.

What do you think?

[Coder-256]

+1!!! This is related to my issue dimforge/nalgebra#503. I am trying to represent a qubit as a vector of 2 complex numbers, but that would mean that I can't use most functions, because almost all of them require passing a Real. The vast majority of the methods of the Real trait are in no way specific to real numbers. In fact, of the 55 required methods, I'd argue that only the following 8 do not also make sense on complex numbers:

• floor
• ceil
• round
• trunc
• fract
• signum
• is_sign_positive
• is_sign_negative

This could be fixed by simply moving all but these 8 methods into a new trait ComplexTrait, then making Real a subtrait of ComplexTrait.

However, I think that a better solution would be to group related methods into their own traits. For example, separate traits for trigonometry, hyperbolic trigonometry, logarithms, fractions/rounding, and sign. That way, library authors could require only the traits they use. For example:

pub trait Complex:
    ...
    + Trigonometry            # sin, cos, tan, plus reciprocals and inverses
    + HyperbolicTrigonometry  # sinh, cosh, tanh, plus reciprocals and inverses
    + Logarighms              # ln, log2, e, log2_e, ln_1p, etc.
{
...                           # Not much goes here (most is inherited)
}

pub trait Real:
    ...
    + Complex
    + Fractions               # floor, ceil, round, etc.
    + Signed                  # signum, is_sign_positive, is_sign_negative
{
...                           # Not much goes here (most is inherited)
}

(You would probably want to name the traits better than I have)

The best part of this is that it would be 100% backwards compatible as the resulting interface for Real is the same as before. However, I would like to propose one breaking change, which is not requiring Any, Debug, or especially 'static on any interface. Developers can write Real + 'static for any function that needs a static lifetime, but otherwise this literally forces a memory leak on all numbers.

TL;DR Most methods of Real also apply to complex numbers, so IMO Real should be a subtrait of ComplexTrait.

[omalaspinas]

Actually I would even not have a specific number name. They could be arranged in whatever traits: transcendental, algebraic, ... (I am very bad at making this kind of naming and regrouping :-)). The vast majority of these functions which are applied to tuples of real numbers basically can implement all these functions (dual numbers or quaternions for example) so I would not have a naming for a specific kind of number.

[Coder-256]

@mathintro I had considered that, but here's why I think it would be better to use separate traits. Let's say for example that I have a function that does some complex trigonometric operation using lots of sin, cos, etc. What traits should my function accept? If all I do is call trigonometric functions, then I should be able to specify only what I use (trigonometry, addition/multiplication/etc., and only the operations I need). That way, if people want to make some sort of strange abstract representation of a number, they're not also tied to all these other traits (bounded, etc.)

The downside to this is that things might get a bit messy, though I'd want to look into how things would turn out in practice. Currently I'm experimenting with forking num_traits to add more expressive traits for number systems (complex, real, rational, integer, etc.) and operations like I've explained.

[omalaspinas]

I completely agree. I was more thinking about not having explicitly a ComplexTrait because the name would be misleading. These operations can be applied on very different kind of numbers.
I don't know what the @sebcrozet and @jswrenn might think about these things.

[sebcrozet]

Hey! Sorry for the late answer. I've not read this issue in-depth yet but I just wanted to tell that we agree this is an issue and that this is necessary for improving support of complex number in alga (and nalgebra).
Better complex number support is one of our goals for 2019!

I will start studying the subject more closely next month.

[sebcrozet]

Hey! Just so you know, I've started working on better Complex support. Hopefully I'll have a PR open within the next few weeks.

[Coder-256]

@sebcrozet Just curious, how do you plan to reconcile Real with complex numbers? There is lots of overlap. I am also working on my own version of this (as a separate fork) and the only way I found was to completely change the Real trait beyond any hope of backwards compatibility, which is why I'm using my own fork.

[sebcrozet]

@Coder-256 Yes, this will be breaking change! I'm basically splitting the Real trait in two. I'd be interested in taking a look at your fork by the way! I'll probably open a PR about this this week-end.

[Coder-256]

@sebcrozet You've got me interested now, I'm very curious to see what you're planning. Anyway here is my branch for now (in my own, separate project). I decided to fork into my own project because I plan to steer development away from just num-traits and make a comprehensive algebraic library like alga but with better support for complex numbers. However now that num-traits is being updated, I wonder if I might just be able to pull it in as a dependency rather than developing a similar project separately.