algebra
algebra copied to clipboard
brendanzab
Add ApproxEq trait with asserts
This effectively adds some topology to this library. In particular, the trait effectively is a metric space M combined with some (small) constant ε∈M. Do floating point numbers form a metric space?
NaN could be considered infinitely far from everything, in particular, from itself, so with that assumption, no.
I really think we should just ignore special values and the various irregularities of floating point numbers. I we don't we could not use them for anything in this library because it would not even implement basic property-traits (e.g. no multiplicative associativity), nor structural-traits because of the lack of unique additive identity element (among thousands of other problems).
Ok, I was not entirely sure about that, since one might want floating point numbers to fulfill weaker variants of these properties, e.g. multiplication and addition should be approximately associative. But looking at the literature it appears that the theory there is not entirely fleshed out. However we should at the very least document these inaccuracies when implementing traits for floating point types that do not actually fulfill these properties though.
Ignoring it has the downside that quickcheck-style theorem testing will not work on floating point types. I wonder if we could weaken the abstract mathematical properties, s.t. the weaker variants hold for floating point arithmetic and also are implied by the more strict ones. The question then is, of course, whether the stricter variants would see much use, when they are not implemented for floating-point types.
@huonw that's not directly a problem, when you use another form of identity where NaN != NaN. But this may lead to other problems down the road, I guess.
Should the macros be packaged in separate crate btw? Quickcheck does it that way and I think this approach makes more sense, if you look at the extern crate declarations, as you need to declare the library and its exported macros separately anyway.
Mind sebcrozet/nalgebra#60 for the implementation. The essence is to just ignore the least significant bits of the mantissa instead of specifying some arbitrary epsilon. This might also yield more consistent algebraic properties.