GHC doesn't remove intermediate lists down both
branches of a zip, so yes, you'll get intermediate lists.
Okay.
Why not use array indexing, as per your second version
(only in Haskell)?
something along the lines of:
f arr = f' low 0
where (low,high) = bounds arr
f' pos acc | pos high = acc
| otherwise = f' (pos+1) (acc + arr!pos)
?
would:
sum [v!i + u!i | i - range (bounds v)]
also generate an intermediate list?
And finally, what about something like:
f u v = listArray (bounds u) [v!i * u!i | i - range (bounds u)]
versus
f u v = u // [(i, v!i*u!i) | i - range (bounds u)]
?
It's very unclear to me exactly what is going on behind the scenes with
arrays. I would like to see functions like:
afoldl, afoldr, azipWith, etc...
to be defined in the libraries, since there are so many possible
implementations and, it seems, the best implementation could be very
compiler dependent. but barring this happening, what's the best approach
to take for things like this. is // fast, or is it better to create new
arrays?
- Hal
| -Original Message-
| From: Hal Daume III [mailto:[EMAIL PROTECTED]]
| Sent: 16 May 2002 00:55
| To: GHC Users Mailing List
| Subject: efficiency of UArray
|
|
| can we expect a function like:
|
| sum [x*y | (x,y) - zip (elems v) (elems u)]
|
| to be as efficient as, say:
|
| sum = 0
| for i=1, n
| sum = sum + v[i] * u[i]
|
| ?
|
| Basically, will any intermediate lists be created here?
|
| --
| Hal Daume III
|
| Computer science is no more about computers| [EMAIL PROTECTED]
| than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume
|
| ___
| Glasgow-haskell-users mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users
|
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
