Re: need help
Mark Alexander Wotton
> i tried on the list library but havent find something useful.i dont want to
> sort the list but just to produce a list of lists with every list having
> the same items. i.e from [a,a,b] to get [[a,a],[b]].
>
> ive done this so far but cant finish it
>
> list :: [a] -> [[a]]
> list [] = []
> list (h:[]) = [[h]]
> list(h:t)=...
>
> thank u
I think you need to make it a bit clearer what you're trying to do.
would ['a','b','a'] go to [['a','a'],['b']], for instance, or are you
just trying to group them locally?
mrak
--
realise your life was only bait for a bigger fish
-- aesop rock
Vincenzo Ciancia
> fun [a,a,b,c,a,b] will give back [[a,a,a],[b,b],[c]] any ideas?
If you look at Prelude.List I bet you'll find a couple of useful functions
to do what you need, perhaps start by sorting the list :)
V.
--
Please notice that my e-mail address has been altered to prevent spam
Adrian Hey
> On Thu, 14 Oct 2004 20:15:11 -0400, valez posted:
>> i tried on the list library but havent find something useful.i dont want
>> to sort the list but just to produce a list of lists with every list
>> having the same items. i.e from [a,a,b] to get [[a,a],[b]].
>>
>> ive done this so far but cant finish it
>>
>> list :: [a] -> [[a]]
>> list [] = []
>> list (h:[]) = [[h]]
>> list(h:t)=...
>>
>> thank u
>
> I think you need to make it a bit clearer what you're trying to do.
> would ['a','b','a'] go to [['a','a'],['b']], for instance, or are you
> just trying to group them locally?
Actually I think valez aims were clear from his first post.
One easy way is with my own pet AVL library:-)
http://homepages.nildram.co.uk/~ahey/HLibs/Data.Tree.AVL/
(Probably only installs properly with ghc at the moment).
The following does the trick I think..
import Data.Tree.AVL
fun :: Ord a => [a] -> [[a]]
fun as = [ replicate n a
| (a,n) <- asListL (asTreeKeyWith' (+) [(a,1) | a <- as])
]
I guess you could do something similar with Data.FiniteMap too.
I'll leave figuring out how it works as an exercise for valez :-)
(newbie hint: uses two list comprehensions)
Regards
--
Adrian Hey
Tomasz Zielonka
> Mark Alexander Wotton wrote:
>
> The following does the trick I think..
>
> import Data.Tree.AVL
>
> fun :: Ord a => [a] -> [[a]]
> fun as = [ replicate n a
> | (a,n) <- asListL (asTreeKeyWith' (+) [(a,1) | a <- as])
> ]
A bit too complicated for my taste. Also, you would equalize externally
unequivalent Eq-ual elements, if you know what I mean ;)
Here's another hint: fun can be written as
fun l = f1 (f2 l)
where f1 and f2 are some function from module List.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
Mark Alexander Wotton
> Tomasz Zielonka wrote:
>> A bit too complicated for my taste. Also, you would equalize externally
>> unequivalent Eq-ual elements, if you know what I mean ;)
>
>
> Damn, that's what you get when you try to look smarter than you really
> are ;)
>
> Best regards,
> Tom
well, now that we've thoroughly confused the original poster... :)
Tomasz Zielonka
> unequivalent
or is that inequivalent?
best regards,
tomasz
Adrian Hey
> Adrian Hey wrote:
>> Mark Alexander Wotton wrote:
>>
>> The following does the trick I think..
>>
>> import Data.Tree.AVL
>>
>> fun :: Ord a => [a] -> [[a]]
>> fun as = [ replicate n a
>> | (a,n) <- asListL (asTreeKeyWith' (+) [(a,1) | a <- as])
>> ]
>
> A bit too complicated for my taste. Also, you would equalize externally
> unequivalent Eq-ual elements, if you know what I mean ;)
I think I know what you mean, but I don't think it's a problem. AFAIK for
all predefined or derived instances of Ord and Eq the following
holds..
(x `compare` y = EQ) implies (x == y = True)
and..
(x == y = True) implies (x = y)
I always thought that was the intended semantics anyway.
> Here's another hint: fun can be written as
>
> fun l = f1 (f2 l)
>
Yes, I think this solution must be what whoever set this problem
had in mind. (Though if it uses the standard H98 sort I wouldn't
advocate it's use in real programs :-)
Regards
--
Adrian Hey
Adrian Hey
> (Though if it uses the standard H98 sort I wouldn't
> advocate it's use in real programs :-)
I've just had a look at the Data.List source code and it seems someone
has changed the sort to something much better than that defined in the
H98 standard libraries. (I don't want to spread misinformation on this,
hence this post).
Regards
--
Adrian Hey
Tomasz Zielonka
From The Haskell 98 Report:
8 Standard Prelude
In this chapter the entire Haskell Prelude is given. It constitutes a
specification for the Prelude. Many of the definitions are written with
clarity rather than efficiency in mind, and it is not required that the
specification be implemented as shown here.
As you can see there is no obligation to use the implementation from The
Report.
Adrian Hey
> From The Haskell 98 Report:
>
> 8 Standard Prelude
>
> In this chapter the entire Haskell Prelude is given. It constitutes a
> specification for the Prelude. Many of the definitions are written with
> clarity rather than efficiency in mind, and it is not required that the
> specification be implemented as shown here.
>
> As you can see there is no obligation to use the implementation from The
> Report.
You're gonna think I'm nit-picking, but sort isn't part of the prelude, so
these words don't apply :-)
You'd think that similar words would have been used for the standard
libraries too, but I can't find them. In fact, IIRC someone recently
stated on one of the Haskell mailing lists that to be H98 compliant,
the standard libraries had to be implemented exactly as given in the
report. Unfortunately I've forgotten who it was :-(
But seeing as we're actually talking about sort from Data.List I guess
none of this matters really (H98 standard is N/A anyway).
Though why the Haskell folk chose to include such an obviously crap
sort algorithm in the standard in the first place has always puzzled
me (and a many other folk too I think). Even if there was an unstated
assumption that implementors would not be foolish enough to use it
in practice, it's appearance is just plain embarrassing IMO :-)
Regards
--
Adrian Hey