search

ocramz / sparse-linear-algebra

Numerical computation in native Haskell
GNU General Public License v3.0
88 stars 10 forks source link

More tests #58

Open Jaxan opened 6 years ago

Jaxan commented 6 years ago

I just wanted to show how we could use more QuickCheck property testing.

These commits are still a bit of a mess as I wanted to use floating points first (that clearly will not work). And afterwards moved to rational numbers. I propose not to merge it, but just to have a look at it.

Note that Complex Rational does not have a Num instance because one cannot define abs. This is a bit annoying and really a problem with base. Also we cannot have Normed instances for rational numbers, so we can only test some things exactly.

ocramz commented 6 years ago

Thanks a lot @Jaxan ! I'll look into this asap. For the time being, why did you have to change the bounds on base and the Stackage LTS versions? Thanks!

Jaxan commented 6 years ago

Good question. The reason is that the function conjugate from Data.Complex had the constraint RealFloat instead of Num and they fixed that in 4.8. I wanted to use the same tests with Complex Rational, so I needed conjugate to work. However, in the end it didn't work at all, because there is no Num instance as abs is unimplementable for Complex Rational.

As I said, the code is a bit of a mess (and more for exposition instead of merging). I also changed stuff in Epsilon which is maybe not necessary.

ocramz commented 6 years ago

Great points! Yes, working over Z or Q would enable exact algorithms, but then we'd have to rewrite all the parts that use square roots (such as the L2 norm), trig functions etc.

Jaxan commented 6 years ago

I think it's the most we can easily get out of QuickCheck. For the floating point instances and classes like Normed, we can still write unit tests.