You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have questions about stdlib? Need help fixing a bug, figuring out what to do next, or just looking for feedback? Join our weekly office hours to connect with project maintainers, stay updated on the latest project news, and chat with other community members. This is a great opportunity to ask questions, share ideas, and engage directly with the stdlib team.
There had been a discussion on Zulip regarding sorted arrays generation in C benchmarks for sorted-input packages #10415. This issue was open and I guess there are current open PRs that are waiting for this.
Regarding the Array API compliance for ndarrays' proposal, is it expected to state the implementation details for every package in the issue and the weekly plan? Or is it okay to have external documents (google docs or spreadsheet) that has almost all the details (including the weekly plans)?
Is there an ability to have a maintainer (Athan or Phillip) take a look at a draft proposal? or all proposals should be posted on the GSoC's repository issue tracker once?
I've implemented an initial prototype for number/uint64/ctor in stdlib-js/stdlib#10908. Need some quick feedback on the design. There are various questions scattered around the source code with TODO tags but here is a list of the important ones:
Which parameter types should we actually support? Anything to add or remove from these ones?
number: When between 0 and MAX_SAFE_INTEGER, otherwise error
string: Arbitrary length integer in either decimal, binary, octal, or hex format. Keeps the least significant 64 bits. Uses a manual chunked parsing for decimal integers when BigInt is not used.
Array<number>: Double word ([high, low]) representation. Checks the array size (must equal 2) and the number values (between 0 and MAX_UINT32) and throws error if not satisfied.
Uint32Array: Similar to array.
BigInt: Truncates to 64-bit. Question on negative tho.
Should we support negative parameters? This can be useful for initializing to MAX_UINT64 value by providing -1 but ensuring consistent result across all the parameter branches would be challenging.
How should we store the uint64 value internally? Current implementation uses the value property but its type is dependent on whether we're using BigInt or not (uses a 2-len Uint32Array otherwise). Should we alternatively do 3 seperate props such as this.high, this.low, and this.big? Then the big property will be set only when using BigInt and the other two will be always set.
What should we put in the JSON representation? String seems to be best for readability but storing [high, low] is better for performance.
How can we keep the internal representation a secret or make it private? I guess it's not possible to make it truly private given the structure of this package and the fact that it will need to support the arithmetic ops packages that are separate from the constructor. Should we just leave it out of the docs then?
The constructor takes a second parameter useHighLow that when set to true it forces the internal representation to use double word even if BigInt is available. It was needed for testing all the branches and also for benchmarking the two different ways. But the name feels kinda awkward as if leaking implementation details. Can we find a better name for this parameter?
The toString implementation got way too involved because of supporting all radix (2-36) like number and BigInt. The algorithm I developed is kinda hacky which exploits the 53 bit integer precision of Javascript to go around having to implement the full 64-bit division routine and it needs a deeper look I guess.
And a big concern is, if we're to use the uint64 in PRNG packages that usually uses Uint32Array or similar, how are we gonna take advantage of the BigInt arithmetic? Feels like there would be some back and forth conversions which might be counter-productive for performance.
If we're doing a PR review, then kindly look into: stdlib-js/stdlib#10279
I've written all the test cases that were present in the boost reference and have cross verified the implementation multiple times.
I think it's ready to get merged!
I noticed that some BLAS routines don't have a base.js file and their core implementation is done separately in ndarray.js and <routine>.js. Is this still pending work or it should be left as it is?
Most of the namespaces have the functions and then there is a base subnamespace inside it. I was performing an audit of missing functions to be added to the gsheets.
I am getting really confused with the array namespace as to what should be added and what cannot be. Could you explain this structure and some pointers? Do we need to add all the base functions? or we add only the ones outside the base namespace.
I have opened a draft Proposal. Could you review and suggest improvements?
In jStat, we have APIs working on matrix and nested array operations, for which stdlib has only selective replacements. There are corresponding implementations in stdlib, but they lie under the ndarray namespace. Due to this architectural mismatch, they may not be directly usable. I wanted to ask -for such APIs, can you suggest any references for implementation that would work within jStat's current nested array architecture? I have found MDN to be one useful resource, but I wanted to check if there are any stdlib specific references or prior art that would be more appropriate to follow.
Hi, just wanted confirmation on the structure of the optimization algorithms package, for which I opened a PR: stdlib-js/stdlib#10145. Are there any file-level changes needed? for example, adding any *.js file or removing the existing ones.
Activity
LoayAhmed304 commentedon Mar 16, 2026
impawstarlight commentedon Mar 16, 2026
I've implemented an initial prototype for
number/uint64/ctorin stdlib-js/stdlib#10908. Need some quick feedback on the design. There are various questions scattered around the source code withTODOtags but here is a list of the important ones:number: When between0andMAX_SAFE_INTEGER, otherwise errorstring: Arbitrary length integer in either decimal, binary, octal, or hex format. Keeps the least significant 64 bits. Uses a manual chunked parsing for decimal integers when BigInt is not used.Array<number>: Double word ([high, low]) representation. Checks the array size (must equal 2) and the number values (between0andMAX_UINT32)and throws error if not satisfied.Uint32Array: Similar to array.BigInt: Truncates to 64-bit. Question on negative tho.MAX_UINT64value by providing-1but ensuring consistent result across all the parameter branches would be challenging.uint64value internally? Current implementation uses thevalueproperty but its type is dependent on whether we're usingBigIntor not (uses a 2-lenUint32Arrayotherwise). Should we alternatively do 3 seperate props such asthis.high,this.low, andthis.big? Then thebigproperty will be set only when using BigInt and the other two will be always set.useHighLowthat when set totrueit forces the internal representation to use double word even ifBigIntis available. It was needed for testing all the branches and also for benchmarking the two different ways. But the name feels kinda awkward as if leaking implementation details. Can we find a better name for this parameter?toStringimplementation got way too involved because of supporting all radix (2-36) likenumberandBigInt. The algorithm I developed is kinda hacky which exploits the 53 bit integer precision of Javascript to go around having to implement the full 64-bit division routine and it needs a deeper look I guess.uint64in PRNG packages that usually uses Uint32Array or similar, how are we gonna take advantage of the BigInt arithmetic? Feels like there would be some back and forth conversions which might be counter-productive for performance.nirmaljb commentedon Mar 17, 2026
If we're doing a PR review, then kindly look into: stdlib-js/stdlib#10279
I've written all the test cases that were present in the boost reference and have cross verified the implementation multiple times.
I think it's ready to get merged!
navyansh007 commentedon Mar 17, 2026
If we are doing PR reviews, I would highly appreciate reviews on these PRs:
prajjwalbajpai commentedon Mar 17, 2026
I noticed that some BLAS routines don't have a
base.jsfile and their core implementation is done separately inndarray.jsand<routine>.js. Is this still pending work or it should be left as it is?An example of this is the
dsymvroutine.officiallyanee commentedon Mar 17, 2026
If Karan Anand joins , would really appreciate getting more insights and possibly a review on this issue related to sincosf.
Also if time permits a final look at this PR, it should be close to merging 🤞.
Thank you!
GlyphicGuy commentedon Mar 17, 2026
Hey!
Most of the namespaces have the functions and then there is a
basesubnamespace inside it. I was performing an audit of missing functions to be added to thegsheets.I am getting really confused with the array namespace as to what should be added and what cannot be. Could you explain this structure and some pointers? Do we need to add all the base functions? or we add only the ones outside the base namespace.
Draft Checklist
shubham220420 commentedon Mar 17, 2026
I had a little query :-
jStat, we haveAPIsworking onmatrix and nested arrayoperations, for which stdlib has only selective replacements. There are corresponding implementations in stdlib, but they lie under thendarraynamespace. Due to this architectural mismatch, they may not be directly usable. I wanted to ask -for such APIs, can you suggest any references for implementation that would work within jStat's current nested array architecture? I have foundMDNto be one useful resource, but I wanted to check if there are any stdlib specific references or prior art that would be more appropriate to follow.Aniket-SS commentedon Mar 17, 2026
I would like to have a look into the question regarding the implemetation of
ndarray/base/copywhich was asked in this issue.manit2004 commentedon Mar 17, 2026
Do we need to publish our stdlib showcase page? Or is github repo enough?
udaykakade25 commentedon Mar 17, 2026
Regarding GSoC Proposal: "Add Support for Float16 and Complex32"
array/float16Proposal is almost ready! Would drop Tomorrow
sagar7162 commentedon Mar 17, 2026
Hi, just wanted confirmation on the structure of the optimization algorithms package, for which I opened a PR: stdlib-js/stdlib#10145. Are there any file-level changes needed? for example, adding any *.js file or removing the existing ones.
kgryte commentedon Mar 18, 2026
Thanks everyone!