Add array.any() and array.all()

[CallumJHays]

array.any() https://numpy.org/doc/stable/reference/generated/numpy.ndarray.any.html

array.all() https://numpy.org/doc/stable/reference/generated/numpy.ndarray.all.html

[v923z]

Do you want to have ndarray.any, or numpy.any? Even if the code has to be implemented only once, any new binding adds to the code size.

[CallumJHays]

I would prefer ndarray.any, but it's actually just occurred to me that I can use python's any() and all() on ndarray instead for my purposes (my data is quite small, and I have no need for the axis arg).

Given the code size / compatibility dilemma in general, do you think it's worth implementing small features like this (even if they are behind an #ifdef)? Should a line be drawn?

[v923z]

Given the code size / compatibility dilemma in general, do you think it's worth implementing small features like this (even if they are behind an #ifdef)? Should a line be drawn?

No, I don't think so. As long as it is customisable, it should be fine. We might have to add more documentation in the ulab.h header file itself, but that is OK.

As far as compatibility is concerned, we have tried to stick with numpy's convention in the past. This doesn't mean that all features, keywords etc. must be implemented, but that ulab code should run in CPython. The sole exception is the Fourier transform. Implementing all operators for complexes would definitely increase the firmware size considerably.

[v923z]

These two functions should be added to https://github.com/v923z/micropython-ulab/blob/master/code/compare/compare.c

[v923z]

@CallumJHays Cal, do you think you could add test scripts? The PR is here: #309

[CallumJHays]

@v923z ok I'll try to get it and #305 done this afternoon

[v923z]

#348 should close the issue.