Docs should say that hi/lo accept nulls about ndarray HOT 7 OPEN

Can you elaborate on your use case? I've used it to just just slice an array in one particular dimension without specifying the bounds of the others.

from ndarray.

Yes exactly, that's what I do as well, slicing across one or more dimensions and leaving others untouched (where I use null then instead of giving explicit full bounds).

from ndarray.

See: https://github.com/scijs/ndarray-concat-rows/blob/master/index.js#L72

I'm updating the docs for another ticket so will add a note on this now.

from ndarray.

What about the example? I don't see any null's.

Am 07.01.2016 um 21:49 schrieb Ricky Reusser:

See: https://github.com/scijs/ndarray-concat-rows/blob/master/index.js#L72

I'm updating the docs for another ticket so will add a note on this now.

—
Reply to this email directly or view it on GitHub
#23 (comment).

from ndarray.

Ah, sorry. Yeah, seemed (unless I'm wrong) that as long as it's undefined or null (omitted as an argument = undefined), lo doesn't increase the lower bound and hi doesn't decrease the upper bound in the unspecified dimensions.

from ndarray.

In other words, I used that to grab a section of the ndarray along the first dimension only by leaving the others implicitly unspecified. Concatenating cols was a little more complicated because I had to construct the array of indices explicitly.

(Side note: I'm realizing as I clean some of this up that really more and more of the code should use dynamic code generation to keep this generic n-dimensional programming from actually having to operate in an abstract number of dimensions. With code generation, you just generate the code for the actual number of dimensions for the given input…)

But anyway, AFAIK, either null or implicitly undefined both works.

from ndarray.

Right, ok.

About dynamic code generation, as long as it actually has a measureable performance benefit and the code is used enough times that it matters I'm all for it.

from ndarray.