my_apply: A revised version of 'apply'
In LAJordanger/leanRcoding: Leaner R Coding

Description Usage Arguments Details Value

The ordinary version of 'apply' have the undesirable property that it always squashes the result of its function-argument into a vector, which implies that the dimension and dimension-names get lost in translation. This revised version of apply does not perform such despicable deeds. UPDATE: It does however turn out to be exceptionally inefficient when compared with 'apply', so this attempt can't be considered a success... I guess the better option should be to create a minor tweak that ensures that we reformat the matrix into the desired format instead... UPDATE, 2015-05-14, this had to be done since 'aaply' did not want to cooperate with one of the cases I wanted to use, check the function 'my_aaply' for details.

1 2	my_apply(X, MARGIN, FUN, ..., .list = FALSE, .front = TRUE, .parallel = FALSE, .cores = 1)

`X,`	`array`, the array to work upon. `X` can also be some other object in R, in as far as it can be converted to arrays. Note that a converted vector will be considered to have its first dimension equal to one, so `MARGIN` must thus equal two in case you want to use a function on its elements.
`MARGIN,`	`vector`, specifies the margins that we want to work upon. This can either be a vector of integers specifying the dimensions - or - it can be a vector with a subset of the dimension-names.
`FUN,`	`character`, the name of the function to be used.
`...,`	`dotsMethods`, to be used when `FUN` needs additional arguments.
`.list,`	`logic`, default `FALSE`, use this when you want to use `...` to feed arguments to the function `FUN` - and - those arguments already has been packed into a list or an environment. Caution: If `FUN` actually expects an argument that _is_ a list (or an environment), then the default setting is the correct one to use.
`.front,`	`logic`, default `TRUE`, decides if the new stuff originating from the result of `FUN` should be added as new dimensions at the "front" of the array - or - if it should be appended as new dimension at the "end" of the array instead.
`.parallel,`	`logic`, default `FALSE`, use this when a parallel backend is available. The argument will be ignored if no parallel backend exists.
`.cores,`	`integer`, default 1, use this when a specified number of cores are desired for the computation, and a parallel backend with that number of cores will be used to create a local backend for this computation. Any predefined backends will be restored after the computation has been performed. Remember that more isn't always better when partitioning a process into parallel chunks, and it might be preferable to not blindly use the maximum number of available cores.

I think I see the reason now... The stuff I made below will over and over again create an array with the size of the result, and that does not work very well since it induces a very high overhead for every single part of the loop.. Could this be avoided? Beats me. The idea of modifying the output instead now looks like the most promising option. That might indeed be done very simple I think, since it could boil down to just changing the dimensions to the desired format. After doing that, I guess I could include the dimension-names and so on.

This function returns an array with dimensions specified by those given in MARGIN and those originating from the result of FUN. If FUN returns a single value without any name, e.g. like sum does, then only the dimensions from MARGIN are used. Otherwise new dimensions are added, either in the "front" or the "end" depending on the value of .front (the default is in the "front"). The resulting array will inherit the names and dimension-names from X that MARGIN refers to, and similarly from the result of FUN. Dimension-names will be added if X and the result of FUN does not have them. The parts from X and FUN will then respectively be baptised with "orig_#" and "result_#", where "#" runs over the available dimensions.