2013/9/22 Mike Meyer m...@mired.org:
On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson s...@scientician.net
wrote:
Trying to make something whose name is Not A Number act like a
number sounds broken from the start.
The point here is that IEEE floats are actually more something like a
Maybe
On Tue, Sep 24, 2013 at 5:39 PM, Sven Panne svenpa...@gmail.com wrote:
2013/9/22 Mike Meyer m...@mired.org:
On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson s...@scientician.net
wrote:
Trying to make something whose name is Not A Number act like a
number sounds broken from the start.
On Tue, Sep 24, 2013 at 11:36 AM, Stijn van Drongelen rhym...@gmail.comwrote:
On Tue, Sep 24, 2013 at 5:39 PM, Sven Panne svenpa...@gmail.com wrote:
2013/9/22 Mike Meyer m...@mired.org:
On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson s...@scientician.net
wrote:
Trying to make
On 20/09/2013, at 11:47 PM, damodar kulkarni wrote:
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)
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.
Yes, and then all the torrent of explanation I got here about the
intricacies of floating point operations would seem more
On 2013-09-21 06:16, Mike Meyer wrote:
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.
The Eq instance for Float violates at least one expected law of Eq:
Prelude let nan =
I think you are trying to solve a problem that doesn't exist.
* Float and Double are imprecise types by their very nature. That's exactly
what people are forgetting, and exactly what's causing misunderstandings.
Perhaps(!) it would be better to remove the option to use rational literals
as
On 21 September 2013 08:34, Stijn van Drongelen rhym...@gmail.com wrote:
* As mentioned, there is a total order (Ord) on floats (which is what you
should be using when checking whether two approximations are approximately
equal), which implies that there is also an equivalence relation (Eq).
On Sep 21, 2013 9:38 AM, Colin Adams colinpaulad...@gmail.com wrote:
On 21 September 2013 08:34, Stijn van Drongelen rhym...@gmail.com wrote:
* As mentioned, there is a total order (Ord) on floats (which is what
you should be using when checking whether two approximations are
approximately
On Sat, Sep 21, 2013 at 2:21 AM, Bardur Arantsson s...@scientician.net
wrote:
On 2013-09-21 06:16, Mike Meyer wrote:
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.
The Eq
On Sat, Sep 21, 2013 at 10:26 AM, Mike Meyer m...@mired.org wrote:
On Sat, Sep 21, 2013 at 2:21 AM, Bardur Arantsson s...@scientician.net
wrote:
On 2013-09-21 06:16, Mike Meyer wrote:
The single biggest gotcha is that two calculations
we expect to be equal often aren't. As a result of
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
On Sep 21, 2013 4:17 PM, Bob Hutchison hutch-li...@recursive.ca wrote:
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
Let me quibble.
* Float and Double are imprecise types by their very nature. That's exactly
what people are forgetting, and exactly what's causing misunderstandings.
Float and Double are precise types. What is imprecise is the correspondence
between finite precision floating point types
On 2013-09-20 18:31, Brandon Allbery wrote:
[--snip--]
unless you have a very clever representation that can store
in terms of some operation like sin(x) or ln(x).)
I may just be hallucinating, but I think this is called describable
numbers, i.e. numbers which can described by some (finite)
On Sat, Sep 21, 2013 at 12:35 PM, Bardur Arantsson s...@scientician.netwrote:
On 2013-09-20 18:31, Brandon Allbery wrote:
[--snip--]
unless you have a very clever representation that can store
in terms of some operation like sin(x) or ln(x).)
I may just be hallucinating, but I think this
Sure. An interesting, if not terribly relevant, fact is that there are
more irrational numbers that we *can't* represent the above way than that
we can (IIRC).
However, those aren't actually interesting in solving the kinds of problems
we want to solve with a programming language, so it's
On Sat, Sep 21, 2013 at 12:43 PM, David Thomas davidleotho...@gmail.comwrote:
Sure. An interesting, if not terribly relevant, fact is that there are
more irrational numbers that we *can't* represent the above way than that
we can (IIRC).
I think that kinda follows from diagonalization... it
I think that's right, yeah.
On Sat, Sep 21, 2013 at 9:49 AM, Brandon Allbery allber...@gmail.comwrote:
On Sat, Sep 21, 2013 at 12:43 PM, David Thomas
davidleotho...@gmail.comwrote:
Sure. An interesting, if not terribly relevant, fact is that there are
more irrational numbers that we
On Sep 21, 2013 9:17 AM, Bob Hutchison hutch-li...@recursive.ca wrote:
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
On 2013-09-21 23:08, Mike Meyer wrote:
Exactly. The Eq and Ord instances aren't what's broken, at least when
you're dealing with numbers (NaNs are another story). That there are pairs
According to Haskell NaN *is* a number.
Eq and Ord are just the messengers.
No. When we declare something an
On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson s...@scientician.net
wrote:
On 2013-09-21 23:08, Mike Meyer wrote:
Exactly. The Eq and Ord instances aren't what's broken, at least when
you're dealing with numbers (NaNs are another story). That there are
pairs
According to Haskell NaN *is*
i had a longer email written out, but decided a shorter one is better.
I warmly point folks to use libs like the numbers package on hackage
http://hackage.haskell.org/packages/archive/numbers/2009.8.9/doc/html/Data-Number-BigFloat.html
it has some great alternatives to standard floats and
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
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,
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,
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
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
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
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
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
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
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
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
34 matches
Mail list logo
