On Fri, Sep 20, 2013 at 6:17 PM, 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
>
>
Well, that's easy:
λ: decodeFloat 3.1622776601
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 floats,
On Sep 21, 2013 9:38 AM, "Colin Adams" wrote:
>
>
> On 21 September 2013 08:34, Stijn van Drongelen 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 e
On Sat, Sep 21, 2013 at 10:26 AM, Mike Meyer wrote:
> On Sat, Sep 21, 2013 at 2:21 AM, Bardur Arantsson
> 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
> > > peopl
On Sep 21, 2013 4:17 PM, "Bob Hutchison" wrote:
>
>
> On 2013-09-21, at 4:46 AM, Stijn van Drongelen wrote:
>
>> I do have to agree with Damodar Kulkarni that different laws imply
different classes. However, this will break **a lot** of existing software.
>
>
&
On Tue, Sep 24, 2013 at 5:39 PM, Sven Panne wrote:
> 2013/9/22 Mike Meyer :
> > On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson
> > 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 ac
I do think something has to be done to have an Eq and Ord with more strict
laws.
* Operators in Eq and Ord diverge iff any of their parameters are bottom.
* The default definitions of (/=), (<), (>) and `compare` are law.
* (==) is reflexive and transitive
* (<=) is antisymmetric ((x <= y && y <=
On Wed, Oct 2, 2013 at 3:49 PM, Niklas Haas wrote:
> On Wed, 2 Oct 2013 15:46:42 +0200, Stijn van Drongelen
> wrote:
> > I do think something has to be done to have an Eq and Ord with more
> strict
> > laws.
> >
> > * Operators in Eq and Ord diverge iff a
= x in x) should
yield True either. But perhaps this exception deserves its own rule.
On Wed, Oct 2, 2013 at 5:36 PM, Roman Cheplyaka wrote:
> * Stijn van Drongelen [2013-10-02 15:46:42+0200]
> > I do think something has to be done to have an Eq and Ord with more
> strict
> > laws.
On Wed, Oct 2, 2013 at 6:57 PM, Stijn van Drongelen wrote:
>
> On Wed, Oct 2, 2013 at 5:36 PM, Roman Cheplyaka wrote:
>
>> * Stijn van Drongelen [2013-10-02 15:46:42+0200]
>> > I do think something has to be done to have an Eq and Ord with more
>> strict
>>
Hi!
Your first two cases will be fixed in 7.10, as Applicative finally becomes
a superclass of Monad. I haven't really looked at your third case, so I
can't comment on that. Your fourth case is something I'd really like to see
solved properly (*together* with a better record system), but as you sa
On Thu, Oct 3, 2013 at 8:16 AM, Wvv wrote:
> > Your first two cases will be fixed in 7.10, as Applicative finally
> becomes
> a superclass of Monad.
>
> Sure, newclassses not about Applicative and Monads only.
> This question is more wider.
>
> Must Apply be a superclass of Bind?
> Must Bind be a
On Fri, Oct 4, 2013 at 10:31 PM, Wvv wrote:
> Newclasses are something like instances, but out of scope. In a baggage.
>
So under the hood of GHC, newclasses would be partially filled in
dictionaries.
We already have too many classes: (...)
>
> We can't divide all classes to atimic ones.
>
As
13 matches
Mail list logo