integers shouldn't implement num::Round

[brson]

They don't have a sensible implementation.

[brendanzab]

Related: #4788

[brendanzab]

In my current implementation on my own fork, I've put these in a Float trait where they seem to make more sense. (see my follow-up comment) If genericism and future-proofing is a concern, we could always shift these into a separate Round trait ie:

pub trait Round {
    pure fn ceil(&self) -> Self;
    pure fn floor(&self) -> Self;
    pure fn round(&self) -> Self;
    pure fn trunc(&self) -> Self;
}

But I definitely feel that the current implementation is over-engineered, and rounding functions should not be impled on integer types.

[brendanzab]

Here is the current implementation:

libcore/num/num.rs

pub trait Round {
    pure fn round(&self, mode: RoundMode) -> Self;

    pure fn floor(&self) -> Self;
    pure fn ceil(&self) -> Self;
    pure fn fract(&self) -> Self;
}

pub enum RoundMode {
    RoundDown,
    RoundUp,
    RoundToZero,
    RoundFromZero
}

libcore/num/int-template.rs

impl T: num::Round {
    #[inline(always)]
    pure fn round(&self, _: num::RoundMode) -> T { *self }

    #[inline(always)]
    pure fn floor(&self) -> T { *self }
    #[inline(always)]
    pure fn ceil(&self) -> T { *self }
    #[inline(always)]
    pure fn fract(&self) -> T { 0 }
}

libcore/num/float.rs

impl float: num::Round {
    #[inline(always)]
    pure fn round(&self, mode: num::RoundMode) -> float {
        match mode {
            num::RoundDown
                => f64::floor(*self as f64) as float,
            num::RoundUp
                => f64::ceil(*self as f64) as float,
            num::RoundToZero if is_negative(*self)
                => f64::ceil(*self as f64) as float,
            num::RoundToZero
                => f64::floor(*self as f64) as float,
            num::RoundFromZero if is_negative(*self)
                => f64::floor(*self as f64) as float,
            num::RoundFromZero
                => f64::ceil(*self as f64) as float
        }
    }

    #[inline(always)]
    pure fn floor(&self) -> float { f64::floor(*self as f64) as float}
    #[inline(always)]
    pure fn ceil(&self) -> float { f64::ceil(*self as f64) as float}
    #[inline(always)]
    pure fn fract(&self) -> float {
        if is_negative(*self) {
            (*self) - (f64::ceil(*self as f64) as float)
        } else {
            (*self) - (f64::floor(*self as f64) as float)
        }
    }
}

[brendanzab]

To follow up, I've moved the rounding functions into a separate trait. I think that's a better design actually. I haven't replicated pure fn round(&self, mode: RoundMode) -> Self – I think that's abit over-engineered, and doesn't really have a place in the core lib.

[kud1ing]

I feel a bit uneasy about a Round trait without any other constraints.
People could implement Round on e.g. strings/chars.

Haskell declares round in typeclass RealFrac, which is an extension of typeclasses Real + Fractional:
http://www.bucephalus.org/text/Haskell98numbers/Haskell98numbers.png

I think having a Fractional trait would not be a bad idea.

[brendanzab]

Ooh, that's very handy. Thank you!

[brendanzab]

@kud1ing: how about this?

trait Eq {
    fn eq(&self, other: &Self) -> bool;
    fn ne(&self, other: &Self) -> bool;
}

trait Ord {
    fn lt(&self, other: &Self) -> bool;
    fn le(&self, other: &Self) -> bool;
    fn ge(&self, other: &Self) -> bool;
    fn gt(&self, other: &Self) -> bool;

    // These will be handled using default implementations, but can be
    // specialised, for example using cmath functions
    fn min(&self, other: &Self) -> Self;
    fn max(&self, other: &Self) -> Self;
    fn clamp(&self, mn: &Self, mx: &Self) -> Self;
}

trait Num: Eq
           Neg<Self>
           Add<Self,Self>
           Sub<Self,Self>
           Mul<Self,Self> {
    // These will be handled using default implementations
    fn abs(&self) -> Self;
    fn signum(&self) -> Self;
}

trait Real: Ord Num {
}

trait Floating: Real
                Div<Self,Self>
                Mod<Self,Self> {
    static pure fn NaN() -> Self;
    static pure fn infinity() -> Self;
    static pure fn neg_infinity() -> Self;

    pure fn is_NaN(&self) -> bool;
    pure fn is_infinite(&self) -> bool;
    pure fn is_finite(&self) -> bool;

    static pure fn pi() -> Self;
    static pure fn two_pi() -> Self;
    static pure fn frac_pi_2() -> Self;
    static pure fn frac_pi_4() -> Self;
    static pure fn frac_1_pi() -> Self;
    static pure fn frac_2_pi() -> Self;
    static pure fn frac_2_sqrtpi() -> Self;
    static pure fn sqrt2() -> Self;
    static pure fn frac_1_sqrt2() -> Self;
    static pure fn e() -> Self;
    static pure fn log2_e() -> Self;
    static pure fn log10_e() -> Self;
    static pure fn ln_2() -> Self;
    static pure fn ln_10() -> Self;

    pure fn abs_sub(&self, b: Self) -> Self;
    pure fn mul_add(&self, b: Self, c: Self) -> Self;
    pure fn modf(&self) -> (Self, Self);
    pure fn nextafter(&self, y: Self) -> Self;

    pure fn recip(&self) -> Self;

    pure fn ceil(&self) -> Self;
    pure fn floor(&self) -> Self;
    pure fn round(&self) -> Self;
    pure fn trunc(&self) -> Self;

    pure fn pow(&self, e: Self) -> Self;
    pure fn sqrt(&self) -> Self;
    pure fn invsqrt(&self) -> Self;
    pure fn cbrt(&self) -> Self;
    pure fn exp(&self) -> Self;
    pure fn expm1(&self) -> Self;
    pure fn exp2(&self) -> Self;
    pure fn frexp<I:Int>(&self) -> (Self, I);
    pure fn ldexp<I:Int>(&self, n: I) -> Self;
    pure fn ldexp_radix<I:Int>(&self, i: I) -> Self;
    pure fn ln(&self) -> Self;
    pure fn log_radix(&self) -> Self;
    pure fn ln1p(&self) -> Self;
    pure fn log2(&self) -> Self;
    pure fn log10(&self) -> Self;
    pure fn logarithm(&self, b: Self) -> Self;
    pure fn ilog_radix<I:Int>(&self) -> I;
    pure fn erf(&self) -> Self;
    pure fn erfc(&self) -> Self;
    pure fn lgamma<I:Int>(&self) -> (Self, I);
    pure fn tgamma(&self) -> Self;

    pure fn sin(&self) -> Self;
    pure fn cos(&self) -> Self;
    pure fn tan(&self) -> Self;
    pure fn sinh(&self) -> Self;
    pure fn cosh(&self) -> Self;
    pure fn tanh(&self) -> Self;
    pure fn asin(&self) -> Self;
    pure fn acos(&self) -> Self;
    pure fn atan(&self) -> Self;
    pure fn atan2(&self, b: Self) -> Self;
    pure fn hypot(&self, b: Self) -> Self;

    pure fn j0(&self) -> Self;
    pure fn j1(&self) -> Self;
    pure fn jn<I:Int>(&self, n: I) -> Self;
    pure fn y0(&self) -> Self;
    pure fn y1(&self) -> Self;
    pure fn yn<I:Int>(&self, n: I) -> Self;
}

trait Integer: Real
               SigNum
               Div<Self,Self>
               Mod<Self,Self> {
    fn div_mod(&self, other: &Self) -> (Self,Self);

    fn even(&self) -> bool;
    fn odd(&self) -> bool;
}

trait Bounded {
    static pure fn min_bound() -> Self;
    static pure fn max_bound() -> Self;
}

trait Int: Integer
           Bounded
           Not<Self>
           BitOr<Self,Self>
           BitXor<Self,Self>
           Shl<Self,Self>
           Shr<Self,Self> {
}

[brendanzab]

@pcwalton ping^

[pcwalton]

Sounds good to me… I don't have much of an opinion here, really.

[Kimundi]

As the one who is responsible for this trait, I fully agree that implementing it on integers is not a good solution, but together with the generic NaN/inf functions (#4788) it was necessary for the str conversion functions in num to work on all numbers. (Which in itself might be a bad idea, I don't know.)

However, I think that at least having the Roundmode is worthwhile (and, again, necessary for the conversions functions to work), as it really just allows to treat rounding in a symmetric way in regards to the sign.
floor and ceil are, although historical, really just special cases for 'round towards +inf' and 'round towards -inf'. Comparison:

• RoundUp - round towards +inf, absolute value of two numbers only differing in sign could be different.
• RoundDown - round towards -inf, absolute value of two numbers only differing in sign could be different.
• RoundToZero - round towards 0, absolute value of two numbers only differing in sign is identical.
• RoundFromZero - round towards -inf for negative values, and +inf for positive values, absolute value of two numbers only differing in sign is identical.

It's really just about considering the sign.

[Kimundi]

Also, for the Bounded trait, maybe it might make sense to have a more general 'Limits' trait where upperLimit and lowerLimit would be defined as one of:

• NoLimit - For things like bigints that can grow infinite.
• WeakLimit - Highest exact value on numbers that handle infinity in a special way. For example, the highest exact value of an f32 is ~3.4×10^38, but the highest possible but not exact value is inf.
• HardLimit - Highest exact value on numbers that don't handle infinity in a special way, like ints.

[auroranockert]

@Kimundi While I don't think that having a RoundingMode argument really makes sense when compared to just having multiple methods, the most important problem here is that you've missed the IEEE754 default rounding mode, round-to-even. (Maybe something like this? https://gist.github.com/JensNockert/4719287/raw/65c32ad7eb64e67b55b107e5afb4dfe6e6f6dac6/rounding.rs)

When it comes to a bounded trait, we could just check http://www.cplusplus.com/reference/limits/numeric_limits/ for example, I assume they have been thinking and arguing about this for a very long while and it seems quite sane.

[kud1ing]

@bjz: Nice. I am not sure, whether separate Neg, Add, Sub, Mul are necessary. Also not sure about Real.

Maybe we should create a Wiki page for this, explaining what traits we need and what for.
Could also serve as big-picture documentation, when stuff is implemented.

[kud1ing]

ping @erickt (added Zero and One)