On Mon, Apr 07, 2008 at 04:52:51AM -0700, John Meacham wrote:
> On Mon, Apr 07, 2008 at 04:45:31AM -0700, David Roundy wrote:
> > I wonder about the efficiency of this implementation. It seems that for
> > most uses the result is that the size of a Nat n is O(n), which means that
> > in practice y
Hi,
Am Freitag, den 04.04.2008, 22:44 +0100 schrieb Neil Mitchell:
> Hi
>
> > We can however write function like this:
> >
> > eqLengths [] [] = True
> > eqLengths (x:xs) (y:ys) = eqLengths ys xs
> > eqLengths _ _ = False
> >
> > which looks just fine for me.
>
> I have this defined functio
On 2008-04-04, Neil Mitchell <[EMAIL PROTECTED]> wrote:
>> What do you mean by "proper Lazy naturals"? Peano ones?
>
> Yes
Not _strictly_ necessary. And I'd definitely like some suitable
typeclass put in place. This represents positive arithmetic with
a list homomorphism that forgets the elemen
On Mon, Apr 07, 2008 at 04:45:31AM -0700, David Roundy wrote:
> I wonder about the efficiency of this implementation. It seems that for
> most uses the result is that the size of a Nat n is O(n), which means that
> in practice you probably can't use it for large numbers.
>
> e.g. it seems like
>
On Sun, Apr 06, 2008 at 07:12:24AM -0700, John Meacham wrote:
> On Fri, Apr 04, 2008 at 04:46:22PM +0100, Neil Mitchell wrote:
> > Where length xs = 1 and ys = 1000. This takes 1000 steps to tell the
> > Int's aren't equal, since we don't have proper lazy naturals. If we
> > did, it would take 2 st
On Sun, Apr 06, 2008 at 11:30:20AM -0300, Felipe Lessa wrote:
> On Sun, Apr 6, 2008 at 11:12 AM, John Meacham <[EMAIL PROTECTED]> wrote:
> > I implemented this efficient lazy natural class once upon a time. it
> > even has things like lazy multiplication:
> [...]
> > instance Num Nat where
> >
On Sun, Apr 6, 2008 at 11:12 AM, John Meacham <[EMAIL PROTECTED]> wrote:
> I implemented this efficient lazy natural class once upon a time. it
> even has things like lazy multiplication:
[...]
> instance Num Nat where
> Zero + y = y
> Sum x n1 + y = Sum x (y + n1)
> --x + Zero = x
>
On Fri, Apr 04, 2008 at 04:46:22PM +0100, Neil Mitchell wrote:
> Where length xs = 1 and ys = 1000. This takes 1000 steps to tell the
> Int's aren't equal, since we don't have proper lazy naturals. If we
> did, it would take 2 steps.
>
> Read this: http://citeseer.ist.psu.edu/45669.html - it argue
On Fri, Apr 4, 2008 at 5:45 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> ndmitchell:
> > Note: In case anyone gets the wrong impression, I am not suggesting
> > lazy naturals be the standard numeric type in Haskell, just that by
> > not going that way we have paid a cost in terms of elegance.
>
Don Stewart wrote:
> length, take, drop and index working on machine-sized Ints by default
> are really a bit of a wart, aren't they?
Definitely. See http://cdsmith.wordpress.com/2007/07/05/find-the-bug/
for my account of this problem when I ran into it last summer.
In particular, the combinati
ndmitchell:
> Hi
>
> > We can however write function like this:
> >
> > eqLengths [] [] = True
> > eqLengths (x:xs) (y:ys) = eqLengths ys xs
> > eqLengths _ _ = False
> >
> > which looks just fine for me.
>
> I have this defined function. I also have lenEq1, lenGt1, and a few
> other variant
Hi
> We can however write function like this:
>
> eqLengths [] [] = True
> eqLengths (x:xs) (y:ys) = eqLengths ys xs
> eqLengths _ _ = False
>
> which looks just fine for me.
I have this defined function. I also have lenEq1, lenGt1, and a few
other variants. It works, but it just doesn't fee
On Fri, Apr 4, 2008 at 7:14 PM, Jake Mcarthur <[EMAIL PROTECTED]> wrote:
> On Apr 4, 2008, at 11:31 AM, Loup Vaillant wrote:
>
> > I mean, could we calculate this equality without reducing
> > length ys to weak head normal form (and then to plain normal form)?
> >
>
> Yes. Suppose equality over Na
"Neil Mitchell" <[EMAIL PROTECTED]> writes:
>> length, take, drop and index working on machine-sized Ints by default
>> are really a bit of a wart, aren't they?
> Yes. Also, having strict Int's by default is a bit ugly,
[..]
> (Not that it isn't a worthwhile trade off, but it is still loosing
On Apr 4, 2008, at 11:31 AM, Loup Vaillant wrote:
I mean, could we calculate this equality without reducing
length ys to weak head normal form (and then to plain normal form)?
Yes. Suppose equality over Nat is defined something like:
Z == Z = True
S x == S y = x == y
x == y
Hi
> > > I meant:
> > > (\x (y :: Int) -> x + 1) 1 (1/0 :: Int) <=> _|_ ?
> >
> > Division by 0 is still an error. What I mean is:
>
> Yes, but this particular one need not be performed. Will it be?
Oh, sorry, I misread that. Even with current Haskell's Int's that is
lazy enough to work,
2008/4/4, Neil Mitchell <[EMAIL PROTECTED]>:
> > > > Also, having strict Int's by default is a bit ugly, in an
> > > > otherwise lazy-by-default language.
> >
>
> > I meant:
> > (\x (y :: Int) -> x + 1) 1 (1/0 :: Int) <=> _|_ ?
>
> Division by 0 is still an error. What I mean is:
Yes,
> > > Also, having strict Int's by default is a bit ugly, in an
> > > otherwise lazy-by-default language.
>
> I meant:
> (\x (y :: Int) -> x + 1) 1 (1/0 :: Int) <=> _|_ ?
Division by 0 is still an error. What I mean is:
length xs == length ys
Where length xs = 1 and ys = 1000. This takes
2008/4/4, Neil Mitchell <[EMAIL PROTECTED]>:
>
> Also, having strict Int's by default is a bit ugly, in an
> otherwise lazy-by-default language.
You do mean that, for example
(\x -> x + 1) (1/0 :: Int) <=> _|_ ?
Does it bites often (and how, if you have any example)?
cheers,
Loup
_
On Fri, Apr 04, 2008 at 12:34:54PM +0100, Neil Mitchell wrote:
> > length, take, drop and index working on machine-sized Ints by default
> > are really a bit of a wart, aren't they?
>
> Yes. Also, having strict Int's by default is a bit ugly, in an
> otherwise lazy-by-default language. It's a pl
Hi
> length, take, drop and index working on machine-sized Ints by default
> are really a bit of a wart, aren't they?
Yes. Also, having strict Int's by default is a bit ugly, in an
otherwise lazy-by-default language. It's a place where Haskell decided
to remove mathematical elegance for pragmat
On Thu, Apr 3, 2008 at 11:13 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> length, take, drop and index working on machine-sized Ints by default
> are really a bit of a wart, aren't they?
>
> -- Don
Agreed,
Olivier.
___
Haskell-Cafe mailing list
Haskel
Don Stewart wrote:
>> Which, incidentally, also explains why Don couldn't reproduce it on a 64-
>> bit system. There, instead of hanging for about a minute before printing
>> out the list, it would hang for about 4 billion minutes.
A billion minutes here, a billion minutes there, and pretty soo
cdsmith:
> Bryan O'Sullivan wrote:
> > It's not an infinite list. It's a list of length maxBound::Int, as
> > required by the fact that take's first argument is an Int. The second
> > argument is probably defaulting to Integer.
>
> Which, incidentally, also explains why Don couldn't reproduce it
Bryan O'Sullivan wrote:
> It's not an infinite list. It's a list of length maxBound::Int, as
> required by the fact that take's first argument is an Int. The second
> argument is probably defaulting to Integer.
Which, incidentally, also explains why Don couldn't reproduce it on a 64-
bit system.
25 matches
Mail list logo
