Office Hours (2026-08-18)

[github-actions]

🌟 Join Us for Weekly Office Hours! 🌟

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.

Everyone is welcome—drop in and say hello!

Time

UTC Tue 18-Aug-2026 16:30 (04:30 PM):

Timezone	Date/Time
US / Pacific	Tue 18-Aug-2026 09:30 (09:30 AM)
US / Mountain	Tue 18-Aug-2026 10:30 (10:30 AM)
US / Central	Tue 18-Aug-2026 11:30 (11:30 AM)
US / Eastern	Tue 18-Aug-2026 12:30 (12:30 PM)
EU / Western	Tue 18-Aug-2026 17:30 (05:30 PM)
EU / Central	Tue 18-Aug-2026 18:30 (06:30 PM)
EU / Eastern	Tue 18-Aug-2026 19:30 (07:30 PM)
Moscow	Tue 18-Aug-2026 19:30 (07:30 PM)
Chennai	Tue 18-Aug-2026 22:00 (10:00 PM)
Hangzhou	Wed 19-Aug-2026 00:30 (12:30 AM)
Tokyo	Wed 19-Aug-2026 01:30 (01:30 AM)
Sydney	Wed 19-Aug-2026 02:30 (02:30 AM)

or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=stdlib%20Office+Hours+2026-08-18&iso=20260818T1630

Links

• Public calendar: https://calendar.google.com/calendar/embed?src=a72677fe2820c833714b8b9a2aa87393f742bcaf0d0f6c9499eee6661795eae0%40group.calendar.google.com

Joining the meeting

• Google Meet link: https://meet.google.com/yct-chmu-owx

Agenda

• Have specific things to discuss? Please comment in the issue thread below to add specific items to the agenda.

[DivitJain26]

• Guidance on feat: add strided/base/reinterpret-uint64 stdlib#14219

Should the byte order of the returned Uint32Array view be:

• Host-OS dependent: view[0] is whichever word (high or low) comes first in memory on the current platform (little-endian vs big-endian),
  or
• Definitive: view[0] is always documented as HIGH (or always LOW)?

This affects how examples in the documentation should be written.

var Uint64Array = require( '@stdlib/array/uint64' );
var reinterpret = require( './../lib' );

// Define a 64-bit unsigned integer array:
var x = new Uint64Array( [ 1, 2, 3, 4, 5, 6, 7, 8 ] );
// returns <Uint64Array>

// Reinterpret as a `uint32` array:
var view = reinterpret( x, 0 );
// returns <Uint32Array>

// Set view elements:
view[ 0 ] = 0;
view[ 1 ] = 0;

// Get the first element of the 64-bit unsigned integer array:
var u = x.get( 0 );
// returns <Uint64>[ 0n ]

console.log( u.toString() );

This particular example is endianness-safe; setting both words to 0 zeroes the element no matter which index is high vs. low. But it doesn't actually demonstrate the indexing convention, and any example that sets a specific non-zero value (e.g., "set only the high word") would need to know which index means what.

[0PrashantYadav0]

Discussion on

• @stdlib/blas/ext/base/nannsum/results/struct-factory - #14368 : dstruct schema: { sum, count }
• @stdlib/blas/ext/base/nannsum/results/factory - #14368 : Results constructor factory (float64 | float32)
• @stdlib/blas/ext/base/nannsum/results/float32 - #14348 : Float32Results JS constructor

Initial inspiration :

• ml/base/kmeans/results/struct-factory - #12356
• @stdlib/stats/strided/dztest — stdlib_stats_ztest_one_sample_float64_results
• @stdlib/stats/strided/dztest2 — stdlib_stats_ztest_two_sample_float64_results
• @stdlib/stats/strided/sztest — stdlib_stats_ztest_one_sample_float32_results
• @stdlib/stats/strided/sztest2 — stdlib_stats_ztest_two_sample_float32_results

Project Idea:

nannsum/results/
├── struct-factory/   - Layer 1: raw binary struct schema (dtype-parameterised)
├── factory/          - Layer 2: user-facing constructor factory (validates dtype, adds API)
├── float32/          - Layer 3a: pre-baked float32 constructor (shortcut for factory('float32'))
├── float64/          - Layer 3b: pre-baked float64 constructor (shortcut for factory('float64'))
├── to-json/          - Utility: serialize a results object to a plain JSON object
└── to-string/        - Utility: serialize a results object to a human-readable string

Example for struct-factory:

var structFactory = require( '@stdlib/blas/ext/base/nannsum/results/struct-factory' );
var BigInt = require( '@stdlib/bigint/ctor' );

var Struct = structFactory( 'float64' );
var results = new Struct({
    'sum': 11.7586,
    'count': BigInt( 5 )
});

var str = results.toString({
    'format': 'linear'
});
console.log( str );

Example for factory:

var BigInt = require( '@stdlib/bigint/ctor' );
var resultsFactory = require( '@stdlib/blas/ext/base/nannsum/results/factory' );

var Results = resultsFactory( 'float64' );
var results = new Results({
    'sum': 11.7586,
    'count': BigInt( 5 )
});

var str = results.toString();
console.log( str );

Example for float32:

var BigInt = require( '@stdlib/bigint/ctor' );
var f32 = require( '@stdlib/number/float64/base/to-float32' );
var Results = require( '@stdlib/blas/ext/base/nannsum/results/float32' );

var results = new Results({
    'sum': f32( 11.7586 ),
    'count': BigInt( 5 )
});

var str = results.toString();
console.log( str );

[kgryte]

var out = new Float64Array( 1 );
var count = new Int64Array( 1 );

dnannsum( N, x, strideX, offsetX, out, offsetOut, count, offsetCount );

[kgryte]

var Uint64Array = require( '@stdlib/array/uint64' );
var reinterpret = require( './../lib' );

// Define a 64-bit unsigned integer array:
var x = new Uint64Array( [ 1, 2, 3, 4, 5, 6, 7, 8 ] );
// returns <Uint64Array>

// Reinterpret as a `uint32` array:
var view = reinterpret( x, 0 );
// returns <Uint32Array>

// Set view elements:
view[ 0 ] = 0;
view[ 1 ] = 0;

// Get the first element of the 64-bit unsigned integer array:
var u = x.get( 0 );
// e.g., returns <Uint64>[ 0n ]

[batpigandme]

AI-Generated Summary

Caution

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

Meeting Purpose

To align on technical direction and unblock contributors.

Key Takeaways

• NAN APIs will use separate out and count arrays, not structs, for better performance. This is blocked by the in-progress Int64Array PR and Node.js binding updates.
• New contributors should focus on C ND-array wrappers for packages like blast-extended-base and stats, as this work is unblocked.
• Athan will prioritize reviewing pending Level 3 BLAS PRs (e.g., strided-gemm-tr) after GSOC ends this week.
• Follow-up PRs are the standard process for applying new best practices (e.g., benchmark structure, Int64Array views) to previously merged code.

Topics

NAN API Design

• Problem: stats-strided APIs need to return heterogeneous types (e.g., float64 sum, int64 count).
• Rejected Solution: Structs
  1. Rationale: Creates non-contiguous data, hindering performance for subsequent operations.
  2. Precedent: Structs are reserved for complex results objects (e.g., Z-test) that match user expectations.
• Chosen Solution: Separate Output Arrays
  1. API: d_nan_sum(..., out, offset_out, count, offset_count)
  2. Rationale: Mimics C APIs and provides contiguous arrays for efficient downstream processing.
• Blockers:
  1. Int64Array Support: Requires merging the in-progress PR by Nicole.
  2. Node.js Bindings: Must be updated to parse both Int32Array and Int64Array arguments.
  3. CBLAS int Macro: The JS runtime needs a way to link to the C CBLAS_INT macro.
• Status: All NAN-related refactoring is on hold pending these blockers.

BLAS & SIMD Performance

• Pending Level 3 BLAS PRs:
  • Issue: Many Level 3 BLAS routines (e.g., strided-gemm-tr) are not on NPM.
  • Cause: Reviewer bandwidth.
  • Action: Athan will prioritize reviews after GSOC.
• New Routine: gemm-tr
  • Action: Manit will implement gemm-tr, using the existing gemm module as a reference.
• SIMD/WebAssembly Optimization:
  • Status: Exploratory.
  • Challenge: Requires a major architectural shift to C++ (e.g., Google Highway) and a new build process.
  • Timeline: A clearer path is expected in the next few months.

Contributor Workflow & Best Practices

• Unblocked Work: C ND-array wrappers for packages like blast-extended-base and stats.
  • Action: Prashant will create a tracking issue to guide new contributors.
• Follow-up PRs: The standard process for applying new best practices to previously merged code.
  • Example 1: Add Int64Array views to blast package (Siddharam).
  • Example 2: Align benchmark.native.js with benchmark.js (Ujjwal).
• Masked Array Implementations:
  • Action: Ujjwal will create a demo PR for a masked array routine (e.g., dmask_mean).
  • Rationale: This establishes a pattern for the full family of APIs (e.g., dmask_mean, dnanmask_mean).
• NaN Constant in C:
  • Guidance: Use the standard library macro instead of 0.0 / 0.0.
  • Rationale: Ensures consistency and avoids potential issues with signaling vs. quiet NaNs.
  • Reference: Issue #11743.

Full transcript

Full office hours transcript