[Haskell-cafe] Mystery of an Eq instance
Hello, There were some recent discussions on the floating point support in Haskell and some not-so-pleasant surprises people encountered. There is an Eq instance defined for these types! So I tried this: *Main sqrt (10.0) ==3.1622776601683795 True *Main sqrt (10.0) ==3.16227766016837956 True *Main sqrt (10.0) ==3.1622776601683795643 True *Main sqrt (10.0) ==3.16227766016837956435443343 True It seems strange. So my doubts are: 1. I wonder how the Eq instance is defined in case of floating point types in Haskell? 2. Can the Eq instance for floating point types be considered meaningful? If yes, how? In general, programmers are **advised** not to base conditional branching on tests for **equality** of two floating point values. 3. Is this particular behaviour GHC specific? (I am using GHC 6.12.1) If there are references on this please share. Thanks and regards, -Damodar Kulkarni ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On ghc 7.6.3: Prelude 3.16227766016837956 3.1622776601683795 So if you specify a number with greater-than-available precision, it will be truncated. This isn't an issue with (==), but with the necessary precision limitations of Double. On Fri, 20 Sep 2013, damodar kulkarni wrote: Hello, There were some recent discussions on the floating point support in Haskell and some not-so-pleasant surprises people encountered. There is an Eq instance defined for these types! So I tried this: *Main sqrt (10.0) ==3.1622776601683795 True *Main sqrt (10.0) ==3.16227766016837956 True *Main sqrt (10.0) ==3.1622776601683795643 True *Main sqrt (10.0) ==3.16227766016837956435443343 True It seems strange. So my doubts are: 1. I wonder how the Eq instance is defined in case of floating point types in Haskell? 2. Can the Eq instance for floating point types be considered meaningful? If yes, how? In general, programmers are **advised** not to base conditional branching on tests for **equality** of two floating point values. 3. Is this particular behaviour GHC specific? (I am using GHC 6.12.1) If there are references on this please share. Thanks and regards, -Damodar Kulkarni -- Scott Lawrence ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Which builder to choose?
Hi, I'm looking at the packages blaze-builder and bytestring, and both provide builders for ByteString. Which one should I use? In which situations is one more convenient than the other? Thanks for the help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Which builder to choose?
On Fri, 2013-09-20 at 14:57 +0200, Alejandro Serrano Mena wrote: Hi, I'm looking at the packages blaze-builder and bytestring, and both provide builders for ByteString. Which one should I use? In which situations is one more convenient than the other? I'd say the usual answer here would be bytestring. Both implementations are by Simon Meier, but the bytestring one is the later one with various refinements and more API review. The bytestring one is intended to replace the blaze-builder one. The bytestring one is in the platform. The blaze-builder one still has some extra special-case functionality such as for html encoding. I *think* (but not 100% sure) that Simon's plan is to make blaze-builder re-export the bytestring builder and just add the few extra functions on top. Duncan (bytestring co-maintainer) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On 13-09-20 07:47 AM, damodar kulkarni wrote: *Main sqrt (10.0) ==3.1622776601683795 True [...] *Main sqrt (10.0) ==3.16227766016837956435443343 True This is not even specific to Haskell. Every language that provides floating point and floating point equality does this. (To date, P(provides floating point equality | provides floating point) seems to be still 1.) In the case of Haskell, where you may have a choice: Do you want floating point ? If you say yes, then you have two problems. 1. At present, Haskell puts under Ord, and Ord under Eq. You must accept Eq to get Ord. If you reject this, you're asking the whole community to re-arrange that class hierarchy just for a few types. 2. With or without your approval, one can still defy you and define: eq x y = not_corner_case x not_corner_case y not (xy) not (xy) See, == can be derived from . ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Fri, Sep 20, 2013 at 12:17 PM, damodar kulkarni kdamodar2...@gmail.comwrote: Ok, let's say it is the effect of truncation. But then how do you explain this? Prelude sqrt 10.0 == 3.1622776601683795 True Prelude sqrt 10.0 == 3.1622776601683796 True Because there's no reliable difference there. The truncation is in bits (machine's binary representation) NOT decimal digits. A difference of 1 in the final digit is probably within a bit that gets truncated. I suggest you study IEEE floating point a bit. Also, study why computers do not generally store anything like full precision for real numbers. (Hint: you *cannot* store random real numbers in finite space. Only rationals are guaranteed to be storable in their full precision; irrationals require infinite space, unless you have a very clever representation that can store in terms of some operation like sin(x) or ln(x).) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Fri, Sep 20, 2013 at 06:34:04PM +0200, Stijn van Drongelen wrote: Please find yourself a copy of What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg, and read it. It should be very enlightening. It explains a bit about how IEEE754, pretty much the golden standard for floating point math, defines these precision rules. Ah, this is definitely the best advice in the thread. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Fri, Sep 20, 2013 at 11:17 AM, damodar kulkarni kdamodar2...@gmail.com
wrote:
Ok, let's say it is the effect of truncation. But then how do you explain
this?
Oh, it's a trunaction error all right.
Prelude sqrt 10.0 == 3.1622776601683795
True
Prelude sqrt 10.0 == 3.1622776601683796
True
Here, the last digit **within the same precision range** in the
fractional part is different in the two cases (5 in the first case and 6 in
the second case) and still I am getting **True** in both cases.
Because you're using the wrong precisision range. IEEE floats are
stored in a binary format, not a decimal one. So values that differ by 2 in
the last decimal digit can actually be different values even though
values that differ by one in the last decimal digit aren't.
And also observe the following:
Prelude (sqrt 10.0) * (sqrt 10.0) == 10.0
False
Prelude (sqrt 10.0) * (sqrt 10.0) == 10.002
True
Prelude (sqrt 10.0) * (sqrt 10.0) == 10.003
False
Prelude (sqrt 10.0) * (sqrt 10.0) == 10.001
True
Prelude
Ok, again something like truncation or rounding seems at work but the
precision rules the GHC is using seem to be elusive, to me.
(with GHC version 7.4.2)
Here's a quick-and-dirty C program to look at the values. I purposely
print decimal digits beyond the precision range to illustrate that,
even though we started with different representations, the actual
values are the same even if you use decimal representations longer
than the ones you started with. In particular, note that 0.1 when
translated into binary is a repeating fraction. Why the last hex digit
is a instead of 9 is left as an exercise for the reader. That this
happens also means the number actually stored when you enter 0.1 is
*not* 0.1, but as close to it as you can get in the given
representation.
#include stdio.h
union get_int {
unsigned long intVal ;
doublefloatVal ;
} ;
doubleCheck(double in) {
union get_int out ;
out.floatVal = in ;
printf(%.20f is %lx\n, in, out.intVal) ;
}
main() {
doubleCheck(3.1622776601683795) ;
doubleCheck(3.1622776601683796) ;
doubleCheck(10.0) ;
doubleCheck(10.001) ;
doubleCheck(10.002) ;
doubleCheck(10.003) ;
doubleCheck(0.1) ;
}
But more importantly, if one is advised NOT to test equality of two
floating point values, what is the point in defining an Eq instance?
So I am still confused as to how can one make a *meaningful sense* of the
Eq instance?
Is the Eq instance there just to make __the floating point types__
members of the Num class?
You can do equality comparisons on floats. You just have to know what
you're doing. You also have to be aware of how NaN's (NaN's are float
values that aren't numbers, and are even odder than regular floats)
behave in your implementation, and how that affects your
application. But the same is true of doing simple arithmetic with
them.
Note that you don't have to play with square roots to see these
issues. The classic example you see near the start of any numerical
analysis class is:
Prelude sum $ take 10 (repeat 0.1)
0.
Prelude 10.0 * 0.1
1.0
This is not GHC specific, it's inherent in floating point number
representations. Read the Wikipedia section on accuracy problems
(http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems) for
more information.
Various languages have done funky things to deal with these issues,
like rounding things up, or providing fuzzy equality. These things
generally just keep people from realizing when they've done something
wrong, so the approach taken by ghc is arguably a good one.
mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
Ok, let's say it is the effect of truncation. But then how do you explain this? Prelude sqrt 10.0 == 3.1622776601683795 True Prelude sqrt 10.0 == 3.1622776601683796 True Here, the last digit **within the same precision range** in the fractional part is different in the two cases (5 in the first case and 6 in the second case) and still I am getting **True** in both cases. So the truncation rules seem to be elusive, to __me__. And also observe the following: Prelude (sqrt 10.0) * (sqrt 10.0) == 10.0 False Prelude (sqrt 10.0) * (sqrt 10.0) == 10.002 True Prelude (sqrt 10.0) * (sqrt 10.0) == 10.003 False Prelude (sqrt 10.0) * (sqrt 10.0) == 10.001 True Prelude Ok, again something like truncation or rounding seems at work but the precision rules the GHC is using seem to be elusive, to me. (with GHC version 7.4.2) But more importantly, if one is advised NOT to test equality of two floating point values, what is the point in defining an Eq instance? So I am still confused as to how can one make a *meaningful sense* of the Eq instance? Is the Eq instance there just to make __the floating point types__ members of the Num class? Thanks and regards, -Damodar Kulkarni On Fri, Sep 20, 2013 at 5:22 PM, Scott Lawrence byt...@gmail.com wrote: On ghc 7.6.3: Prelude 3.16227766016837956 3.1622776601683795 So if you specify a number with greater-than-available precision, it will be truncated. This isn't an issue with (==), but with the necessary precision limitations of Double. On Fri, 20 Sep 2013, damodar kulkarni wrote: Hello, There were some recent discussions on the floating point support in Haskell and some not-so-pleasant surprises people encountered. There is an Eq instance defined for these types! So I tried this: *Main sqrt (10.0) ==3.1622776601683795 True *Main sqrt (10.0) ==3.16227766016837956 True *Main sqrt (10.0) ==3.1622776601683795643 True *Main sqrt (10.0) ==3.16227766016837956435443343 True It seems strange. So my doubts are: 1. I wonder how the Eq instance is defined in case of floating point types in Haskell? 2. Can the Eq instance for floating point types be considered meaningful? If yes, how? In general, programmers are **advised** not to base conditional branching on tests for **equality** of two floating point values. 3. Is this particular behaviour GHC specific? (I am using GHC 6.12.1) If there are references on this please share. Thanks and regards, -Damodar Kulkarni -- Scott Lawrence ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Fri, Sep 20, 2013 at 6:17 PM, damodar kulkarni kdamodar2...@gmail.comwrote: Ok, let's say it is the effect of truncation. But then how do you explain this? Prelude sqrt 10.0 == 3.1622776601683795 True Prelude sqrt 10.0 == 3.1622776601683796 True Well, that's easy: λ: decodeFloat 3.1622776601683795 (7120816245988179,-51) λ: decodeFloat 3.1622776601683796 (7120816245988179,-51) On my machine, they are equal. Note that ...4 and ...7 are also equal, after they are truncated to fit in 53 (which is what `floatDigits 42.0` tells me) bits (`floatRadix 42.0 == 2`). Ok, again something like truncation or rounding seems at work but the precision rules the GHC is using seem to be elusive, to me. It seems to me that you're not familiar with the intricacies of floating-point arithmetic. You're not alone, it's one of the top questions on StackOverflow. Please find yourself a copy of What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg, and read it. It should be very enlightening. It explains a bit about how IEEE754, pretty much the golden standard for floating point math, defines these precision rules. But more importantly, if one is advised NOT to test equality of two floating point values, what is the point in defining an Eq instance? Although equality is defined in IEEE754, it's not extremely useful after arithmetic (except perhaps for zero tests). Eq is a superclass of Ord, however, which is vital to using floating point numbers. Is the Eq instance there just to make __the floating point types__ members of the Num class? That was also a reason before GHC 7.4 (Eq is no longer a superclass of Num). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Fri, Sep 20, 2013 at 09:47:24PM +0530, damodar kulkarni wrote: Ok, let's say it is the effect of truncation. But then how do you explain this? Prelude sqrt 10.0 == 3.1622776601683795 True Prelude sqrt 10.0 == 3.1622776601683796 True Here, the last digit **within the same precision range** in the fractional part is different in the two cases (5 in the first case and 6 in the second case) and still I am getting **True** in both cases. What do you mean the same precision range? Notice: Prelude 3.1622776601683795 == 3.1622776601683796 True Prelude 3.1622776601683795 == 3.1622776601683797 True Prelude 3.1622776601683795 == 3.1622776601683798 False The truncation happens base 2, not base 10. Is that what's confusing you? Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PSA: do not install xcode 5 if you are using ghc 7.6
Hi Carter, Thanks for this heads up! Many of us here are cutting edge Mac users, and would have been bitten by this. Darin and I plan to spend some time next month preparing an unofficial patched version of ghc 7.6 that should play nice with clang / xcode 5, though at such a time ghc 7.8 will be in RC status at the very least. Can this be backported to the 7.6.3 tag and released as 7.6.4? It would be nice to not have to choose between running the latest xcode and the ability to test multiple GHC versions. Cheers, Adam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PSA: do not install xcode 5 if you are using ghc 7.6
glad to help. an alternative for the discerning power user is to install a recent version of gcc locally (eg 4.8), and build 7.6.3 with that! (or just repoint your ghc settings file to a locally built version of real gcc.) yes, assuming we have the time (after all, it's all volunteer time), that is the plan. On Fri, Sep 20, 2013 at 1:50 PM, Adam Foltzer acfolt...@gmail.com wrote: Hi Carter, Thanks for this heads up! Many of us here are cutting edge Mac users, and would have been bitten by this. Darin and I plan to spend some time next month preparing an unofficial patched version of ghc 7.6 that should play nice with clang / xcode 5, though at such a time ghc 7.8 will be in RC status at the very least. Can this be backported to the 7.6.3 tag and released as 7.6.4? It would be nice to not have to choose between running the latest xcode and the ability to test multiple GHC versions. Cheers, Adam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Music update
Some might remember me asking about music packages a while back... An update: I ended up using Euterpea, which in turn uses both Codec.Midi and Sound.PortMidi. My working environment was to have my code loaded up in ghci, play MIDI into a software MIDI bus, and pipe that into MainStage 3 which ran the synths. The piece I was working on premiered last night at a concert in Wellington, NZ. The live recording will take a while, but you can hear a studio synth recording (from the above setup) here: https://soundcloud.com/mtnviewmark/plain-changes-2-all-synth-mix The code for the piece is all open source: https://github.com/mzero/PlainChanges2. In particular, there is a somewhat improved MIDI playerhttps://github.com/mzero/PlainChanges2/blob/master/src/Sound/MidiPlayer.hs in there. Enjoy! - Mark P.S.: Yes, and now that that's done with, I can get on with the next Haskell Platform release! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Demarcating monad transformers.
Hi Café,
Below I describe what I call «demarcating monad transformer». It works
great for my purposes, though the construction feels a bit awkward.
Perhaps, this is just an instance of a general case. For details and
example, see [1] (single module package).
Recently I got a challenge of manipulating transformed monadic values. In
my case the value was of type t (Free f) a (or MonadFree m = t m a).
The challange itself was to provide a function:
transform :: (Functor f, MonadTrans t) = (forall b. f b - t (Free f)
b) - t (Free f) a - t (Free f) a
The type t (Free f) a for my purposes can be read as «a program with
low-level API specified with functor f and extra features specified with
monad transformer t».
transform takes a “basic transformation” phi and an abstract program p and
applies phi whenever p “executes” command of free functor f.
It turns out that this function is impossible (try StateT). The point is
that you can't “get inside” of transformed monadic value.
So I came up with idea of «demarcating» monad transformer. By «demarcating»
I mean separating pure monadic computations (lifted m a) from transformed
ones (t m a).
Such separation can be made explicit with the help of free monads:
data DemarcateF t m next
= forall b. DemarcateMonad (m b) (b - next) -- pure monadic
computation
| forall b. DemarcateTrans (t m b) (b - next) -- transformed
monadic computation
instance Functor (Demarcate t m) where ...
-- getting monad for freenewtype Demarcate t m a = Demarcate {
unDemarcate :: Free (DemarcateF t m) a }
instance Monad (Demarcate t m) where ...instance MonadTrans (Demarcate
t) where ...
With that I can define transform functions:
-- transform arbitrary monadic computationtransformDemarcateM ::
(forall b. m b - Demarcate t m b) - Demarcate t m a - Demarcate t m
a
-- transform free monadic actionstransformDemarcateFree :: (forall b.
f b - Demarcate t (Free f) b) - Demarcate t (Free f) a - Demarcate
t (Free f) atransformDemarcateFree phi = transformDemarcateM (iterM
phi)
The complete code is available at [1]. Check out examples/simple.hs for a
use case.
Now the questions are:
- has anyone else encountered such a challenge?
- is this solution an instance of a more general pattern?
- is it sensible to use Demarcate t m a when m is not a free monad?
- how Demarcate may affect the performance?
Thanks in advance,
Nick
[1] https://github.com/fizruk/demarcatehttps://github.com/fizruk/demarcate
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
It seems to me that you're not familiar with the intricacies of floating-point arithmetic. You're not alone, it's one of the top questions on StackOverflow. Please find yourself a copy of What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg, and read it. It should be very enlightening. It explains a bit about how IEEE754, pretty much the golden standard for floating point math, defines these precision rules. I can imagine the following dialogue happening between His[1] Excellency, the Lord Haskell (if I am allowed to anthropomorphize it) and me: Me: My Lord, I just used the (==) on floats and it gave me some unpleasant surprises. Lord Haskell: You fool, why did you tested floats for equality? Don't you know a bit about floating points? Me: My Lord, I thought it'd be safe as it came with the typeclass guarantee you give us. Lord Haskell: Look, you fool you scum you unenlightened filthy soul, yes I know I gave you that Eq instance for the floating point BUT nonetheless you should NOT have used it; NOW go enlighten yourself. Me: My Lord, thank you for the enlightenment. I don't know how many people out there are being enlightened by His Excellency, the Lord Haskell, on floating point equality and other things. Yes, many a good old junkies, like the filthier kinkier C, were keen on enlightening people on such issues. But, see, C is meant to be used for such enlightenment. Although I am not an expert on floating point numbers, the paper is not surprising as I have learnt, at least some things given in the paper, the hard way by burning myself a couple of times because of the floating point thing while programming some things in the good old C. But even the Haskell tempted to define an Eq instance for that scary thing __that__ was a new enlightenment for me. Life is full of opportunities to enlighten yourself. That was also a reason before GHC 7.4 (Eq is no longer a superclass of Num). This seems a good step forward, removing the Eq instance altogether on floating point types would be much better; (unless as pointed out by Brandon, you have a very clever representation that can store (floats) in terms of some operation like sin(x) or ln(x) (with infinite precision)) I know I might be wrong in expecting this change as it might break a lot of existing code. But why not daydream? [1] Please read His/Her Thanks and regards, -Damodar Kulkarni On Fri, Sep 20, 2013 at 10:04 PM, Stijn van Drongelen rhym...@gmail.comwrote: On Fri, Sep 20, 2013 at 6:17 PM, damodar kulkarni kdamodar2...@gmail.comwrote: Ok, let's say it is the effect of truncation. But then how do you explain this? Prelude sqrt 10.0 == 3.1622776601683795 True Prelude sqrt 10.0 == 3.1622776601683796 True Well, that's easy: λ: decodeFloat 3.1622776601683795 (7120816245988179,-51) λ: decodeFloat 3.1622776601683796 (7120816245988179,-51) On my machine, they are equal. Note that ...4 and ...7 are also equal, after they are truncated to fit in 53 (which is what `floatDigits 42.0` tells me) bits (`floatRadix 42.0 == 2`). Ok, again something like truncation or rounding seems at work but the precision rules the GHC is using seem to be elusive, to me. It seems to me that you're not familiar with the intricacies of floating-point arithmetic. You're not alone, it's one of the top questions on StackOverflow. Please find yourself a copy of What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg, and read it. It should be very enlightening. It explains a bit about how IEEE754, pretty much the golden standard for floating point math, defines these precision rules. But more importantly, if one is advised NOT to test equality of two floating point values, what is the point in defining an Eq instance? Although equality is defined in IEEE754, it's not extremely useful after arithmetic (except perhaps for zero tests). Eq is a superclass of Ord, however, which is vital to using floating point numbers. Is the Eq instance there just to make __the floating point types__ members of the Num class? That was also a reason before GHC 7.4 (Eq is no longer a superclass of Num). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Fri, Sep 20, 2013 at 7:35 PM, damodar kulkarni kdamodar2...@gmail.com wrote: This seems a good step forward, removing the Eq instance altogether on floating point types would be much better; (unless as pointed out by Brandon, you have a very clever representation that can store (floats) in terms of some operation like sin(x) or ln(x) (with infinite precision)) Please don't. The problem isn't with the Eq instance. It does exactly what it should - it tells you whether or not two floating point objects are equal. The problem is with floating point arithmetic in general. It doesn't obey the laws of arithmetic as we learned them, so they don't behave the way we expect. The single biggest gotcha is that two calculations we expect to be equal often aren't. As a result of this, we warn people not to do equality comparison on floats. So people who don't understand that wind up asking Why doesn't this behave the way I expect? Making floats not be an instance of Eq will just cause those people to ask Why can't I compare floats for equality?. This will lead to pretty much the same explanation. It will also mean that people who know what they're doing who want to do so will have to write their own code to do it. It also won't solve the *other* problems you run into with floating point numbers, like unexpected zero values from the hole around zero. Given that we have both Data.Ratio and Data.Decimal, I would argue that removing floating point types would be better than making them not be an instance of Eq. It might be interesting to try and create a floating-point Numeric type that included error information. But I'm not sure there's a good value for the expression 1.0±0.1 0.9±0.1. Note that Brandon was talking about representing irrationals exactly, which floats don't do. Those clever representations he talks about will do that - for some finite set of irrationals. They still won't represent all irrationals or all rationals - like 0.1 - exactly, so the problems will still exist. I've done microcode implementations of floating point representations that didn't have a hole around 0. They still don't work right. mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
