"Gennadiy Rozental" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > > > There is BOOST_CHECK_PREDICATE > > > > > Yes, I know. > > My point was that with BOOST_CHECK_EQUAL_NUMBERS() the test library > > could output something readable of the form: > > > > "numbers x and y are not approximately equal" > > > > It could even add to the output something of the form: > > > > " according to " << Pred ; > > This is what BOOST_CHECK_CLOSE is doing basically. > Yes, that's the point. What I proposed is that the user can combine the macro with the comparator (I changed the macro name), becuase the comparison method is often application specific. I suggested to have an abosulte error comparator class as a default, but not as a fixed method inside the macro. The problem with any fixed scheme is that it can't be general enough, and the test library is highly general.
I'm not sure if any fixed comparison method should be supplied at all. I would choose between my proposal, were specific targets can supply their own comparators, or not having fp comparison at all in the test library itself. >For majority of simple cases (not very big, nor very small values) they >should behave similarly. For egde cases relative error comparison produces >better results IMO No. It is not a matter of value magnitude or edge/non-edge cases. It is a matter of the number and type of operations performed yielding the values to be compared. This is why the best method is highly domain specific. Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
