hspec-expectations
hspec-expectations copied to clipboard
Add shouldBeNear expectation
Comparing floating point numbers for equalty is a bad idea. Instead they should tested to see if they are close enough to one another.
Ping?
Hey, sorry for the delay. For this to be useful this would at least need tests and more detailed documentation. Specifically I don't understand
- why is the first case necessary
- what happens on division by zero, e.g. when comparing
1e-20and-1e-20
For this to be useful this would at least need tests
There's no tests listed in the cabal file. I've found the tests in the repo and I'm adding tests, but how do I run them?
why is the first case necessary
This is short circuit evaluation for the case where they are actually equal.
what happens on division by zero, e.g. when comparing 1e-20 and -1e-20
The code for the third case says (abs actual + abs expected) which could only be zero if both values are zero and that would be caught be the second case.
I use ghci or sensei to run tests
Sent from mobile
On 3 Sep 2016, at 4:53 PM, Erik de Castro Lopo [email protected] wrote:
For this to be useful this would at least need tests
There's not tests listed on the cabal file. How do I run them?
why is the first case necessary
This is short circuit evaluation for the case where they are actually equal.
what happens on division by zero, e.g. when comparing 1e-20 and -1e-20
The code for the third case says (abs actual + abs expected) which could only be zero if both values are zero and that would be caught be the second case.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Tests are running on Travis now. Can you rebase on current master and make sure the build is green.
I also wouldn't mind if you remove some of the code duplication, e.g. by factoring common stuff out into a where-clause.
Then I would love to discuss the actual stuff, that is the formula and the chosen value for epsilon.
Ok, the build has passed.
Since the current code uses guards, its not possible to refactor common code into a where clause, but I could make it a separate top level function (and then not export it).
I think you can use a where clause with guards, no?
Sent from mobile
On 6 Sep 2016, at 5:03 PM, Erik de Castro Lopo [email protected] wrote:
Ok, the build has passed.
Since the current code uses guards, its not possible to refactor common code into a where clause, but I could make it a separate top level function (and then not export it).
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
It works! Fixed, rebased and pushed.
For some reason I couldn't get one the tests working with ghc 7.10 even though it passed on all the other versions.
@sol Does this seem ok?
@erikd is this still a valid approach or have you found a different way to tackle comparing Doubles?
@istathar I stopped using hspec about 6 years ago, in favor of hedgehog. However, I suspect this may still be a valid approach.