New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assertion macros for approximate equality #40
Comments
In the long term, I wonder if this kind of assertion could be moved to https://github.com/bjz/algebra, formalized as a test of inclusion of a point in another point's neighborhood (i-e. for the case of Reals, an open ball of radius I the mean time, I think this can be added to |
cc @bjz |
+1 for this |
milibopp
added a commit
to milibopp/nalgebra
that referenced
this issue
Nov 23, 2014
These macros yield readable error messages as test assertions for ApproxEq types. They can be invoked as: assert_approx_eq!(a, b); assert_approx_eq_eps!(a, b, eps); Fixes dimforge#40.
milibopp
added a commit
to milibopp/nalgebra
that referenced
this issue
Nov 23, 2014
These macros yield readable error messages as test assertions for ApproxEq types. They can be invoked as: assert_approx_eq!(a, b); assert_approx_eq_eps!(a, b, eps); Fixes dimforge#40.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I already added this to
cgmath
in rustgd/cgmath#131 and would like to contribute a similar feature here. The API differences are minor, so it should be mostly a matter of copy & paste. To make this self-consistent, I'll repeat the explanation:Testing code with floating point numbers and nalgebra data structures one can use assertions on ApproxEq types:
This does not yield readable error messages upon failure. Arguably it is also a bit ugly to read/write. I propose adding macros similar to
assert_eq!
to alleviate this, e.g.:The question is, whether exported macros should go in a separate crate or not. Since macros aren't namespaced some libraries do that, to allow importing macros separately from the rest of the functionality, while others don't. I don't think that would make a lot of sense here though, as the macro is tightly coupled to the ApproxEq trait.
The text was updated successfully, but these errors were encountered: