Activity

1. github-actions

   added

   Office HoursIssue announcing office hours and soliciting associated agenda items.Issue announcing office hours and soliciting associated agenda items.

   on Sep 22, 2026
2. DivitJain26 commented on Sep 29, 2026

   

   DivitJain26

   on Sep 29, 2026

   Member

   More actions

   1. Here is my understanding of unsafe integers; could you please confirm.
      i. JavaScript's Number is an IEEE 754 double, so the safe integer range is [-(2^53 - 1), 2^53 - 1].
      ii. Integers outside that range can still be represented (stored exactly) but are unsafe (arithmetic on them may silently lose precision).

      And clarify a few things?

      i. We use constants like these in several places. If they're unsafe, how can we trust results computed from them?

      var TWO_63 = 0x8000000000000000; // 2^63
      var TWO_64 = 0x10000000000000000; // 2^64

      ii. Is there any difference between 0x10000000000000000 and 18446744073709551616 as literals?

   2. What's the difference between "same" and "equal" when comparing values?
3. ujjwalv01 commented on Sep 29, 2026

   

   ujjwalv01

   on Sep 29, 2026

   Last edited by ujjwalv01

   Member

   More actions

   Follow-up from last to last week's office hours (multi-output audit for lapack/base):

   Routines that currently pack multiple scalar outputs into a single out array, i.e. candidates for refactoring to separate single-element output arrays :

   • dlassq (merged): out = [scale, sumsq]
   • dlarfg #7109: out = [alpha, tau]
   • dlartgp #9608: out = [c, s, r]
   • dlae2 #2824: out = [rt1, rt2]
   • dlaev2 #2828: out = [rt1, rt2], ev = [cs1, sn1]
   • dlas2 #2833: out = [ssmin, ssmax]
   • dlasv2 #2819: out = [ssmin, ssmax, snr, csr, snl, csl]

   Before refactoring dlassq, could you take a second look at dlaln2 (#15222) to confirm the separate-array form (scale, xnorm, info) is the way we want to go?
   Happy to take the dlassq refactor and help update the open PRs if that's the direction we go with.

   Separately, I would like some guidance on dztest (#15318), the first C implementation for the ztest family in stats/base/ndarray. Unlike the other stats/base/ndarray add-ons, it writes to a results object instead of returning a scalar, and stdlib_ndarray_napi_addon_arguments cannot process the zero-dimensional output ndarray because it has a struct data type. In the PR, the add-on receives the results object as a DataView (the same mechanism as the merged stats/strided/dztest add-on) and wraps it in a zero-dimensional ndarray before calling the C API, so that stdlib_stats_dztest( arrays ) mirrors the JavaScript contract. Is that the intended approach, or should addon_arguments grow support for struct data types first? Whatever we decide will also apply to sztest, dztest2, and sztest2.
4. gunjjoshi commented on Sep 29, 2026

   

   gunjjoshi

   on Sep 29, 2026

   Member

   More actions

   In order to implement the top-level package for forward transforms, i.e., fft/rfftf, we will need to convert the half-complex format returned by our strided APIs to complex formats. The question that I had was:

   Would it be fine to add fft/base/hc2c, which does this conversion for us? I was thinking of the following signature:

   /**
   * Converts a real-valued array in FFTPACK half-complex format to a complex-valued array.
   *
   * @param {NonNegativeInteger} N - length of the original real sequence
   * @param {Collection} hc - input array in FFTPACK half-complex format
   * @param {integer} strideHc - stride length for `hc`
   * @param {NonNegativeInteger} offsetHc - starting index for `hc`
   * @param {(Complex128Array|Complex64Array)} out - output complex array
   * @param {integer} strideOut - stride length for `out` (in complex elements)
   * @param {NonNegativeInteger} offsetOut - starting index for `out` (in complex elements)
   * @returns {(Complex128Array|Complex64Array)} output complex array
   */
   function hc2c( N, hc, strideHc, offsetHc, out, strideOut, offsetOut ) {
   }

   I am explicitly mentioning "FFTPACK half-complex" here instead of just "half-complex" format, since the half-complex format of fftpack differs from that of FFTW, for example. FFTPACK's half-complex format is:

   Even N:  [ DC, Re(1), Im(1), Re(2), Im(2), ..., Re(N/2-1), Im(N/2-1), Nyquist ]
   Odd N:   [ DC, Re(1), Im(1), Re(2), Im(2), ..., Re((N-1)/2), Im((N-1)/2) ]

   (nyquist will only be present in case of even N).

   I referred this from https://www.netlib.org/fftpack/doc.

   Internally, we could use @stdlib/strided/base/reinterpret-complex to reinterpret the complex output array (out) to real array. Would this be the correct way?
5. manit2004 commented on Sep 29, 2026

   

   manit2004

   on Sep 29, 2026

   Last edited by manit2004

   More actions

   • Request to review PR sgemmtr
   • sort/sorthp/circshift don't validate ndarray sort-order/shift arg shape, should throw but don't stdlib#15658 Request to review this issue and related PR fix: validate broadcast-compatibility of ndarray sort/shift argument stdlib#15660
6. impawstarlight commented on Sep 29, 2026

   

   impawstarlight

   on Sep 29, 2026

   Member

   More actions

   I noticed that we had a custom implementation for math/base/special/abs in the past instead of just wrapping Math.abs. Why was that?
7. kgryte commented on Sep 29, 2026

   

   kgryte

   on Sep 29, 2026

   Member

   More actions

   @impawstarlight Ref: https://github.com/stdlib-js/stdlib/blob/develop/lib/node_modules/%40stdlib/repl/lib/drain.js

   👍React with 👍1Reacted by Abdul Kaium
8. batpigandme commented on Sep 29, 2026

   

   batpigandme

   on Sep 29, 2026

   Member

   More actions

   AI-Generated Summary

   Caution

   These notes are likely imperfect, especially when it comes to spelling/function/package names

   Meeting Purpose

   Reviewing technical questions, PRs, and project blockers.

   Key Takeaways

   • ZTest Family Blocked: The ZTest family of functions is blocked, as they require custom dtype support in ndarray that is not yet implemented.
   • FFT Strategy Defined: The default fft implementation will use the pure-JS fft-pack library. fftw will be a native-only wrapper, used as an optional system-level dependency or fallback, due to its GPL license.
   • Local Test Failures: Local test failures from compiler optimizations (e.g., fp-contract) will be addressed by modifying make test to recompile native add-ons with these flags disabled, ensuring parity with CI.
   • AI-Generated PRs: AI-generated PRs require critical review. Contributors must provide a sound mathematical rationale to justify changes, especially when diverging from established upstream implementations like Boost.

   Topics

   Unsafe Integers & Floating-Point Comparisons

   • Unsafe Integers: The definition of an "unsafe integer" is about round-tripping (number → N64 → number), not arithmetic precision.
     • Values outside the safe range (2^53 - 1) will lose precision when converted to a JavaScript number.
     • However, if the resulting number can be represented exactly, it will round-trip correctly.
     • The N64 constructor's note about from or BigInt is a warning about this initial precision loss, not a limitation of N64 itself.
   • same vs. equal:
     • is same methods use the ECMAScript SameValue algorithm for floating-point comparisons.
     • This algorithm treats NaN as equal to NaN and positive/negative zero as different values.
     • This is crucial for correctly comparing arrays that may contain these special floating-point values.
     • is equal methods are used for integers, where NaN and signed zeros do not exist.

   Multi-Output LAPACK Refactor

   • Goal: Refactor LAPACK routines that pack multiple scalar outputs into a single array to return a structured object instead.
   • Plan:
     1. Merge DLA-SQ PR: Ujjwal will open a refactor PR for the already-merged DLA-SQ routine.
     2. Update Open PRs: After DLA-SQ is merged, Ujjwal will get edit rights to update the six open PRs with the new multi-output structure.
     3. Cleanup: This is an opportunity to clean up older, potentially stale PRs (e.g., from Pranoff).

   ZTest Family Implementation Blocker

   • Problem: The ZTest family of functions is blocked because their output is a custom struct dtype (e.g., float64 results).
   • Root Cause: The ndarray package lacks support for custom dtype objects, which prevents serialization and other core operations.
   • Status: All ZTest implementations are paused. Ujjwal will add a note to the issue to inform future contributors.

   FFT Implementation Strategy

   • Half-Complex to Complex (HC2C) Conversion:
     • The HC2C conversion utility is specific to the fft-pack library's half-complex format.
     • Decision: The utility will live in the fft-pack namespace (e.g., fft-pack/base/hc2c) to avoid confusion with other formats (e.g., FFTW).
   • FFT Library Strategy:
     • fft-pack: The default, pure-JS implementation. Its permissive license allows direct inclusion.
     • fftw: Will be a native-only wrapper around the external fftw library.
       • Rationale: The GPL license prevents direct inclusion of fftw code.
       • Usage: Can be an optional system-level dependency or an explicit, direct-namespace call.
   • Top-Level API (fft, rfft):
     • Default: A copying API that returns a new array.
     • Rationale: The half-complex format requires a different output array type (complex) than the input (real), making in-place mutation impossible.
     • assign API: Will write the result to a user-provided complex array instead of allocating a new one.

   Local Test Failures & Compiler Optimizations

   • Problem: Local test failures occur due to compiler optimizations (e.g., fp-contract) enabled by default for native add-ons.
   • Impact: This causes results to differ from CI (which runs on Linux with these flags disabled), creating confusion for developers.
   • Proposed Solution: Modify make test to recompile native add-ons with optimization flags disabled.
     • Benefit: Ensures local tests match CI results.
     • Challenge: Requires R&D to handle packages without native add-ons gracefully (e.g., by swallowing a non-zero exit code from the recompile step).

   AI-Generated PRs & Code Quality

   • Context: Recent PRs, likely AI-generated, propose changes to special functions and statistical distributions.
   • Review Policy:
     • Critical Review: Do not dismiss AI-generated PRs outright, as they can identify legitimate bugs.
     • Demand Rationale: Require contributors to provide a sound mathematical justification for their changes.
     • Upstream Alignment: Prioritize alignment with established implementations (e.g., Boost) to minimize maintenance friction.
     • Triage: Karan will help triage these PRs, pushing back on contributors who cannot explain their proposals.

   REPL Display for Custom Types

   • Problem: Custom types like Int64, UInt64, and Complex are printed as empty objects in the REPL.
   • Solution: Add special handling to source/repl/lib/drain.js.
     • Implementation: Use isN64, isUN64, and isComplex checks to format output.
     • Format: ConstructorName [value] (e.g., Int64 [123]) or Complex64 [1+2i].
     • Rationale: This file already contains custom logic for NDArray display.

   Full transcript

   Full office hours transcript

   ❤️React with ❤️1Reacted by Abdul Kaium