Remove most free-standing numeric functions and implement Interpolate trait

[brendanzab]

As part of #4819, this commit removes most of the free-standing wrapper functions from the numeric modules. It also removes the re-exports of the delegated intrinsic and cmath functions in std::{float, f32, f64}.

What does this mean from a user perspective? Most of the functions you normally use are now covered by methods in the numeric trait hierarchy. For example, f32::sin(2.0) would now be written as 2.0f32.sin(), or int::min(1, 2) as 1i.min(&2) (unfortunately the explicit type suffix is needed because Rust can't infer the type).

@jensnockert has also added an Interpolate trait to std::num implemented for float, f64 and f32. This adds the following associated functions:

pub trait Interpolate {
    pub fn linear(x: Self, y: Self, t: Self) -> Self;
    pub fn cosine(x: Self, y: Self, t: Self) -> Self;
    pub fn smooth(x: Self, y: Self, t: Self) -> Self;
    pub fn barycentric(x: Self, y: Self, z: Self, t0: Self, t1: Self) -> Self;
    pub fn hermite(x: Self, xp: Self, y: Self, yp: Self, t: Self) -> Self;
    pub fn cubic(x: Self, y: Self, z: Self, u: Self, t: Self) -> Self;
    pub fn catmull_rom(x: Self, y: Self, z: Self, u: Self, t: Self) -> Self;
}

In addition, I have also added the error functions to std::num::Real:

pub trait Real {
    //...

    pub fn erf(&self) -> Self;
    pub fn erfc(&self) -> Self;

    // ...
}

[brson]

I r+'d this but I'm not at all confident that all these obscure interpolation functions are appropriate for std, nor that they make sense as a trait. In the future please try to put different features in different pull requests.

[brendanzab]

@brson Sure thing, this one got a little out of hand. We'll discuss/debate further in #4819.

[Casorati]

why remove free-standing numeric functions? They are the most intuitive definition of numerical operation. A numerical function does not act on a number (it does not change it), but it maps it to an element form the same or different set. An expression like 2.0f32.sin() is ugly, hard to read and would probably prevent a lot of people (including me) to ever use rust for numerical applications.
You might follow the goal to make rust more consistent but the notation used for numerical functions is very mature and even consistent among different computer languages so in my option it should remain an exception if needed.
Also, as a welcome side effect those free-standing function prevent a misleading use of function names like exp, sin and so on. We can consider them to be reserved for their classical meaning.

[auroranockert]

I agree with you @Casorati partially.

Syntax-wise I think we should allow for the sin(x) option in addition to x.sin(). What will be the 'default' way to call mathematical functions can then be decided by the community.

But I also think it is very important to remove the current free-standing numeric functions. Currently there are at least three different sin(x) which doesn't make sense to me.

The sane way to implement the numeric functions is to

1. First remove the free-standing functions.
2. Then add new generic functions that implement sin(x) &c. for all types that implement x.sin().

Ps. @bjz, could you split up this PR into two? The two groups of changes are completely orthogonal.

[graydon]

The method vs free-standing call thing is part of uniform method calls, which we intend to fix generally. Not sure about schedule.

[Casorati]

Then I think the changes should include the fix instead of forcing a temporary syntax change in existing code.

@JensNockert How can a generic version of a function like sin be defined in rust?

[auroranockert]

@bjz Could you close this PR?

@Casorati I did some changes and split out that part of the PR, so please, could you check it over and maybe leave a comment? (#7090)

[brendanzab]

@JensNockert sure thing! I think this has been a good discussion anyway. :)