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 =
On Sun, Apr 25, 2010 at 9:08 PM, Richard O'Keefe 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?
Editorializing a bit,
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) F
> 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
On Sat, Apr 24, 2010 at 5:56 AM, Barak A. Pearlmutter 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 just compar
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
> 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 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 kno
> 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 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 --- s
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 classe
> 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 flo
On Fri, Apr 23, 2010 at 3:21 AM, Barak A. Pearlmutter 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.
Yes, of cour
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
___
> From: "Barak A. Pearlmutter"
>
>> ... 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 the
> ... 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 the IEEE standard, and is why NaN is
so contagi
On 13:30 Thu 22 Apr , Casey McCann wrote:
> On Thu, Apr 22, 2010 at 11:34 AM, Barak A. Pearlmutter
> 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
On Thu, Apr 22, 2010 at 11:34 AM, Barak A. Pearlmutter 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 don't, can't, an
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 thes
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
20 matches
Mail list logo
