Re: avoiding cost of (++)

2003-01-17 Thread John Hughes
On Thu, 16 Jan 2003, Hal Daume III wrote: I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like: mapWithout :: ([a] - b)

RE: avoiding cost of (++)

2003-01-17 Thread Gerhard Navratil
:[EMAIL PROTECTED]] On Behalf Of Hal Daume III Sent: Donnerstag, 16. Jänner 2003 17:11 To: Haskell Mailing List Subject: avoiding cost of (++) I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list

Re: avoiding cost of (++)

2003-01-17 Thread John van Groningen
Hal Daume III wrote: I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like: mapWithout :: ([a] - b) - [a] - [b] mapWithout

Re: avoiding cost of (++)

2003-01-17 Thread Christian Sievers
Hal Daume III asked: mapWithout :: ([a] - b) - [a] - [b] mapWithout f = mapWith' [] where mapWith' pre [] = [] mapWith' pre (x:xs) = f (pre ++ xs) : mapWith' (x:pre) xs Unfortunately, this is very slow, due to the overhead of (++). Any way I could speed this up would

avoiding cost of (++)

2003-01-16 Thread Hal Daume III
I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like: mapWithout :: ([a] - b) - [a] - [b] mapWithout f = mapWith' []

Re: avoiding cost of (++)

2003-01-16 Thread Iavor S. Diatchki
hi, just for fun i wrote the function in a different way. it should perform pretty much the same way as your function. i don't think the problem is (++) here, it is just the way this function is. if f is going to use all of its argument, it doesn't matter that you concatenated the two

Re: avoiding cost of (++)

2003-01-16 Thread D. Tweed
On Thu, 16 Jan 2003, Iavor S. Diatchki wrote: hi, just for fun i wrote the function in a different way. it should perform pretty much the same way as your function. i don't think the problem is (++) here, it is just the way this function is. if f is going to use all of its argument, it

Re: avoiding cost of (++)

2003-01-16 Thread Zdenek Dvorak
Hello, I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like: mapWithout :: ([a] - b) - [a] - [b] mapWithout f = mapWith'

Re: avoiding cost of (++)

2003-01-16 Thread Pal-Kristian Engstad
On Thursday 16 January 2003 08:10 am, Hal Daume III wrote: I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like:

Re: avoiding cost of (++)

2003-01-16 Thread Janis Voigtlaender
Hal Daume III wrote: I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like: mapWithout :: ([a] - b) - [a] - [b]

Re: avoiding cost of (++)

2003-01-16 Thread D. Tweed
On Thu, 16 Jan 2003, Pal-Kristian Engstad wrote: It struck me though, if you have a function that calculates something on a list 'lst', and then you calculate something on 'lst ++ [a]', then surely one should be able to cache the results from the previous calculation. I'm not a Haskell