use different package for ndarray

[xnought]

Move to stdlib.js array

• [x] abstract this away in other class
• [ ] reimplement prefix sum
• [ ] reimplement slicing
• [ ] reimplement subtraction across slices

[xnought]

This can now be translated into whatever format by just reimplementing the falconArray.ts file. Right now its still in NdArray js format

[kgryte]

Hello! Stopping by from stdlib-land. One small comment regarding the falconArray abstraction layer. I'd recommend migrating to stdlib property naming conventions (see ndarray/ctor). In particular, instead of the scijs convention of stride, use strides, which is what is used by TF.js and stdlib (and NumPy for that matter). And instead of size, I'd recommend length, which is the stdlib convention.

Thinking ahead to the future, these suggestions are intended to ensure that future contributors see similar idioms in the Falcon ndarray abstraction layer provided they are already familiar with stdlib (and other) ndarrays.

[xnought]

Great points altogether. I'll make those changes. Thanks for the response and links!

I do have a weird attachment to size. I have to reflect why I have that proclivity before I change that to length

[kgryte]

Understandable. For context, the PyData convention largely stems from len(x) returning x.shape[0] (similar to nested lists), which is something which is considered a mistake for ndarrays. Thus, there was a need for a different attribute (e.g., size) to indicate the total number of elements.

For stdlib, we wanted to maintain consistency with existing JS convention for array-like objects; namely, using length to indicate how many elements an object contains. If you wanted to, you could keep both and just reflect size to length.

Regardless, while not strictly assumed by stdlib, we cannot guarantee that we won't check for a .length property as a shorthand for numel(shape) in various ndarray functions, so your mileage may vary.

[xnought]

Aha that makes sense!