On 13.07.2012 19:27, Brandon Allbery wrote:
On Fri, Jul 13, 2012 at 7:29 AM, Aleksey Khudyakov
mailto:alexey.sklad...@gmail.com>> wrote:
Num inherits from Eq, so Float couldn't have an instance for Num
if we
didn't have that Eq instance.
No more since GHC 7.4. But Eq
On Fri, Jul 13, 2012 at 7:29 AM, Aleksey Khudyakov <
alexey.sklad...@gmail.com> wrote:
> Num inherits from Eq, so Float couldn't have an instance for Num if we
>> didn't have that Eq instance.
>>
>> No more since GHC 7.4. But Eq is indeed superclass of Ord and it Ord is
> used a lot.
...but Flo
On 13.07.2012 14:18, Sönke Hahn wrote:
On 07/13/2012 03:12 AM, Bardur Arantsson wrote:
Speaking of which... would it be remiss of me to mention the elephant in
the room, namely the Eq instance for Float?
AFAICT there is no possible way for a Float value to fulfill the Eq type
class requirements
On 07/13/2012 03:12 AM, Bardur Arantsson wrote:
> Speaking of which... would it be remiss of me to mention the elephant in
> the room, namely the Eq instance for Float?
>
> AFAICT there is no possible way for a Float value to fulfill the Eq type
> class requirements, so why is it an instance? (I'm
On 07/10/2012 12:51 PM, malcolm.wallace wrote:
> Also, it is more likely to be a buggy instance of Eq, than a real loss
> of referential transparency.
>
Speaking of which... would it be remiss of me to mention the elephant in
the room, namely the Eq instance for Float?
AFAICT there is no possibl
On 11.07.2012 20:05, Tyson Whitehead wrote:
On July 11, 2012 04:51:50 Christian Maeder wrote:
Is it not enough to store floats into memory just before equality tests
(or add rounding in the instance definitions of Float and Double in Eq
and Ord)?
You have to be 100% consistent in how you do ev
On July 11, 2012 04:51:50 Christian Maeder wrote:
> Is it not enough to store floats into memory just before equality tests
> (or add rounding in the instance definitions of Float and Double in Eq
> and Ord)?
You have to be 100% consistent in how you do every operations in all cases
otherwise dif
On 11/07/2012 09:51, Christian Maeder wrote:
Am 11.07.2012 10:25, schrieb Simon Marlow:
On 11/07/2012 08:36, Christian Maeder wrote:
Hi,
I think this bug is serious and should be turned into a ticket on
http://hackage.haskell.org/trac/ghc/
Would you do so Sönke?
The abstraction of floats (Flo
Am 11.07.2012 10:25, schrieb Simon Marlow:
On 11/07/2012 08:36, Christian Maeder wrote:
Hi,
I think this bug is serious and should be turned into a ticket on
http://hackage.haskell.org/trac/ghc/
Would you do so Sönke?
The abstraction of floats (Float or Double) is broken if equality
considers
On 11/07/2012 08:36, Christian Maeder wrote:
Hi,
I think this bug is serious and should be turned into a ticket on
http://hackage.haskell.org/trac/ghc/
Would you do so Sönke?
The abstraction of floats (Float or Double) is broken if equality
considers (random and invisible) excess bits that are
Hi,
I think this bug is serious and should be turned into a ticket on
http://hackage.haskell.org/trac/ghc/
Would you do so Sönke?
The abstraction of floats (Float or Double) is broken if equality
considers (random and invisible) excess bits that are not part of the
ordinary sign, exponent an
On July 10, 2012 10:39:41 Colin Adams wrote:
> Sure they would be better modelled that way, but the whole point of using
> floating point arithmetic is to sacrifice accuracy for performance, is it
> not?
True. I just find it interesting that some types have a builtin Nothing value.
Some further
On Tue, 10 Jul 2012, Sönke Hahn wrote:
Hi!
I've discovered a strange bug that violates simple equational reasoning.
Basically, something similar to this:
let a = f x
in a == f x
While this code as it stands doesn't quite illustrate the referential
transparency error, since == isn't guarente
On July 10, 2012 09:28:27 Christian Maeder wrote:
> Am 10.07.2012 13:06, schrieb Sönke Hahn:
> > I've attached the code. The code does not make direct use of
> > unsafePerformIO. It uses QuickCheck, but I don't think, this is a
> > QuickCheck bug. The used Eq-instance is the one for Float.
>
> The
It also works (exposes the bug on x86) without Quickcheck and Doubles:
main = prop 6.0 0.109998815
prop m x = do
let a = x * m
putStrLn (show a ++ " foo")
print (x * m == a)
0.65999289 foo
False
The middle line seems to prevent CSE.
C.
Am 10.07.2012 13:06, schrieb Sönke Hahn:
I'
Am 10.07.2012 13:06, schrieb Sönke Hahn:
I've attached the code. The code does not make direct use of
unsafePerformIO. It uses QuickCheck, but I don't think, this is a
QuickCheck bug. The used Eq-instance is the one for Float.
The Eq-instance for floats is broken wrt NaN
Prelude> (0/0 :: Float
On 10/07/2012 12:21, Aleksey Khudyakov wrote:
On Tue, Jul 10, 2012 at 3:06 PM, Sönke Hahn wrote:
I've attached the code. The code does not make direct use of
unsafePerformIO. It uses QuickCheck, but I don't think, this is a
QuickCheck bug. The used Eq-instance is the one for Float.
I've only m
On Tue, Jul 10, 2012 at 3:06 PM, Sönke Hahn wrote:
> I've attached the code. The code does not make direct use of
> unsafePerformIO. It uses QuickCheck, but I don't think, this is a
> QuickCheck bug. The used Eq-instance is the one for Float.
>
> I've only managed to reproduce this bug on 32-bit-l
I've attached the code. The code does not make direct use of
unsafePerformIO. It uses QuickCheck, but I don't think, this is a
QuickCheck bug. The used Eq-instance is the one for Float.
I've only managed to reproduce this bug on 32-bit-linux with ghc-7.4.2
when compiling with -O2.
(The code might
Also, it is more likely to be a buggy instance of Eq, than a real loss of referential transparency.Regards,
MalcolmOn Jul 10, 2012, at 11:49 AM, Christopher Done wrote:Depends what the real offending code is. For example, if it contains unsafePerformIO then it's not a bug. On 10 July 2012 12:
Depends what the real offending code is. For example, if it contains
unsafePerformIO then it's not a bug.
On 10 July 2012 12:42, Sönke Hahn wrote:
> Hi!
>
> I've discovered a strange bug that violates simple equational reasoning.
> Basically, something similar to this:
>
> let a = f x
> in a == f
Hi!
I've discovered a strange bug that violates simple equational reasoning.
Basically, something similar to this:
let a = f x
in a == f x
evaluates to False.
I'd like to report this on ghc-trac, but I realised, that I don't know a
good name for behaviour like this. Is there one? "Broken refere
22 matches
Mail list logo