Interval operations with scalars

[Chris00]

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)

[unageek]

Thank you for your feedback!

How about using a macro like this:

https://github.com/unageek/graphest/blob/127dd3aeb8fd00804f8e23e60b42dbbe4a527725/rust/src/interval_set_ops.rs#L1468-L1476

I don't want to let users mix floating-point and interval operations for obvious reasons:

• It would become too easy to write spurious codes, such as:

  let one = const_interval!(1.0, 1.0);
  let one_tenth = one / 10.0;

  (Edit: this code works as intended. c.f. Interval operations with scalars #71 (comment))

• NaN and infinities are common results of FP operations, but are not mapped to intervals.

[Chris00]

How about using a macro like this:
https://github.com/unageek/graphest/blob/127dd3aeb8fd00804f8e23e60b42dbbe4a527725/rust/src/interval_set_ops.rs#L1468-L1476

That's what I do in my own code. It is better that nothing but still makes the code more obscure than it needs to be.

It would become too easy to write spurious codes, such as:

I do not see the problem with this code as 10. would be “promoted” to the interval [10., 10.] and then the division will be performed. That said, someone way also write const_interval!(0.1, 0.1) which has the same problem you alluded to (or maybe you intend that macro to be restricted to literal numbers and you eventually intend to parse them — probably a good check at compile time).

NaN and infinities are common results of FP operations, but are not mapped to intervals.

I agree, you would have to guard against these — or define a promotion such as +∞ ↦ [f64::MAX, +∞], NaN ↦ [-∞, +∞].

One way to avoid the above two problems while keeping the convenience would be to define a more powerful macro i!: i!(expr) would promote all literal constants in expr to intervals (checking that they indeed are exactly representable as f64 numbers). The above would just become:

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

which would be legible and safe.

[unageek]

I do not see the problem with this code as 10.

Oh, you're right! Maybe I'm already confused by the mixture.

define a more powerful macro

Yeah, IntervalArithmetic.jl does that.

[Chris00]

Slowly thinking of such a procedural macro (which must be in a separate crate as far as I understand), this macro could also specialize operations where it sees fit. For example, 2. * x could be transformed into [2. * x.inf, 2. * x.sup]. Thus a (hidden from the docs) submodule with optimized functions may be of interest. What do you think?