Skip to content

Office Hours (2026-07-14) #140

Closed
Closed

Description

@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 14-Jul-2026 16:30 (04:30 PM):

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

or in your local time:

Links

Joining the meeting

Agenda

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

Activity

  1. added
    Office HoursIssue announcing office hours and soliciting associated agenda items.
    on Jul 7, 2026
  2. DivitJain26 commented on Jul 14, 2026

    @DivitJain26
    Member
    • feat: add array/uint64 stdlib#12562 is ready for review.
    • I was looking at custom array methods, and I was wondering why not provide a default ordering and only use a custom compareFcn when the user supplies one?
  3. prajjwalbajpai commented on Jul 14, 2026

    @prajjwalbajpai
    Member
    • I have a doubt regarding tests, we use ULP difference to see whether tests are passing or not. But, near-zero values like 2.4e-17 and -4.6e-19 are both essentially zero and they differ by ~9e18 ULPs due to opposite signs. This is causing my tests to fail. Is there any other way to write tests?
    • For the dorgqr routine, I have tried to implement the mathematical verification test. Does this look fine?
    tape( 'the function generates an `M-by-N` real matrix `Q` with orthonormal columns (multiple blocks, mathematical verification)', function test( t ) {
    	var WORK;
    	var info;
    	var TAU;
    	var LDA;
    	var QT;
    	var A;
    	var C;
    	var M;
    	var N;
    	var K;
    	var i;
    	var I;
    	var Q;
    
    	M = 162;
    	N = 162;
    	K = 161;
    	LDA = M;
    
    	A = new Float64Array( M * N );
    	TAU = new Float64Array( K );
    	WORK = new Float64Array( 2 * N );
    
    	for ( i = 0; i < N; i++ ) {
    		A[ i + ( i * LDA ) ] = 1.0;
    	}
    	for ( i = 0; i < K; i++ ) {
    		TAU[ i ] = 2.0;
    	}
    
    	info = dorgqr( 'column-major', M, N, K, A, LDA, TAU, WORK, 2 * N );
    
    	Q = ctor( 'float64', A, [ M, N ], [ 1, LDA ], 0, 'column-major' ); // Create ndarray view of Q
    	QT = transpose( Q ); // Compute Q^T
    	C = new Float64Array( N * N ); // Compute C = Q^T * Q
    	dgemm( 'no-transpose', 'no-transpose', N, N, M, 1.0, QT.data, QT.strides[ 0 ], QT.strides[ 1 ], QT.offset, Q.data, Q.strides[ 0 ], Q.strides[ 1 ], Q.offset, 0.0, C, 1, N, 0 ); // Compute C = Q^T * Q
    
    	I = new Float64Array( N * N ); // Create identity matrix
    	for ( i = 0; i < N; i++ ) {
    		I[ i + ( i * N ) ] = 1.0;
    	}
    
    	t.strictEqual( info, 0, 'returns expected value' );
    	t.strictEqual( isAlmostEqual( C, I, 1 ), true, 'Q^T * Q equals identity matrix' );
    	t.end();
    });
  4. 0PrashantYadav0 commented on Jul 14, 2026

    @0PrashantYadav0
    Member

    Discussion on this issues: stdlib-js/stdlib#13468

  5. batpigandme commented on Jul 14, 2026

    @batpigandme
    Member

    AI-Generated Summary

    Caution

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

    Meeting Purpose

    Resolve technical questions and align on best practices for development.

    Key Takeaways

    • array-uint64 Sorting: Implement a default sort by comparing high then low words. Wrap user-provided comparators to ensure they receive uint64 instances, not raw buffer values.
    • Test Failures Near Zero: For values near zero with sign differences, use an absolute tolerance (abs(value) < eps) instead of ULP comparisons, which fail due to the large ULP distance across zero.
    • Test Fixture Optimization: To reduce large fixture sizes, Prajjwal will test a strategy of storing only column-major data and dynamically converting it to row-major for testing.
    • README Best Practices: Prioritize user clarity by hiding non-essential info (e.g., ESLint comments) in README examples. Use existing high-level APIs (e.g., random for real numbers) to simplify code.

    Topics

    array-uint64 Custom Sort

    • Problem: The array-uint64 sort implementation lacks a default comparator.
    • Rationale: Unlike complex numbers, uint64 values have a total order, making a default sort necessary for consistency with other array types (e.g., array-bool).
    • Solution:
      • Default Comparator: Define a function to sort by comparing high words, then low words.
      • User Comparator: Wrap user-provided functions to ensure they receive uint64 instances, not raw buffer values.
      • Scope: The default comparator can be defined in the parent scope; the user wrapper must be defined within the sort method.

    Test Failures Near Zero

    • Problem: ULP comparisons fail for values near zero with opposite signs (e.g., +1e-308 vs. -1e-308), which have a large ULP distance but are mathematically equivalent.
    • Solution:
      • Absolute Tolerance: For values expected to be near zero, use an absolute tolerance check: abs(value) < eps. This handles sign differences correctly.
      • ULP Comparison: Continue using ULP comparisons for all other values where signs are expected to match.

    Optimizing Mathematical Verification Tests

    • Context: Prajjwal is writing mathematical verification tests (e.g., Q * Q^T = I) to supplement Fortran reference tests.
    • Optimizations:
      • Transpose: Use DGETrans instead of manual buffer manipulation.
      • Identity Matrix: Use DLAset with alpha=0, beta=1 to create an identity matrix.
    • Fixture Optimization Idea:
      • Proposal: Store only column-major data in JSON fixtures.
      • Method: Dynamically convert column-major data to row-major for testing using DGETrans.
      • Goal: Reduce large fixture sizes and simplify maintenance.

    README & Example Best Practices

    • Problem: recent PRs used complex number random-generation logic for real-valued arrays and included ESLint comments in README examples.
    • Rationale for Corrections:
      • API Usage: Use existing high-level APIs (e.g., random for real numbers) to simplify code. The complex number logic is a temporary workaround for a missing API and should not be generalized.
      • README Clarity: Hide non-essential info (e.g., ESLint comments) from users. Use HTML comments (<!-- eslint-disable -->) to hide linter directives in markdown, ensuring examples are clean and focused.
    Full transcript

    Full office hours transcript

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Office HoursIssue announcing office hours and soliciting associated agenda items.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions