As part of my ongoing campaign to make NDArray<T> behave more like kotlin's Collection<T> this PR adds to*** functions that convert NDArrays into row-major 1D objects that behave like builtins.
NDArray<T>.toTypedArray(): Array<T>
NDArray<T>.toList(): List<T>
NDArray<T>.toMutableLIst(): MutableList<T>
NDArray<Double>.toDoubleArray(): DoubleArray for each of the special-cased numerical NDArray types
The first three are just convenience methods, but the last one avoids a round of boxing and unboxing that would occur using the technique it replaced:
someNdArray.toIterable().toList().toDoubleArray()
// ^- lg n array allocations + n boxing allocations
// ^- n unboxings
toDoubleArray() and its brethren use .size and the non-boxing linearized getters introduced in #51, so the number of allocations should be O(1).
As part of my ongoing campaign to make
NDArray<T>behave more like kotlin'sCollection<T>this PR addsto***functions that convert NDArrays into row-major 1D objects that behave like builtins.NDArray<T>.toTypedArray(): Array<T>NDArray<T>.toList(): List<T>NDArray<T>.toMutableLIst(): MutableList<T>NDArray<Double>.toDoubleArray(): DoubleArrayfor each of the special-cased numerical NDArray typesThe first three are just convenience methods, but the last one avoids a round of boxing and unboxing that would occur using the technique it replaced:
toDoubleArray()and its brethren use.sizeand the non-boxing linearized getters introduced in #51, so the number of allocations should be O(1).