The striding access in core.strides currently allows slicing existing ndarray views that allow flexible access of array slices. Since core.cmath._op() basically offers two variants of basic MAC operations it could be of advantage to call them by their names and to reflect this abstract connection by the actual implementation.
By introducing operations that work on some sort of stride pointer (with a defined incrementation behaviour) one could separate an operation from
Doing so will have the following positive effects:
There will be one straightforward approach to implement such functions
There is one distict place to do type case multiplexing (reduces compilation complexity). As a side effect casting warnings, that are seen in some compiler configurations (most notably on Appveyor builds) will disappear as well due to the clearer type handling routines.
in-place and incrementation and "walking increments" along a certain stride are now possible while using the same code.
in-place and regular scalar and dot multiplication as well as computing norms will be possible with no extra code overhead neccessary.
All BLAS functionality within fastmat is contained in one (quite compact) place and mostly limits on one reasonably flexible MAC operation that handles a limited set of data types and some data movement and addressing operations
The striding access in
core.stridescurrently allows slicing existing ndarray views that allow flexible access of array slices. Sincecore.cmath._op()basically offers two variants of basic MAC operations it could be of advantage to call them by their names and to reflect this abstract connection by the actual implementation.By introducing operations that work on some sort of stride pointer (with a defined incrementation behaviour) one could separate an operation from
Doing so will have the following positive effects: