Add RFC: approx-asserts

[dhardy]

• add assert_approx macro to libstd prelude
• add assert_tol macro to libstd prelude

Rendered

[mdinger]

// You could do something different with macros to differentiate the
// relative and absolute. I'm not sure if `=` works with macros...expressions
// usually just evaluate...not really experience with this type...
assert_tol!(1.003e8f32, 1e8f32, rel = abs = 1e-2f32);
assert_tol!(1.003e8f32, 1e8f32, rel = .01, abs = .1);

[P1start]

I’d prefer just having an approx_eq method on floats, and doing assert!(1.0.approx_eq(1.0001)); as an assertion. Having only a special assert_eq!-like macro seems very strange. I don’t think assert_eq! should exist at all, but that’s not strictly relevant to this RFC and not something I expect to change any time soon.

I think that if we do get a macro like this, we should get a method on floats like it as well. Having a macro to assert something but not a simple method to test it would be pretty ridiculous.

[dhardy]

@P1start do you say this out of simple reasoning or experience? I'm not saying you're wrong, but the only time I have wanted approximate equality outside of an assertion is when error-handling user input of the form "I require a list of numbers whose sum must be 1", at which point it is usually clearer to write something like if !(0.999 < sum && sum < 0.001) {...} than bothering with a function.

Other than that, your suggestion has two issues: (minor) it's longer to type and (major) poor error messages:

use std::num::Float;
/// A simple approx-equals function
fn is_approx<T: Float>(x: T, y: T, atol: T) -> bool { (x - y).abs() < atol }
/// Geometric series
fn geom(r: f64, n: u32) -> f64 { if n > 1 { r + r * geom(r, n-1) } else { r } }
fn main() {
    assert!(is_approx(geom(0.5, 10), 1.0, 1e-6));
}

panics with message

thread '<main>' panicked at 'assertion failed: is_approx(geom(0.5, 10), 1.0, 1e-6)', <anon>:7

but what's the value of geom(0.5, 10)?

[dhardy]

@mdinger thanks for the hint, will consider

[aturon]

Thanks for the PR!

In general, we're working right now to cut down the standard library to a conservative core that we're happy to commit to. While these macros seem useful, there's not in my mind a strong reason to introduce them into the standard library and prelude right this second -- in general, it's better for this kind of thing to begin its life in the crates.io ecosystem and gradually migrate into std only if needed for standardization or widespread use.

[dhardy]

Sounds like good advice, cheers.