On 24/04/2010, at 22:42, Roman Leshchinskiy wrote:
On 24/04/2010, at 22:06, Barak A. Pearlmutter wrote:
I was thinking of this:
data T = T Double deriving ( Eq, Ord )
... GHC basically produces
instance Ord T where
compare (T x) (T y) = compare x y
t u = compare t u == LT
That
It seems to me that there's a choice here between
(A) Full conformance to the letter of IEEE arithmetic
AND full conformance to the letter of Haskell total ordering
with consequent inconvenience:
don't make floats Ord
create new IEEE comparison operations for floats
(B)
On Sun, Apr 25, 2010 at 9:08 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote:
It seems to me that there's a choice here between (...)
Nice! That's a very comprehensive summary of the situation regarding
issues of correctness. I do wonder, though, what (if any) are the
performance implications?
And yet a lot of generic code is written in terms of compare.
That's can be an advantage, because often that code *should* blow up
when it gets a NaN. E.g., sorting a list of Floats which includes a
NaN.
Even deriving(Ord) only produces compare and relies on standard
definitions for other
On 24/04/2010, at 19:56, Barak A. Pearlmutter wrote:
And yet a lot of generic code is written in terms of compare.
That's can be an advantage, because often that code *should* blow up
when it gets a NaN. E.g., sorting a list of Floats which includes a
NaN.
However, often you will know
It's a question of what the right default is - safety or
performance. In the case of floating point numbers, I'm leaning
towards performance.
I quite agree.
Currently the standard prelude has default definition:
...
compare x y
| x == y= EQ
| x = y= LT
On 24/04/2010, at 22:06, Barak A. Pearlmutter wrote:
Currently the standard prelude has default definition:
...
compare x y
| x == y= EQ
| x = y= LT
| otherwise = GT
I'd suggest
[...]
compare x y
| x y = LT
| x
On Sat, Apr 24, 2010 at 5:56 AM, Barak A. Pearlmutter ba...@cs.nuim.ie wrote:
Even deriving(Ord) only produces compare and relies on standard
definitions for other methods.
I don't think that's actually a problem. Surely the IEEE Floating
Point types would give their own definitions of not
The problem are not so much the additional instructions. Rather,
it's the fact that compare for Float and Double can fail at all
which inhibits some optimisations. For instance, GHC is free to
eliminate the comparison in (x `compare` y) `seq` a but wouldn't be
with your change. It doesn't
From: Barak A. Pearlmutter ba...@cs.nuim.ie
... An invalid comparison evaluating to _|_ is arguably more
correct, but I personally find the idea of introducing more bottoms
rather distasteful.
Too late! NaN is pretty much the _|_ of IEEE Floating Point.
That was certainly the intent of
On 23/04/2010, at 01:34, Barak A. Pearlmutter wrote:
I'd suggest that compare involving a NaN should yield
error violation of the law of the excluded middle
Please think of the poor guys trying to write high-performance code in Haskell!
Roman
On Fri, Apr 23, 2010 at 3:21 AM, Barak A. Pearlmutter ba...@cs.nuim.ie wrote:
... An invalid comparison evaluating to _|_ is arguably more
correct, but I personally find the idea of introducing more bottoms
rather distasteful.
Too late! NaN is pretty much the _|_ of IEEE Floating Point.
Please think of the poor guys trying to write high-performance code in
Haskell!
Like me? (Well, not in Haskell per-se, but in a pure functional context.)
In all seriousness, I think it is reasonable when isNaN x for
x C
x == C
x C
C x
C == x
C x
to all be False, for all floats C,
Casey McCann wrote:
The only correct solution would be to strip floating point types of
their instances for Ord, Eq, and--therefore, by extension--Num. For
some reason, no one else seems to like that idea. I can't imagine
why...
I'm not terribly opposed to it. But then, I've also defined
On 24/04/2010, at 07:15, Barak A. Pearlmutter wrote:
In all seriousness, I think it is reasonable when isNaN x for
x C
x == C
x C
C x
C == x
C x
to all be False, for all floats C, even C=x, as a sort of efficient
weak Bool bottom. This is what the FP hardware does --- so it is very
Comparison of exceptional IEEE floating point numbers, like Nan, seems
to have some bugs in ghci (version 6.12.1).
These are correct, according to the IEEE floating point standards:
Prelude 0 (0/0)
False
Prelude 0 (0/0)
False
Prelude 0 == (0/0)
False
But these are
On 16:34 Thu 22 Apr , Barak A. Pearlmutter wrote:
Comparison of exceptional IEEE floating point numbers, like Nan, seems
to have some bugs in ghci (version 6.12.1).
These are correct, according to the IEEE floating point standards:
Prelude 0 (0/0)
False
...
But these are
On Thu, Apr 22, 2010 at 11:34 AM, Barak A. Pearlmutter ba...@cs.nuim.ie wrote:
Comparison of exceptional IEEE floating point numbers, like Nan, seems
to have some bugs in ghci (version 6.12.1).
Arguably, the bug in question is the mere existence of Eq and Ord
instances for IEEE floats. They
On 13:30 Thu 22 Apr , Casey McCann wrote:
On Thu, Apr 22, 2010 at 11:34 AM, Barak A. Pearlmutter ba...@cs.nuim.ie
wrote:
Comparison of exceptional IEEE floating point numbers, like Nan, seems
to have some bugs in ghci (version 6.12.1).
Arguably, the bug in question is the mere
19 matches
Mail list logo
