CLN: remove arrmap, closes #27251

[jbrockmendel]

No description provided.

[jbrockmendel]

This removes the dependency of this module on non-cython parts of the code

[simonjayhawkins]

#27251 (comment) was it not feasible to just use np.vectorize? is there is a perf impact?

[jbrockmendel]

feasible to just use np.vectorize?

Probably. My understanding was that is just a fancy for-loop. Am I missing something?

is there is a perf impact?

Haven't measured. On the one hand we get rid of a call to lib.maybe_convert_objects (and a semi-expensive runtime import), and on the other we do a python-space list comprehension. My assumption is that this isn't called with particularly large arrays for the quantile arg.

One alternative would be to keep arrmap_float64 and specialize it given that we know the output will be float64. We'd still get to remove the maybe_convert_objects call, which is what I'm most excited about.

[simonjayhawkins]

feasible to just use np.vectorize?

Probably. My understanding was that is just a fancy for-loop. Am I missing something?

so according the numpy docs, The vectorize function is provided primarily for convenience, not for performance. so I guess that using a list comprehension is a sensible approach.

Haven't measured. On the one hand we get rid of a call to lib.maybe_convert_objects (and a semi-expensive runtime import), and on the other we do a python-space list comprehension. My assumption is that this isn't called with particularly large arrays for the quantile arg.

One alternative would be to keep arrmap_float64 and specialize it given that we know the output will be float64. We'd still get to remove the maybe_convert_objects call, which is what I'm most excited about.

i'll leave that to you to decide if its worth further investigation.

[jreback]

@simonjayhawkins yeah we talked about this in a previous issue. even if this was a measureable slowdown, would still take it in reducing complexity.

[jreback]

thanks @jbrockmendel