Eq context for evalPoly

[dmcclean]

I'm wondering if it would make sense to supply an alternate version of evalPoly at type (Num a) => Poly a -> a -> a instead of (Num a, Eq a) => Poly a -> a -> a.

It looks like the current version uses the Eq context to check if the argument is zero before evaluating the polynomial, presumably either for efficiency or to be sure to get the exact result.

However this context requirement is a burden when the polynomial is over an abstract domain like an Ivory IDouble which doesn't supply an Eq context.

[mokus0]

Yea, that constraint is there solely for the shortcut of evaluating at zero, which happens (perhaps surprisingly) often in practice.

A more general form sounds like a useful addition, though I'd prefer to do the same for all the other functions at the same time rather than a few random selections. Ideally the more general forms would probably be in a separate module. And then there's the additional question of whether there should also be a similar generalized module for the VectorSpace-based versions of the same functions as well.