Floating point conversion tests#402
Conversation
- largely pulled from ryu unit tests
- avoid introducing new functions to test - we get reasonable exposure to rounding and shortest path even with the generic dispatch on exponent
How about a property test that compares the BTW, where does the requirement to match |
Do you mean e.g This test tends to not cover enough cases to exposes differences reliably but is a good statement of expectation.
There was some discussion in the original C PR #222 (comment) and mostly the idea was that it would be 'quite unexpected to diverge from |
Diverging from it means a breaking change, and of a nasty nature. I think it's desitable to keep Ideally I'd love to see |
Thanks for making me aware (again) of this test! :)
Agreed. It might make sense to explicitly say that |
|
Thanks @Lumaere! |
* Add floating conversion tests - largely pulled from ryu unit tests * Use floatDec and doubleDec in tests - avoid introducing new functions to test - we get reasonable exposure to rounding and shortest path even with the generic dispatch on exponent
* Add floating conversion tests - largely pulled from ryu unit tests * Use floatDec and doubleDec in tests - avoid introducing new functions to test - we get reasonable exposure to rounding and shortest path even with the generic dispatch on exponent
This PR adds floating point tests for
floatDecanddoubleDec. It expects implementations to match baseshowfunctionality wrt rounding and (non) shortest-path.These are based on the original C tests with modifications to match
show.