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.

Submitted by Amir Livne Bar-On (not verified) on Tue, 06/28/2005 - 2:29pm.

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.

Submitted by Paul Johnson (not verified) on Fri, 07/08/2005 - 8:24pm.

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.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.