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
    @mike442144 Thanks for your interest! You can find the contributing guide here: https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md
    You’ll want to setup your local dev environment as documented in the developer guide linked in the above document.
    One slight modification is that you should avoid running make test, make examples, and make benchmark, for the time being, as these are rather CPU intensive. Instead, when working on a contribution (which you can find in the issue list under the “good first issue” label: https://github.com/stdlib-js/stdlib/issues), you’ll want to use the environment variable filter (e.g., TESTS_FILTER=.*/incr/wmean/.*).
    Feel free to ping back in this channel if you have further questions!
    Mike Chen
    @mike442144
    Cool! many thanks
    Josh Hopkins
    @joshhopkins
    Hi all, looking to replace simple-statistics but it appears there's still a lot to be desired here. Is there any timeline till stdlib can be directly comparable? Cheers
    Ryan Seal
    @rseal_gitlab
    Is anyone working on the BLAS routines? I'd like to take a crack at providing some of the level 1 routines if no one is working on it
    Athan
    @kgryte
    Hey @rseal_gitlab ! That would be awesome! I suggest picking one of the routines to add, opening a working PR, and adding a vanilla JavaScript, Fortran, and C implementation. We can omit the native add-on and wasm logic for now. 🙂
    Ryan Seal
    @rseal_gitlab
    @kgryte - Okay, I'll take some time to work on that this week, I am thinking of starting with sdot and /or ddot. Should I shoot you a one-to-one message if I have questions, or should I just post them here?
    Athan
    @kgryte
    @rseal_gitlab Just post here! sdot or ddot sounds good to me!
    Ryan Seal
    @rseal_gitlab
    @kgryte Okay, I think I got the basics down. I have implementations in C, Fortran and Javascript for sdot. I have written the benchmarks. Working on the tests now.
    Athan
    @kgryte
    @rseal_gitlab Awesome!
    Philipp Burckhardt
    @Planeshifter
    @rseal_gitlab Seconding Athan, that's awesome! Looking forward to your contribution.
    Ryan Seal
    @rseal_gitlab
    To get the repl working, do I need to manually add the alias for sdot to @stdlib/namespaces/lib/namespace ? Or is there a build process that does that?
    Philipp Burckhardt
    @Planeshifter
    Right now we do not have a build process for that, so yeah, the alias has to be manually added (see b.js file for included base BLAS functions)
    Athan
    @kgryte
    But don’t worry about adding the alias. This is something we can do after merge.
    If you are looking just to test, simply use require in the REPL.
    eg, require( ‘@stdlib/blas/base/sdot’ ).
    Ryan Seal
    @rseal_gitlab
    Okay, cool.
    Ryan Seal
    @rseal_gitlab
    Ran into a snag when trying to lint my repl.txt. When I run the linter (either with the pre-commit hook or manually) it gets stuck. eventually Node carashes with a "Javascript heap out of memeory" error message. I tried this on the saxpy reoutine's repl.txt and the the same thing happened. Any clues to what I did wrong in my dev environement setup would be helpful
    Athan
    @kgryte
    What command are you running to run manually?
    Ryan Seal
    @rseal_gitlab

    I pulled it from the git hooks script, since that is where I ran into it first:

    echo "lib/node_modules/@stdlib/blas/base/saxpy/docs/repl.txt" | DEBUG="lint:repl-txt:*" lib/node_modules/@stdlib/_tools/lint/repl-txt/bin/cli

    Athan
    @kgryte
    Hmm...let me see if I can reproduce on my end.
    Athan
    @kgryte
    @rseal_gitlab Able to reproduce. Investigating...
    Athan
    @kgryte
    @rseal_gitlab Thanks for identifying this bug in the linter! We have pushed fixes, so if you pull down the latest from develop, you should hopefully no longer encounter the heap error.
    Ryan Seal
    @rseal_gitlab
    Thanks @kgryte, just need to go through repl lint errors and I'll submit my pull request
    Athan
    @kgryte
    Awesome!!!
    Ryan Seal
    @rseal_gitlab

    @kgryte and @Planeshifter - Thanks for the help!

    Once the sdot is merged in, what should be next on my list? Should I move on to doing ddot, or working on node addon glue code and wasm glue code?

    Athan
    @kgryte

    @rseal_gitlab No problem! Once merged, we’ll make a couple minor adjustments, and then you can start in on ddot.

    As for addon and wasm glue code, not yet. Unfortunately, I need to spend some time rethinking how that glue code will work and “modernize” the current implementations in the other BLAS routines.

    You want to go ahead and create an RFC for ddot?
    Athan
    @kgryte
    @rseal_gitlab Updated sdot. You should be able to use that package as a template for ddot.
    Ryan Seal
    @rseal_gitlab
    Sounds good!
    Athan
    @kgryte
    Awesome!
    Ryan Seal
    @rseal_gitlab
    Was the current BLAS WASM glue code developed by hand, or did you use emscripten to generate things like the .malloc routines?
    Athan
    @kgryte
    Both.
    The issue is that Emscripten has evolved since we initially prototyped the wasm interfaces and the build processes have undoubtedly changed.
    I need to spend some time refiguring everything out.
    The main work remains the native implementations as done in sdot.
    Athan
    @kgryte
    Re: addons. The issue there is I need to spend some time determining how to support both GYP and N-API, which will take some work.
    Do you have a pressing need for the wasm interfaces or are you asking out of curiosity?
    Ryan Seal
    @rseal_gitlab
    Just curiosity. Been experimenting with WASM a bit to get my head around it and its use cases. Obviously, having the BLAS routines available to WASM will make them more efficient, but no pressing need for me.
    Athan
    @kgryte
    Yeah, for large data arrays in the browser and judicious reuse of allocated memory, WASM implementations will be (and are) more performant.
    Ryan Seal
    @rseal_gitlab
    Small question - for the examples in the documentation you had me use z as the variable to store the result of sdot, but in tests, benchmarks and code examples I used dot. For ddot, would you rather have me use the same variable name z in benchmarks etc or should I use dot to be consistent?
    Athan
    @kgryte
    In this case, just use dot to be consistent.
    I used z as I had yet to come across your use of dot.
    Ryan Seal
    @rseal_gitlab
    :thumbsup:
    Athan
    @kgryte
    @rseal_gitlab If you are interested in working on more BLAS functions, dscal, sscal, dnrm2, and snrm2 would be great additions!
    For the first two, we can follow the reference implementations and not support negative increments (which is what we do in dasum and sasum, also following the reference implementations).
    Ryan Seal
    @rseal_gitlab
    Yeah, that sounds good. I will be away this weekend, but I will take a look on Tuesday
    Athan
    @kgryte
    Awesome! Thanks!