unageek / inari Goto Github PK

In a project, I need to implement the function

Clearly I cannot do it naively because the singularity of the logarithm at 0. To that aim, directed rounding methods (such as x.add_ru(y), x.mul_rd(y),...) would be useful. Of course I can always make a singleton with each boundary point by I would be making twice as many computations (and half would be thrown away). What do you think?

Wouldn't it be desirable for the methods .inf() and .sup() to be constant? That would allow, for example, const_interval!(0., Interval::PI.sup()).

How about a function from(x: f64) → Interval? Its definition would be:

• from(NAN) = ∅
• from(+∞) = [f64::MAX, f64::INFINITY]
• from(-∞) = [f64::NEG_INFINITY, f64::MIN]
• otherwise from(x) = [x,x].

This could be useful for producing constants in generic code. What do you think?

@unageek @Chris00 considering that Rust seems to be growing in popularity, which many people now use to compile for Web browser use (with WASM byte code), it seems like it would be useful to have your library compile to WASM. I mention this because there is an open issue before the WASM community to add instructions which accelerate floating-point operations sensitive to rounding mode. The community has made it clear that they want to see concrete use cases before doing so, however. Your library seems like a good example, especially considering that it already has 13 stars and 2 forks. I can provide more details if you're interested. Otherwise, feel free to close this issue.

I wonder why you did not call the pown function powi as in the standard library?

This is really minor but I am wondering: any reason to use transmute instead of the dedicated _mm_set_pd?

The following minimal project that simply does use inari::*; does not compile: RUSTFLAGS='-Ctarget-cpu=haswell' cargo build yields,

    Updating crates.io index
   Compiling libc v0.2.110
   Compiling gmp-mpfr-sys v1.4.7
   Compiling az v1.2.0
   Compiling memchr v2.4.1
   Compiling version_check v0.9.3
   Compiling rug v1.14.0
   Compiling minimal-lexical v0.2.1
   Compiling cfg-if v1.0.0
   Compiling nom v7.1.0
   Compiling inari v0.11.0
   Compiling test v0.0.1 (/tmp/test)
error[E0432]: unresolved import `inari`
 --> test.rs:1:5
  |
1 | use inari::*;
  |     ^^^^^ maybe a missing crate `inari`?

For more information about this error, try `rustc --explain E0432`.
error: could not compile `test` due to previous error

One often has to implement expressions such as and it would be convenient to be able to write

3. * x.powi(3) + 4.5 * x.powi(2) - 1.25

instead of

const_interval!(3., 3.) * x.powi(3) + const_interval!(4.5, 4.5) * x.powi(2) - const_interval!(1.25, 1.25)

Having mul_rev_to_pair as defined in section 10.5.5 of the standard or possibly taking advantage that Rust has enums

pub fn div2(self, rhs: Interval) → Union2;
pub enum Union2 {
    Single(Interval),
    Union(Interval, Interval),
}

would be useful (e.g. for Newton). What do you think?

when rust-lang/rust#96710 is stabilized.

May you explain the rationale for inf to return -0. when the lower bound is 0.? That breaks the invariant one may expect: interval!(x.inf(), x.sup()) == x (when the interval is not empty).

I saw that LLVM can reorder rounding-mode-sensitive float operations outside rounding mode changes in SSE so I was wondering whether Inari is affected by this. While I am at it, I would like to make sure that I understood well the code (my ASM is very limited) and that there is no rounding that can adversely affect the result when stored from extended precision into memory. (I want to use your library for computer assisted proofs and I'd like to be reassured that it is 100% reliable. 😀)