Office Hours (2026-03-24)

[kgryte]

🌟 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 24-Mar-2026 16:30 (04:30 PM):

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

or in your local time:

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

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.

[LoayAhmed304]

Hi all👋!

• I noticed that there have been fewer PR merges over the past few weeks, likely due to maintainers’ availability. I was wondering how open PRs will be taken into account for GSoC applications and proposals?
• Regarding surveying other libraries for implementation details, I've found it hard to find the source code for specific functions in Julia and MATLAB, MATLAB requires to have it installed and I don't have a license for such, and even Octave makes it hard to find implementation details for their "built-in functions". The only convenient survey is Numpy's over their official documentation website. Do you have guidance as of how to check Julia and MATLAB source code? And is it okay if I contacted them over their communication channel for guidance? I believe Julia participates in GSoC. Otherwise I may only survey their approach, assumptions, etc.
• You mentioned to me that we aren't doing an exact 1:1 mapping, for example the copy argument in astype won't exist exactly as intended since we'll be using dedicated assign methods, can I have more elaboration on that? Also for such cases in the future, is there a pattern that I should be aware of, where we won't be mapping exact arguments? Or is this something we'll discuss during the RFC making of such functions then instead?
• I had couple questions when I was studying your clean-up commit on ndarray/base/full.
  • I noticed you omitted the compiler error throwing on invalid value argument, after re-checking fill I noticed that it is also omitted, may I know the reason behind that? Is it because the fill value may be any in the future? After support string etc..? Change.
  • I noticed the documentation has 2 versions, REPL and lib/main.js use the Returns an ndarray... while package.json and lib/index.js use the word Create an ndarray..., while README has both. May I know the convention behind this?
  • Finally, regarding the package notes, I know that README should have all the notes needed in its notes section, but I was wondering what kind of notes should be added to REPL and test.d.ts and what not? Or does this have no exact convention and is implementation-dependent?
• Regarding the eye function, should the tests include a test for each dtype? Currently I have for accessors and float64 only, covering negative and positive k and square and rectangular rows and cols, with different orders combination.
• (Implementation detail question) Regarding the eye function, will it be simple looping on the buffer and (accessor) assigning identities on the kth diagonal, where strides and offset will be mathematically computed beforehand? Or is there another approach? (This is the approach I took here).

Thank you

[DivitJain26]

Hello @kgryte
Hope you’re doing well.

I had a few questions regarding BLAS routines

1. Testing precision in double-precision (d and z) routines
   I have observed two common approaches in existing packages:

   i. First, Integer like inputs (e.g., dgemv, x = [1.0, 2.0]): These produce outputs with clean decimal representations, making comparisons straightforward. However, I’m unsure whether this adequately tests numerical precision.

   ii. Second, Fractional inputs (e.g., drot, xbuf = [0.6, 0.1, -0.5, 0.8, ...]): These often result in outputs like 1.9250000715255737, requiring approximate comparisons, a custom function isApprox( t, actual, expected, rtol ) is being used here. This seems more effective for validating precision.

   For Level 2 and Level 3 double-precision routines, which approach is preferred?

2. Documentation for packed matrix formats (eg., cbmv and chemv)
   Since these routines require matrices to be packed in a specific format before being passed as input:

   • Should I include links to external references (e.g., Intel MKL documentation) in the README.md?
   • Or should I provide a detailed explanation directly in the README.md?, if yes then is it acceptable to adapt or reuse descriptions from MKL documentation?

3. Validation of strides, offsets, and dimensions
   I noticed that most Level 2 routines validate parameters like strideX, strideY, and LDA in their wrappers, but do not check:

   • Offsets (offsetA, offsetX, offsetY)
   • Matrix strides (strideA1, strideA2)
   • Effective vector lengths considering stride and offset

   Is this omission intentional? If not, should I add validation for these cases?
   Also, should there be explicit checks to ensure dimensional compatibility (e.g., preventing multiplication of a 3×3 matrix with a vector that is too short given its stride and offset)?

Thank you.

[DivitJain26]

• I noticed that there have been fewer PR merges over the past few weeks, likely due to maintainers’ availability. I was wondering how open PRs will be taken into account for GSoC applications and proposals?

Will maintainers still be able to review pull requests submitted after the proposal deadline (March 31)?

If yes, is there a rough timeframe after the deadline during which these PRs can still be considered as part of a candidate’s GSoC proposal evaluation?

[kgryte]

A few topics from me:

• Note on GSoC proposals and public discussions: #gsoc-questions > general chat @ 💬

[Om-A-osc]

I submitted my draft PR about a week ago, but it hasn’t received any feedback yet. My initial plan was to post it on the GSoC repository and refine it based on your reviews. Since the proposal submission deadline (March 31) is approaching, I would really appreciate it if you could take a look when you have time.

I believe that once you’ve reviewed the proposed architecture, we can have a much more focused and meaningful discussion on refining the C doctester, rather than me asking blind or disconnected questions on zulip.

DRAFT PROPOSAL

stdlib-js/google-summer-of-code#189

Did you have a look at the draft pr and error log i shared on zulip ? If yes what do you think.

Draft pr for concept validation

stdlib-js/stdlib#11106

Complete repo error log for C source files

https://drive.google.com/file/d/1wuXgV06lRakNuuBvjZuftk1MfFFLVn4R/view

[Amansingh0807]

Hi @kgryte and team,

I wanted to discuss Issue #44 (GSOC Repo one) (StringArray) and get your thoughts on a proposed memory architecture before finalizing my GSoC proposal.

After studying the implementations of Complex64Array and BooleanArray, I understand the necessity of backing custom arrays with fixed-length memory for C-interop. However, since strings are variable-length, I am proposing a Dual-Buffer Architecture (similar to Apache Arrow):

1. _buffer (Data Buffer): A contiguous Uint8Array storing the raw UTF-8 encoded bytes.
2. _offsets (Offset Buffer): An Int32Array storing the start/end byte boundaries for each string.

My main architectural question is regarding the reallocation strategy during a set() operation when a new string is larger than the existing slot.

To avoid an $O(N)$ memory shift across the entire array, I am proposing an "Append and Amortized Compaction" strategy:

• Append the new UTF-8 bytes to the end of the _buffer.
• Update the _offsets for that index to point to the new tail.
• The old byte slice becomes "dead space".
• Track total dead space and trigger a compact() routine (allocating a new buffer with a growth factor, e.g., 1.5x) only when a certain threshold is reached.

1. Does this "Append & Compact" strategy align with your vision for performance and C-level ndarray iteration, compared to a full reallocation on every growth?
2. For C interop, would passing a struct containing pointers to both the data buffer and offset array be the expected approach for the iteration macros?

Looking forward to discussing this!

[therealharshit]

Hello everyone,

I’d like to discuss the project on bringing production dependencies in-house (#102).

So far, I’ve been exploring the immediate targets: debug, minimist, resolve, and glob. I’ve also drafted two RFCs outlining implementation plans for minimist and debug.

I wanted to get your guidance on the next steps:

• Which dependencies would you recommend prioritizing next?
• Should I consider working on d3-*, vdom-to-html, and virtual-dom, given that they are lower priority and may be phased out after migrating plot functionality to Vega?
• Also, I’d appreciate your thoughts on handling more complex dependencies like acorn and friends, as well as readable-stream, since these seem significantly more challenging from a design and maintenance perspective.

Looking forward to your suggestions. Thanks!

Further discussion can continue on this public thread: #gsoc-questions > Improve project supply chain security by bringing production

[prajjwalbajpai]

Thanks @kgryte for the comments on my draft GSoC proposal!!

Following up on that feedback, I wanted to confirm if this implementation for my dgetc2 PR correctly addresses the point you raised.

		xmax = 0.0;

		ix1 = offsetA + ( i*( strideA1 + strideA2 ) ); // Index of `A( i, i )`

		if ( isRowMajor( [ strideA1, strideA2 ] ) ) {
			dx0 = strideA2;
			dx1 = strideA1 - ( N*strideA2 ) + ( i*dx0 );
			for ( i1 = i; i1 < N; i1++ ) {
				for ( i0 = i; i0 < N; i0++ ) {
					if ( abs( A[ ix1 ] ) >= xmax ) {
						xmax = abs( A[ ix1 ] );
						ipv = i1;
						jpv = i0;
					}
					ix1 += dx0;
				}
				ix1 += dx1;
			}
		} else { // column-major
			dx0 = strideA1;
			dx1 = strideA2 - ( N*strideA1 ) + ( i*dx0 );
			for ( i1 = i; i1 < N; i1++ ) {
				for ( i0 = i; i0 < N; i0++ ) {
					if ( abs( A[ ix1 ] ) >= xmax ) {
						xmax = abs( A[ ix1 ] );
						ipv = i0;
						jpv = i1;
					}
					ix1 += dx0;
				}
				ix1 += dx1;
			}
		}		

[DhruvArvindSingh]

Hey so i added a tool in PR which sees all the deps of a package and shows which deps have C implementations remaining

In the latest version it also accepts package family path as input and according to the C backlog deps it strategizes which packages to implement first and so on, it shows startegy in 5 levels.

maybe we can use this in some CI🤔

It looks something like this right now!!

dhruv  stdlib ➜ node lib/node_modules/@stdlib/_tools/pkgs/c-impl-status/bin/cli @stdlib/math/base/special

Family: @stdlib/math/base/special
──────────────────────────────────────────────────
  372 packages  │  13 need C  │  359 ✓ done  │  0 JS-only

Implementation order (13 packages, 4 levels):

├── Level 1 — implement these first (8)
│   ├── ✗  gammaincinv      
│   ├── ✗  kernel-betainc   
│   ├── ✗  maxn             
│   ├── ✗  minmaxabsn       
│   ├── ✗  minmaxn          
│   ├── ✗  minn             
│   ├── ✗  polygamma        
│   └── ✗  sici             
│
├── Level 2 — after Level 1 (3)
│   ├── ✗  betainc          
│   ├── ✗  maxabsn          
│   └── ✗  minabsn          
│
├── Level 3 — after Level 2 (1)
│   └── ✗  kernel-betaincinv
│
└── Level 4 — after Level 3 (1)
    └── ✗  betaincinv       

Already done ✓ (359):
  abs  abs2  abs2f  absf  absgammalnf  acos  acosd  acosdf  acosf  acosh  
  acoshf  acot  acotd  acotdf  acotf  acoth  acothf  acovercos  acovercosf  
  acoversin  acoversinf  acsc  acscd  acscdf  acscf  acsch  ahavercos  
  ahavercosf  ahaversin  ahaversinf  asec  asecd  asecdf  asecf  asech  asin  
  asind  asindf  asinf  asinh  asinhf  atan  atan2  atan2d  atan2f  atand  
  atandf  atanf  atanh  atanhf  avercos  avercosf  aversin  aversinf  
  bernoulli  bernoullif  besselj0  besselj1  bessely0  bessely1  beta  betaln  
  binet  binomcoef  binomcoeff  binomcoefln  boxcox  boxcox1p  boxcox1pinv  
  boxcoxinv  cabs  cabs2  cabs2f  cabsf  cbrt  cbrtf  cceil  cceilf  cceiln  
  ccis  ceil  ceil10  ceil2  ceilb  ceilf  ceiln  ceilsd  cexp  cflipsign  
  cflipsignf  cfloor  cfloorf  cfloorn  cinv  cinvf  clamp  clampf  copysign  
  copysignf  cos  cosd  cosdf  cosf  cosh  coshf  cosm1  cosm1f  cospi  cospif  
  cot  cotd  cotdf  cotf  coth  covercos  covercosf  coversin  coversinf  
  cphase  cphasef  cpolar  cpolarf  cround  croundf  croundn  csc  cscd  cscdf  
  cscf  csch  csignum  csignumf  deg2rad  deg2radf  digamma  dirac-delta  
  dirac-deltaf  dirichlet-eta  ellipe  ellipj  ellipk  erf  erfc  erfcinv  
  erfcx  erfinv  exp  exp10  exp2  expit  expm1  expm1rel  factorial  
  factorial2  factorial2f  factorialln  factoriallnf  falling-factorial  
  fast/abs  fast/absf  fast/acosh  fast/alpha-max-plus-beta-min  fast/asinh  
  fast/atanh  fast/atanhf  fast/hypot  fast/hypotf  fast/max  fast/maxf  
  fast/min  fast/minf  fast/pow-int  fast/uint32-log2  fast/uint32-sqrt  
  fibonacci  fibonacci-index  fibonacci-indexf  fibonaccif  flipsign  
  flipsignf  floor  floor10  floor2  floor2f  floorb  floorf  floorn  floornf  
  floorsd  fmod  fmodf  fresnel  fresnelc  fresnels  frexp  frexpf  gamma  
  gamma-delta-ratio  gamma-lanczos-sum  gamma-lanczos-sum-expg-scaled  
  gamma-lanczos-sum-expg-scaledf  gamma1pm1  gammainc  gammaln  gammasgn  
  gammasgnf  gcd  gcdf  hacovercos  hacovercosf  hacoversin  hacoversinf  
  havercos  havercosf  haversin  haversinf  heaviside  heavisidef  hyp2f1  
  hypot  hypotf  inv  invf  kernel-cos  kernel-cosf  kernel-log1p  
  kernel-log1pf  kernel-sin  kernel-sincos  kernel-sincosf  kernel-sinf  
  kernel-tan  kernel-tanf  kronecker-delta  kronecker-deltaf  labs  lcm  lcmf  
  ldexp  ldexpf  ln  lnf  log  log10  log1mexp  log1p  log1pexp  log1pf  
  log1pmx  log2  logaddexp  logf  logit  logitf  lucas  lucasf  max  maxabs  
  maxabsf  maxf  min  minabs  minabsf  minf  minmax  minmaxabs  minmaxabsf  
  minmaxf  modf  modff  nanmax  nanmaxf  nanmin  nanminf  negafibonacci  
  negafibonaccif  negalucas  negalucasf  nonfibonacci  nonfibonaccif  pdiff  
  pdifff  pow  powf  powm1  rad2deg  rad2degf  ramp  rampf  rcbrt  rcbrtf  
  rempio2  rempio2f  riemann-zeta  rising-factorial  round  round-nearest-even  
  round10  round2  roundb  roundf  roundn  roundnf  roundsd  rsqrt  rsqrtf  
  sec  secd  secdf  secf  sech  signum  signumf  sin  sinc  sincf  sincos  
  sincosd  sincosdf  sincosf  sincospi  sind  sindf  sinf  sinh  sinpi  sinpif  
  spence  spencef  sqrt  sqrt1pm1  sqrtf  sqrtpi  sqrtpif  tan  tand  tandf  
  tanf  tanh  tribonacci  tribonaccif  trigamma  trigammaf  trunc  trunc10  
  trunc2  truncb  truncf  truncn  truncsd  vercos  vercosf  versin  versinf  
  wrap  wrapf  xlog1py  xlogy  xlogyf

[nakul-krishnakumar]

I would like to discuss about:

• Review on revised work plan for GSoC 2026 project
  • Updates done on the sheet from previous iteration:
    • Removed sub-namespaces like cluster and regression and kept all the algorithms inside @stdlib/ml namespace.
    • Revised list of algorithms according to the size and feasibility of implementation
  • Sheet link: sheet
• If time persists after the mentioned work plan, can I look into refactoring ml/incr APIs to support newer implementations (including some TODOs as well as the newly added distance metrics)? If yes, what would be more prioritised, refactoring ml/incr APIs or adding additional batch ml APIs mentioned in the above sheet?
• Anything particular I should keep in mind as this proposal is not listed under stdlib GSoC proposals?

[batpigandme]

• I've found it hard to find the source code for specific functions in Julia

@LoayAhmed304 are you talking about Julia packages or base Julia. I think all of their source code should be in the GitHub repo: https://github.com/JuliaLang/julia/blob/master/base/array.jl

[nirmaljb]

I had some questions regarding my gsoc proposal: 188

[kgryte]

Thanks everyone!