Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Athan
    @kgryte
    In short, just not clear what a user intends when only providing nested arrays and describing the order as column-major without also specifying the desired output shape.
    Ricky Reusser
    @rreusser
    stdlib.array([[1, 2], [3, 4], [5, 6]], { order: 'column-major' })
    Athan
    @kgryte
    The reason being that nested arrays are inherently row-major.
    Ricky Reusser
    @rreusser
    can you help me understand why you'd expect that to be a 3x2 matrix instead of 2x3?
    Athan
    @kgryte
    Because “order” is descriptive, not prescriptive.
    Ricky Reusser
    @rreusser
    ah, that's a good, simple explanation
    Athan
    @kgryte
    By only specifying the order, you are telling me in what order the data is already laid out.
    Not how you want it to be.
    This is discussed in the documentation: https://github.com/stdlib-js/stdlib/blob/65a0057aca6be5022275ae740c113376d73fd3e7/lib/node_modules/%40stdlib/ndarray/array/docs/repl.txt#L41
    (and in the README under the options docs)
    Obviously, there is a tension here between providing an API which tells us how to interpret a provided data buffer and providing an API which reshapes a data buffer to conform to a specified layout.
    For example, this API supports providing a linear buffer. In this case, it makes sense to “describe” the linear buffer layout. In your use case, you want to “prescribe” the end layout result which could involve copying memory around.
    Ricky Reusser
    @rreusser
    yeah, I think I understand better what you mean now. do I understand correctly that it primarily affects how .get works?
    (and perhaps some other functions)
    but basically that it doesn't change storage but instead affects only how you interpret the data?
    Athan
    @kgryte
    Yes, that is correct.
    Ricky Reusser
    @rreusser
    that makes sense. if i'm being honest, it seems logically consistent and defensible but a bit counterintuitive that the convenience interface doesn't do what I (to pick one biased sample) would expect, which is to treat an array of arrays (which I'd assume is primarily a friendly convenience interface in the first place) as a list of columns when you specify the input is column-major
    or maybe it's a tension between the technical and english-language meaning of "column major"
    Athan
    @kgryte
    I think maybe the ambiguity is more apparent when providing a square matrix based on nested arrays, say, 3x3. If you specify the order as column-major, does that mean the data is already in column-major order? or does it mean that we should copy elements around to be localized in memory according to column-major order? Not clear to me which we should choose without the user providing additional info, etc, because two different users could each want different things.
    The current behavior simply assumes that a user is a bit more “expert” in having already constructed nested arrays to generate the desired linear layout and then just tells us the order in order to ensure proper data access.
    Ricky Reusser
    @rreusser
    I worded it in my head as: "here is input. by "column major" I mean that I am specifying it by walking down a column first
    yeah. to be honest it's probably best to deemphasize the feature for general usage and perhaps really provide in the docs an example like this where it will bite you
    a related question: I was adapting mikola's fft module to work with @stdlib/ndarray
    Athan
    @kgryte
    Yeah, I get that. But that basically means we need to hop around in the nested arrays and do a manual copy to ensure the right layout.
    Re: docs. Agreed.
    Ricky Reusser
    @rreusser
    if I were to write a module that uses ndarrays, how do I need to handle row vs. column major data?
    are my choices to either
    1. use getters/setters everywhere
    2. implement support for row and column major separately
    Athan
    @kgryte
    I would just use the getter/setter APIs.
    Ricky Reusser
    @rreusser
    I haven't benchmarked this, but past benchmarking has made me doubt JS engine's ability to inline things like this
    specifically, I'd expect a non-negligible performance hit from some combination of 1) executing get/set via callbacks, and 2) bounds-checking every access in inner loops
    Athan
    @kgryte

    Re: 2. The lower-level API (i.e., base) does not do bounds checking.

    Re: 1. This should get inlined in modern engines. https://github.com/stdlib-js/stdlib/blob/develop/lib/node_modules/%40stdlib/ndarray/base/ctor/lib/compile_get.js

    Ricky Reusser
    @rreusser
    (anecdotally, I measured a 25x speedup on a task similar to computing the surface area of a mesh by inlining dot and cross products and similar operations rather than leaning on gl-matrix for everything)
    Athan
    @kgryte
    This is the expected output from compiling a getter: https://github.com/stdlib-js/stdlib/blob/develop/lib/node_modules/%40stdlib/ndarray/base/ctor/lib/compile_get.js#L81
    That should be readily inlined.
    Ricky Reusser
    @rreusser
    got it, thanks. I'll benchmark this once I get it working
    Athan
    @kgryte
    …but we’d need to use an updated version of something like IRHydra to be sure.
    Ricky Reusser
    @rreusser
    last time I benchmarked it was probably a year and a half ago. I was rather disappointed.
    Athan
    @kgryte
    I’d be surprised if modern compilers did not inline the getter.
    If getters and setters are not compiled, I can imagine that non-compiled getters/setters would be harder to inline. https://github.com/stdlib-js/stdlib/blob/65a0057aca6be5022275ae740c113376d73fd3e7/lib/node_modules/%40stdlib/ndarray/base/ctor/lib/get.js
    Ricky Reusser
    @rreusser
    anyway, thanks. I'll give this a try when i get there.
    Athan
    @kgryte
    Awesome. Thanks for raising this issue!
    Athan
    @kgryte

    @rreusser For reference, you can find getter/setter benchmarks here: https://github.com/stdlib-js/stdlib/blob/8c3884542fd9b04dfc82ca8a12260e783cf70e96/lib/node_modules/%40stdlib/ndarray/base/ctor/benchmark/benchmark.js#L833

    Inlined benchmarks are not included, but could be.

    Athan
    @kgryte

    Heads-up for all those working on stdlib development atm. Currently a bug in one of our dev dependencies that is causing Markdown linting and example execution to fail. (see unifiedjs/unified-engine#41)

    Until this is resolved, if you are committing Markdown files, you’ll need to use the —no-verify Git command-line flag.

    Terence Yang
    @Tranced
    Just wanted to tackle the issues surrounding the mathematical functions (sec, cosc ect). Can't wait to tackle those in the next few days. Thought I should ping here instead of replying on 13 different issues.
    Athan
    @kgryte
    @Tranced That’s awesome! Thanks!
    Athan
    @kgryte
    @Tranced After submitting a PR for sec, just comment on the next RFC you want to resolve, and we’ll iterate from there. :)
    Gabriel Dodan
    @gabrieldodan_twitter
    Hi, is there support for kernel regression https://en.wikipedia.org/wiki/Kernel_regression ?
    i have searched in the documentation but havn't found anything related to kernel regression
    thanks!
    Philipp Burckhardt
    @Planeshifter
    @gabrieldodan_twitter Currently, we do not have kernel regression inside of stdlib. I worked on it in the past (https://github.com/Planeshifter/kernel-smooth), and could prioritize bringing this functionality into stdlib. May I ask you about the timeline when you would need to have a kernel regression package available?