How do you feel about not being able to modify arrays in-place
Submitted by metaperl on Tue, 06/28/2005 - 9:21am.
I was wondering if you thought it was efficient to only be able to return a new array for each modification of an array.
It seems like it would be a great hindrance to efficiency in comparison with a procedural approach to a programming problem.
- metaperl's blog
- Login to post comments
Creating a new array is a wasteful operation, unless you actually need two arrays, so it's not good to create new arrays.
Most languages with array-copying semantics provide optimization, so arrays aren't usually copied.
Even if they are copied, it might be copy-on-write, or GC can make the new array be allocated in place of the old array.
Haskell also provides mutable arrays, and unboxed arrays.
It doesn't bother me. In addition to the previous poster's mention of unboxed arrays and the mutable (i.e. monadic) arrays, very few jobs
actually seem to require arrays: lists are usually a more natural structure, and associative arrays (module Data.Map) offer O(log n)
behaviour as well.
Even when traditional arrays are necessary, a lot of array processing can actually be represented as list processing with arrays providing accumulators. So for example if I were doing matrix addition I would write something like:
matrixAdd a b = accumArray (+) 0 (bounds a) (assocs a ++ assocs b)
This assumes that a and b are the same size of course,
and the use of list concatenation might not be the fastest method of getting both arrays in there. ZipWith might be a better solution. But you can see the idea.
Paul.