apply for arrays?

[hartrock]

[update] -> 10.5.6.

Code Select Expand


(setq a (array 10 (sequence 1 10)))

;; currently we have:
(setq a_applied (apply + (array-list a)))

;; nice would be:
(setq a_applied (apply-array + a))
;; or:
(setq a_applied (apply + a))

Func apply-array could work at source array directly (without indirection by conversions to/from lists).

Because
 

[*] it shouldn't be more expensive than its list counterpart,

[*] the result type depends on to be applied function and not on source to be applied to (array);

[/list]
it probably could be named the same (and internally just do the right thing).

[Lutz]

Both map and apply also take arrays in the next version, but will do array -> list conversion internally to keep code changes / additions to a minimum leveraging existing code.

[rickyboy]

If the input "sequence" is an array, what would the output "sequence" be -- an array or list?

[hartrock]

If the input "sequence" is an array, what would the output "sequence" be -- an array or list?

For map the output naturally would be an array (for apply applied func decides).



A multi-dimensional array can be seen as an array of arrays: then map would just map first dimension.

This seems to be the semantics of array; at least it's possible to replace elements of first dim by both lists and arrays, without changing the type of the array:

Code Select Expand

> (setq a (array 2 5 (sequence 0 9)))
((0 1 2 3 4) (5 6 7 8 9))
> (setq (a 0) (sequence 10 14))
(10 11 12 13 14)
> (setq (a 1) (array 5 (sequence 15 19)))
(15 16 17 18 19)
> (array? (a 0))
nil
> (array? (a 1))
true
>> (array? a)
true
>

In case of mapping all lowest-level elements - e.g. pixels in an image - map had to be nested.

[hartrock]

Both map and apply also take arrays in the next version, but will do array -> list conversion internally to keep code changes / additions to a minimum leveraging existing code.

This sounds good!



There are some functions for which there are different performance characteristics for lists and arrays: e.g. an assoc for arrays should be slower for large arrays compared to lists. In such cases there is a trade-off, because there are two possibilities for making such a function applicable for the other data type:

[*] Use the same name: comfortable to use (unification), but may create performance surprises, if list arg gets an array or vice-versa;

[*] use another name: less comfortable to use, but you have it explicit, that a list or an array is expected, and exclude the other data type.

[/list]
My point has been - under the assumption, that arrays are specially made just for performance reasons -, that this kind of trade-off needn't be applied for apply, if it will be implemented accordingly. So far I had seen array-list as a result of the will to make computation effort visible (you explicitely have to convert), and not as something, which has to be there.