On 2013-09-21, at 4:46 AM, Stijn van Drongelen <rhym...@gmail.com> wrote:
> I do have to agree with Damodar Kulkarni that different laws imply different
> classes. However, this will break **a lot** of existing software.
You could argue that the existing software is already broken.
>
> If we would do this, only Eq and Ord need to be duplicated, as they cause
> most of the problems. Qualified imports should suffice to differentiate
> between the two.
>
> import qualified Data.Eq.Approximate as A
> import qualified Data.Ord.Approximate as A
>
> main = print $ 3.16227766016837956 A.== 3.16227766016837955
As soon as you start doing computations with fp numbers things get much worse.
Something like Edward Kmett's Numeric.Interval package would likely be helpful,
a start at least (and the comments in the Numeric.Interval documentation are
amusing) In the distant past when I was worried about maintaining accuracy in a
solids modeller we went with an interval arithmetic library that we *carefully*
implemented. It worked. Unpleasant in C, but it worked. And this link might be
interesting:
http://lambda-the-ultimate.org/node/1301
Cheers,
Bob
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
