Office Hours (2026-02-24) #85

Activity

1. kgryte

   added

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

   on Feb 24, 2026
2. officiallyanee commented on Feb 24, 2026

   

   officiallyanee

   on Feb 24, 2026

   Member

   More actions

   Kindly Review,
   10218
   10265
   Thanks!
3. nirmaljb commented on Feb 24, 2026

   

   nirmaljb

   on Feb 24, 2026

   More actions

   Can you please review them?
   Kernel-betainc: #10279
   Cexpf: #10223
   Powm1f: #10315
4. GlyphicGuy commented on Feb 24, 2026

   

   GlyphicGuy

   on Feb 24, 2026

   More actions

   • I would like to discuss some potential proposal ideas for the Gsheets repo, pertaining to the issues open there.
   • Also about the Fused operations as it's mentioned as a deliverable in the Idea and has not been implemented yet.
   • I have done the needful as discussed earlier and the following PRs are ready for a final review:
     • feat: add gsheets/api/math/acosd gsheets#5
     • feat: add gsheets/api/math/acotd gsheets#6
5. shubham220420 commented on Feb 24, 2026

   

   shubham220420

   on Feb 24, 2026

   Last edited by shubham220420

   More actions

   a final check on
   10121
   10154
   10282
   9857
   9739

   also a discussion on adding bessel function
6. DivitJain26 commented on Feb 24, 2026

   

   DivitJain26

   on Feb 24, 2026

   Last edited by DivitJain26

   Member

   More actions

   Can you pls check: feat: add blas/base/cgemv #9839

   Guidance over: feat: add blas/base/cgbmv #10468
   I’d really appreciate some guidance on whether the layout handling and branch logic look correct, especially around the band indexing.
7. sagar7162 commented on Feb 24, 2026

   

   sagar7162

   on Feb 24, 2026

   More actions

   Kindly review stdlib-js/stdlib#10145,
   stdlib-js/stdlib#9785
8. manit2004 commented on Feb 24, 2026

   

   manit2004

   on Feb 24, 2026

   More actions

   Review on wald mode pr #10205
9. parthodas23 commented on Feb 24, 2026

   

   parthodas23

   on Feb 24, 2026

   Last edited by parthodas23

   More actions

   I am working on fixing the lint errors in @stdlib/proxy/ctor/lib/polyfill.js as part of Issue #6214. Following previous feedback, I am attempting to disable the jsdoc-doctest rule for the example instead of changing the return value from 6.28 to 3.14.

   However, I am encountering a conflict:

   1. If I use // eslint-disable-next-line before the return comment, the linter throws an orphaned return annotation error.
   2. If I place the disable comment at the top of the @example block, the linter ignores the comment and still flags the value mismatch.

   What is the preferred syntax for disabling a doctest mismatch within a JSDoc block in this project without breaking the internal JSDoc node structure?
10. Witty-31-06 commented on Feb 24, 2026

    

    Witty-31-06

    on Feb 24, 2026

    Last edited by Witty-31-06

    More actions

    If possible I would like to discuss the GSoC idea of stdlib-js/google-summer-of-code#101. I have questions regarding implementation of mmap utilities in JS.

    I found this Node Library which implements mmap in NodeJS environment.
11. nirmaljb commented on Feb 24, 2026

    

    nirmaljb

    on Feb 24, 2026

    More actions

    I found an inconsistency in @stdlib/math/base/special/kernel-betainc for out[1] (derivative).

    When regularized=false, the returned derivative is branch-dependent:
      - In some branches, out[1] is effectively regularized derivative.
      - In other branches, out[1] is unregularized derivative (scaled by beta(a,b)).

    out[0] appears correct for regularized/upper in all cases I checked.

    In Boost’s beta.hpp, derivative output pointer is only valid for normalized mode (assert((p_derivative == 0) || normalised)), and derivative is exposed separately via ibeta_derivative:

    What should we do about it?

    Could we make out[1] semantics consistent for regularized=false (either always normalized derivative or always unregularized), and add tests that assert this across branch paths?

    The C porting has been done with parity to the JavaScript implementation. And the test cases have been written with reference to betainc + some edge cases.
12. parthodas23 commented on Feb 24, 2026

    

    parthodas23

    on Feb 24, 2026

    Last edited by parthodas23

    More actions

    In addition to the question above, I have opened a PR for this fix: #10432. If you could review it when you have a moment, I'd appreciate any feedback on whether this approach meets the project's standards. Thank you!
13. kgryte

    closed this as completedon Mar 3, 2026