| Age | Commit message (Collapse) | Author | Lines |
|---|
|
As discussed on issue #4819, I have created four new traits: `Algebraic`, `Trigonometric`, `Exponential` and `Hyperbolic`, and moved the appropriate methods into them from `Real`.
~~~rust
pub trait Algebraic {
fn pow(&self, n: Self) -> Self;
fn sqrt(&self) -> Self;
fn rsqrt(&self) -> Self;
fn cbrt(&self) -> Self;
fn hypot(&self, other: Self) -> Self;
}
pub trait Trigonometric {
fn sin(&self) -> Self;
fn cos(&self) -> Self;
fn tan(&self) -> Self;
fn asin(&self) -> Self;
fn acos(&self) -> Self;
fn atan(&self) -> Self;
fn atan2(&self, other: Self) -> Self;
}
pub trait Exponential {
fn exp(&self) -> Self;
fn exp2(&self) -> Self;
fn expm1(&self) -> Self;
fn log(&self) -> Self;
fn log2(&self) -> Self;
fn log10(&self) -> Self;
}
pub trait Hyperbolic: Exponential {
fn sinh(&self) -> Self;
fn cosh(&self) -> Self;
fn tanh(&self) -> Self;
}
~~~
There was some discussion over whether we should shorten the names, for example `Trig` and `Exp`. No abbreviations have been agreed on yet, but this could be considered in the future.
Additionally, `Integer::divisible_by` has been renamed to `Integer::is_multiple_of`.
|
|
One of the tests seems to have no current equivalent that's similar. Please let me know if that's incorrect, and I'll try fixing it instead of deleting it. I suppose a struct could be used instead of `any` and `match type`, but it seems like the original intent of the test was to exercise `match type`
|
|
After discussions on IRC and #4819, we have decided to revert this change. This is due to the traits expressing different ideas and because hyperbolic functions are not trivially implementable from exponential functions for floating-point types.
|
|
The Hyperbolic Functions are trivially implemented in terms of `exp`, so it's simpler to group them the Exponential trait. In the future these would have default implementations.
|
|
r? @pcwalton
A month's worth of parser cleanup here. Much of this is new comments and renaming. A number of these commits also remove unneeded code. Probably the biggest refactor here is splitting "parse_item_or_view_item" into two functions; it turns out that the only overlap between items in foreign modules and items in regular modules was macros, so this refactor should make things substantially easier for future maintenance.
|
|
'is_even'
|
|
|
|
|
|
|
|
Trigonometric, Exponential and Hyperbolic traits
|
|
|
|
This fixes issue #5641
|
|
This is a follow-up commit for #6041 (and depending on #6048).
Also adding `#[inline(always)]` for almost every methods in `std::bigint`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the name no longer made sense. perhaps this could just be inlined.
|
|
|
|
|
|
two problems with the old name: they're not called classes any more, and
the word "item" has a specific connotation in the parser
|
|
|
|
|
|
|
|
before this change, the parser would parse 14.a() as a method call, but
would parse 14.ø() as the floating-point number 14. followed by a function
call. This is because it was checking is_alpha, rather than ident_start,
and was therefore wrong with respect to unicode.
|
|
|
|
|
|
In principle, it seems like a nice idea to abstract over the two
functions that parse blocks (one with inner attrs allowed, one not).
However, the existing one wound up making things more complex than
just having two separate functions, especially after the obsolete
syntax is (will be) removed.
|
|
|
|
parser comments
|
|
prec.rs no longer had much to do with precedence; the token->binop
function fits better in token.rs, and the one-liner defining the
precedence of 'as' can go next to the other precedence stuff in
ast_util.rs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
With luck, this will allow rust to compile itself without --cfg flags again...
|
|
`self` has type `&@Rand`, so `*self` will be of type `@Rand` which causes
this same impl to be called again.
|
|
|
|
Also remove abs() method from the non-trait impl for BigInt/BigUint.
That method is provided in the Signed trait.
|
|
|
|
r? @brson mkdir_recursive creates a directory as well as any of its
parent directories that don't exist already. Seems like a useful
thing to have in core.
(Or r? anyone who gets to it first.)
|
|
People hit the recursion depth limit too often, it's not possible
to unwind reliably from out-of-stack.
Issues #3555, #3695
|
