Am 11.04.2019 um 15:07 schrieb Riccardo (Jack) Lucchetti:
On Thu, 11 Apr 2019, Sven Schreiber wrote:
>> I'm thinking: would it be worthwhile to add this to the "extra"
package?
>
> What's the use case, by the way?
I'm using aggregate() on a string-valued variable and I'd like to be
able to sort the results alphabetically.
OK sorry, the thread then took a different direction. To be honest there
have been a bunch of ideas about "extra" over the last months (some by
myself) and I haven't really kept track. Probably I need to search the
archives to construct a list of potential additions.
In this particular case, is this still on the table? The alternative was
a C function I think.
> Speaking about arrays and the extra package: I don't want to
hijack your
> thread, but I've thought that a function would be useful that takes an
> array argument and applies some operation (another function)
> automatically to all elements of the array.
Something like this, you mean
...
ret[i] = feval(op, A[i])
...
That'd be nice to have as a native funciton, so that we don't
have to
write a separate function for every array type we have (unless we find a
mechanism for having "array" as a function argument type).
Yes, what about this idea?
BTW, I think there are at least two other theoretical possibilities to
enable the same hansl function for various input types:
1) If each object type only occurs once in the function signature,
loosen the requirement of positional arguments.
Such that for the signature:
function void myfunc(matrices mm[null], strings ss[null])
both these calls would be allowed: myfunc(mymatarr) and myfunc(mystrarr).
2) Named arguments -- this would of course be a substantial undertaking
to implement I guess. So given the likely fallout I'm not sure I like
the idea.
cheers
sven