Polyfills about ndarray-blas-level1 HOT 8 OPEN

Am working on cleanup. In this case, do we actually want a full polyfill? It seems like x > 0 ? 1 : -1 would be adequate since typed arrays are guaranteed to be numeric (or NaN), and validating that every entry of an Array is numeric seems unnecessary. In other words, seems like maybe the full spec-compliant Math.sign isn't actually a perfect fit for operations like this.

from ndarray-blas-level1.

If this is the case, then a polyfill would only export the replacement, which could perhaps be simplified:

See: https://github.com/scijs/ndarray-blas-level1/blob/cleanup/lib/sign.js

from ndarray-blas-level1.

You're probably right about not needing the entire polyfill for typed arrays. (BTW we'd have to do something like x === 0 ? 0 : (x > 0 ? 1 : -1) since we'd need to handle x = 0).

The real problem then comes when someone specifies an Array for the data array. ndarray allows for that, so I'm not sure what the best option is there.

from ndarray-blas-level1.

Yeah. I think though that if your code fails because addition is undefined for boxed objects in an Array, we can maybe just let that throw an error on its own or spit out a bunch of NaNs. The only alternative seems to be trapping errors (unoptimizable) or validating each element (unnecessary).

Tangentially, I'm working now on a module that parses the code via esprima and applies transformations (something like A.get(i, j) --> A[A.offset + i * A.stride[0] + ...]) so that hopefully we'll be able to apply some data-type-aware logic and write a single function in get/set notation that's optimized to operate on vanilla arrays, ndarrays (generic get/set and normal), arrays of arrays… The goal is to add reasonably intelligent optimizations like blocking and loop reordering…

from ndarray-blas-level1.

(At risk of getting OT), see: https://github.com/rreusser/loop-experiments

from ndarray-blas-level1.

I guess we can possibly force the consumers to validate their inputs (gasp!). Half of the Math.sign polyfill is validating that it's not NaN or coercing the value to numeric.

from ndarray-blas-level1.

The behavior is nice, I guess, but not so necessary for what's going on here:

> isNaN('string')
true

> isNaN(5)
false

> isNaN('5')
false

from ndarray-blas-level1.

And yeah, adding input validations is a huge item that needs to be handled (scijs-validations?), but validating the content of data input is a huge performance hit that we probably don't want unless a situation definitely calls for it.

Wondering if we need to make a big repo with scijs-validations/is-ndarray, scijs-validations/is-object and similar. Again, the math.io approach is validate.io which is outstanding, but I'm worried about the maintainability of 100+ repos for validations.

from ndarray-blas-level1.