As part of the numeric trait reform (see issue #4819), I have added the following traits to `core::num` and implemented them for Rust's primitive numeric types:
~~~rust
pub trait Bitwise: Not<Self>
+ BitAnd<Self,Self>
+ BitOr<Self,Self>
+ BitXor<Self,Self>
+ Shl<Self,Self>
+ Shr<Self,Self> {}
pub trait BitCount {
fn population_count(&self) -> Self;
fn leading_zeros(&self) -> Self;
fn trailing_zeros(&self) -> Self;
}
pub trait Bounded {
fn min_value() -> Self;
fn max_value() -> Self;
}
pub trait Primitive: Num
+ NumCast
+ Bounded
+ Neg<Self>
+ Add<Self,Self>
+ Sub<Self,Self>
+ Mul<Self,Self>
+ Quot<Self,Self>
+ Rem<Self,Self> {
fn bits() -> uint;
fn bytes() -> uint;
}
pub trait Int: Integer
+ Primitive
+ Bitwise
+ BitCount {}
pub trait Float: Real
+ Signed
+ Primitive {
fn NaN() -> Self;
fn infinity() -> Self;
fn neg_infinity() -> Self;
fn neg_zero() -> Self;
fn is_NaN(&self) -> bool;
fn is_infinite(&self) -> bool;
fn is_finite(&self) -> bool;
fn mantissa_digits() -> uint;
fn digits() -> uint;
fn epsilon() -> Self;
fn min_exp() -> int;
fn max_exp() -> int;
fn min_10_exp() -> int;
fn max_10_exp() -> int;
fn mul_add(&self, a: Self, b: Self) -> Self;
fn next_after(&self, other: Self) -> Self;
}
~~~
Note: I'm not sure my implementation for `BitCount::trailing_zeros` and `BitCount::leading_zeros` is correct for uints. I also need some assistance creating appropriate unit tests for them.
More work needs to be done in implementing specialized primitive floating-point and integer methods, but I'm beginning to reach the limits of my knowledge. Please leave your suggestions/critiques/ideas on #4819 if you have them – I'd very much appreciate hearing them.
I have also added an `Orderable` trait:
~~~rust
pub trait Orderable: Ord {
fn min(&self, other: &Self) -> Self;
fn max(&self, other: &Self) -> Self;
fn clamp(&self, mn: &Self, mx: &Self) -> Self;
}
~~~
This is a temporary trait until we have default methods. We don't want to encumber all implementors of Ord by requiring them to implement these functions, but at the same time we want to be able to take advantage of the speed of the specific numeric functions (like the `fmin` and `fmax` intrinsics).
r? @brson
Unwinding through macros now happens as a call to the trait function `FailWithCause::fail_with()`, which consumes self, allowing to use a more generic failure object in the future.
The "unsigned 4 byte" `ub4`s are actually 8 bytes on 64-bit platforms
which mean that some bits > 2**32 were retained in calculations, these
would then "reappear" after a right shift and so the stream of random numbers
would differ on 32 bit vs 64 bit platforms.
http://burtleburtle.net/bob/c/randport.c
This removes the comparison to manual memory management examples,
because it requires too much existing knowledge. Implementing custom
destructors can be covered in the FFI tutorial, where `unsafe` is
already well explained.
This is a temporary trait until we have default methods. We don't want to encumber all implementors of Ord by requiring them to implement these functions, but at the same time we want to be able to take advantage of the speed of the specific numeric functions (like the `fmin` and `fmax` intrinsics).
This means that `ub4`s are always 4 bytes, rather than being 8 bytes on
x64. (Suggested but not implemented by upstream: "Porting it to a 64-bit
machine [...] may just need an adjustment of the definition of ub4")
Having three traits for primitive ints/uints seemed rather excessive. If users wish to specify between them they can simply combine Int with either the Signed and Unsigned traits. For example: fn foo<T: Int + Signed>() { … }
I didn't know how to use "use" initially, and an error message like this would
have solved quite a bit of frustration. I think this properly handles cases
where it's not appropriate but I'm not sure.
r? @graydon
Sorry, this pull request is a few different things at once, but I tried to make them separate commits.
First, as before, this should do file searching the way that's described in the doc now.
Second, there's also some preliminary work on the install command (really just tests for it).
As part of the numeric trait reform (see issue #4819), I have added the following traits to `core::num` and implemented them for floating point types:
~~~rust
pub trait Round {
fn floor(&self) -> Self;
fn ceil(&self) -> Self;
fn round(&self) -> Self;
fn trunc(&self) -> Self;
fn fract(&self) -> Self;
}
pub trait Fractional: Num
+ Ord
+ Round
+ Quot<Self,Self> {
fn recip(&self) -> Self;
}
pub trait Real: Signed
+ Fractional {
// Common Constants
fn pi() -> Self;
fn two_pi() -> Self;
fn frac_pi_2() -> Self;
fn frac_pi_3() -> Self;
fn frac_pi_4() -> Self;
fn frac_pi_6() -> Self;
fn frac_pi_8() -> Self;
fn frac_1_pi() -> Self;
fn frac_2_pi() -> Self;
fn frac_2_sqrtpi() -> Self;
fn sqrt2() -> Self;
fn frac_1_sqrt2() -> Self;
fn e() -> Self;
fn log2_e() -> Self;
fn log10_e() -> Self;
fn log_2() -> Self;
fn log_10() -> Self;
// Exponential functions
fn pow(&self, n: Self) -> Self;
fn exp(&self) -> Self;
fn exp2(&self) -> Self;
fn expm1(&self) -> Self;
fn ldexp(&self, n: int) -> Self;
fn log(&self) -> Self;
fn log2(&self) -> Self;
fn log10(&self) -> Self;
fn log_radix(&self) -> Self;
fn ilog_radix(&self) -> int;
fn sqrt(&self) -> Self;
fn rsqrt(&self) -> Self;
fn cbrt(&self) -> Self;
// Angular conversions
fn to_degrees(&self) -> Self;
fn to_radians(&self) -> Self;
// Triganomic functions
fn hypot(&self, other: Self) -> Self;
fn sin(&self) -> Self;
fn cos(&self) -> Self;
fn tan(&self) -> Self;
// Inverse triganomic functions
fn asin(&self) -> Self;
fn acos(&self) -> Self;
fn atan(&self) -> Self;
fn atan2(&self, other: Self) -> Self;
// Hyperbolic triganomic functions
fn sinh(&self) -> Self;
fn cosh(&self) -> Self;
fn tanh(&self) -> Self;
}
/// Methods that are harder to implement and not commonly used.
pub trait RealExt: Real {
// Gamma functions
fn lgamma(&self) -> (int, Self);
fn tgamma(&self) -> Self;
// Bessel functions
fn j0(&self) -> Self;
fn j1(&self) -> Self;
fn jn(&self, n: int) -> Self;
fn y0(&self) -> Self;
fn y1(&self) -> Self;
fn yn(&self, n: int) -> Self;
}
~~~
The constants in `Real` could be [associated items](http://smallcultfollowing.com/babysteps/blog/2013/04/03/associated-items-continued/) in the future (see issue #5527). At the moment I have left the constants in `{float|f32|f64}::consts` in case folks need to access these at compile time. There are also instances of `int` in `Real` and `RealExt`. In the future these could be replaced with an associated `INTEGER` type on `Real`.
`Natural` has also been renamed to `Integer`. This is because `Natural` normally means 'positive integer' in mathematics. It is therefore strange to implement it on signed integer types. `Integer` is probably a better choice.
I have also switched some of the `Integer` methods to take borrowed pointers as arguments. This brings them in line with the `Quot` and `Rem` traits, and is be better for large Integer types like `BigInt` and `BigUint` because they don't need to be copied unnecessarily.
There has also been considerable discussion on the mailing list and IRC about the renaming of the `Div` and `Modulo` traits to `Quot` and `Rem`. Depending on the outcome of these discussions they might be renamed again.
Unwinding through macros now happens as a call to the trait function `FailWithCause::fail_with()`, which consumes self, allowing to use a more generic failure object in the future.
The "unsigned 4 byte" `ub4`s are actually 8 bytes on 64-bit platforms
which mean that some bits > 2**32 were retained in calculations, these
would then "reappear" after a shift and so the stream of random numbers
would differ on 32 bit vs 64 bit platforms.
