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 Aug 18, 2026
2. manit2004 commented on Aug 25, 2026

   

   manit2004

   on Aug 25, 2026

   More actions

   • Review on feat(blas/base/sgemmtr): adding lib, test, docs, examples, benchmark  stdlib#14415
   • Discuss possibility of string array on webgpu (wgstrings)
3. teddygood commented on Aug 25, 2026

   

   teddygood

   on Aug 25, 2026

   More actions

   Following Office Hours #150 and the Highway/DAXPY draft PR #13068, I wanted to narrow the question before suggesting any broader SIMD direction. I have not changed upstream source or opened a PR. The goal was to identify what an actual package prototype should test.

   I began with DAXPY because it was already being explored in the Highway draft and offered a simple C ABI baseline. To see whether its result generalized, I then chose representative workloads for different constraints. DDOT covered reduction ordering. DABS and the sampled generated ADD signatures covered callback and generation boundaries. DCBRT covered vector math and numerical accuracy. DSUMPW, observed through DMEANPW, covered a reduction with independent accumulators and a fixed combination tree. These were probes for different questions rather than equal rollout candidates, so I compared the methods relevant to each constraint.

   Those probes produced different outcomes. Optimized plain C was already strong for DAXPY, and DDOT exposed the numerical consequences of changing the reduction order. In the scratch comparisons, callback removal explained most gains for DABS and the sampled generated ADD signatures. DCBRT separated bounded error vector math from an exact current result path dependent on link time optimization and symbol visibility. DSUMPW provided the clearest evidence of explicit SIMD beyond specialized C. Each base reduction uses eight logical accumulators, so I could pack their updates for contiguous inputs while preserving their addition order and the final combination tree. Under that constraint, direct compiler intrinsics, SIMDe, xsimd, and Highway matched the current implementation on the tested corpus and showed repeatable gains at large contiguous N on one x86 host and in direct WebAssembly runs in headless Chrome and Firefox. I therefore prioritized DSUMPW for the first package prototype.

   Would it be useful for me to implement and test a prototype in the actual DSUMPW package using stdlib’s existing build, tests, and benchmarks? I would keep the C ABI, scalar fallback, and current reduction order unchanged. The goal would be to see whether the performance gains remain after integration and justify the added complexity and size before discussing a backend or broader rollout.

   P.S. I’m sorry I will not be able to attend today’s Office Hours because I was not feeling well. I would appreciate any feedback you can leave either in the Zulip thread or here, and I’ll make sure to follow up on it.
4. ujjwalv01 commented on Aug 25, 2026

   

   ujjwalv01

   on Aug 25, 2026

   Member

   More actions

   To implement native C bindings for stats/base/ndarray/ packages like dstdev and dvariance, I noticed an architectural pattern that differs from the single-array packages I've recently worked on, and I'd love to get some guidance.

   For these packages, the user provides a data array and a zero-dimensional ndarray for the correction (degrees of freedom adjustment).

   In the JavaScript wrapper for ndarray/dstdev, it handles the translation to a primitive number for the strided layer like this:

   // stats/base/ndarray/dstdev/lib/main.js
   function dstdev( arrays ) {
   	var correction;
   	var x = arrays[ 0 ];
       
   	// Extracts the scalar from the 0-dim ndarray
   	correction = ndarraylike2scalar( arrays[ 1 ] ); 
   
   	// Passes it to strided as a primitive number
   	return strided( numelDimension( x, 0 ), correction, getData( x ), ... ); 
   }

   Conversely, the underlying strided package's C addon expects that primitive number directly:

   // stats/strided/dstdev/src/addon.c
   static napi_value addon( napi_env env, napi_callback_info info ) {
   	// ...
   	// Extracts the correction as a primitive double
   	STDLIB_NAPI_ARGV_DOUBLE( env, correction, argv, 1 ); 
   	// ...
   }

   My question is: When we write addon.c for these ndarray packages, we will be receiving the arrays array containing the 0-dim ndarray object, so we can't simply use STDLIB_NAPI_ARGV_DOUBLE like the strided package did.

   What is the recommended approach for handling this in C? Once we extract the zero-dimensional ndarray using stdlib_ndarray_napi_addon_arguments, how should we properly extract its underlying scalar double value so that we can pass it down to the strided C function?
5. gunjjoshi commented on Aug 25, 2026

   

   gunjjoshi

   on Aug 25, 2026

   Member

   More actions

   Discussion around stdlib-js/stdlib#14591 (review), and how we want to plan implementing packages further, in the FFT namespace.
6. 0PrashantYadav0 commented on Aug 25, 2026

   

   0PrashantYadav0

   on Aug 25, 2026

   Member

   More actions

   float stdlib_stats_svariance( const struct ndarray *arrays[] ) {
   	const struct ndarray *x = arrays[ 0 ];
   	float correction;
   	stdlib_ndarray_get_float32( arrays[ 1 ], NULL, &correction );
   	return API_SUFFIX( stdlib_strided_svariance_ndarray )( stdlib_ndarray_dimension( x, 0 ), correction, (const float *)stdlib_ndarray_data( x ), stdlib_ndarray_stride_elements( x, 0 ), stdlib_ndarray_offset_elements( x ) );
   }

   Is this looks good ?
7. batpigandme commented on Aug 25, 2026

   

   batpigandme

   on Aug 25, 2026

   Member

   More actions

   AI-Generated Summary

   Caution

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

   Meeting Purpose

   Discussing technical challenges and development strategy for stdlib.

   Key Takeaways

   • String Arrays: Prioritize a CPU-based implementation, studying the NumPy RFC for its 3 allocation strategies. WebGPU is premature due to the async execution model, CPU-GPU transfer overhead, and the need for a unified device management strategy.
   • ndarray C Implementations: Use stdlib.ndarray.getFloat64 to extract scalar values from 0D arrays, avoiding manual buffer access. A single, generalized tracking issue will replace specific ones to manage the moving target of new APIs.
   • FFT Workspace: The float32 workspace for decompose is acceptable for practical sequence lengths (~50k). A performance benchmark will compare float32 vs. int32 views for very large sequences (>16.7M) to assess the risk of rounding errors.
   • PCG32 Fixtures: Generate fixtures using a small, custom C wrapper for the original PCG32 implementation. Standardize test messages to "returns expected value" to enable future automated, verbose error reporting.

   Topics

   ndarray C Implementations & Tracking

   • Problem: Extracting scalar values from 0D ndarray arguments for C functions.
   • Solution: Use the dedicated stdlib.ndarray.getFloat64 API to extract the value directly, avoiding manual buffer manipulation.
   • Problem: Duplicate PRs for ndarray C implementations due to a lack of a central tracking issue.
   • Solution: Create one generalized tracking issue instead of specific ones, as the set of APIs is a moving target.
     • Scope: Any blas-extended-base/ndarray API with a JavaScript wrapper but no C implementation.
     • Process: Comment on the issue to claim a task and use a standardized PR title (e.g., feature: add C implementation to <package>) to prevent conflicts.

   String Arrays on WebGPU

   • Proposal: Implement GPU-accelerated string arrays via WebGPU, inspired by NVIDIA's cuDF.

   • Decision: Defer WebGPU. A CPU-based implementation is the necessary first step to define the core API and understand the JavaScript-C/WASM bridge.

   • Rationale for Deferring WebGPU:

     • Execution Model: WebGPU is async, requiring a computational graph (like PyTorch/Jax) to queue operations and manage state.
     • Overhead: CPU-GPU data transfer is a bottleneck for smaller datasets.
     • Device Management: stdlib lacks a unified strategy for device types (CPU, WASM, GPU), which would be an "infectious" change across the entire API.
     • Data Type Support: WebGPU has limited native data type support (e.g., no int64), requiring emulation.

     FFT Workspace Data Type

   • Context: The decompose function in the FFT implementation uses a float32 workspace for integer factors.

   • Risk: For very large sequence lengths (>16.7M), float32 lacks the precision to represent all integers, potentially causing rounding errors. The original rFFT library uses an int32 view of the buffer to avoid this.

   • Decision: Proceed with float32 for now.

     • Rationale: Practical FFT sequence lengths are much smaller (~50k), making the risk negligible.
     • Future Path: If needed, a simple refactor can create an int32 view of the buffer for decompose without reallocating memory.

     PCG32 Fixture Generation

   • Problem: Generating test fixtures for PCG32 requires using the original C library, which has multiple versions and a large codebase.

   • Solution: Create a small, custom C wrapper for the original PCG32 implementation to generate the required JSON fixtures.

     • Process: Generate the JSON file independently and commit it to the repository.

   • Standardization:

     • Test Messages: Standardize all test messages to "returns expected value." This enables future automated, verbose error reporting.
     • Seed Value: Use a consistent seed (e.g., 12345) across JavaScript and C examples to simplify divergence detection.
     • TypeScript: Add the missing normalized function declaration to the MersenneTwister TypeScript file**.**

     ESLint Configuration Issue

   • Problem: Recent ESLint configuration changes are causing new, unexpected lint errors (e.g., in READMEs), breaking CI.

   • Action: Philipp will lint a large portion of the project with the new config to identify and fix the problematic rules.

   Full transcript

   Full office hours transcript
8. batpigandme

   closed this as completedon Sep 2, 2026