feat: add ndarray/base/scalar-dtype

[kunalKumar-13]

Resolves #11002.

Description

What is the purpose of this pull request?

This pull request:

• adds ndarray/base/scalar-dtype, which resolves a default ndarray data type from a scalar value.

The logic currently exists in two places:

• ndarray/base/atleastnd/lib/main.js:111 — which carries the TODO this implements
• ndarray/from-scalar/lib/main.js:128

Both spell the same four branches: a number resolves to the default real-valued floating-point dtype, a boolean to the default boolean dtype, a complex number to a corresponding complex dtype (falling back to the default complex-valued floating-point dtype when unrecognized), and everything else to 'generic'.

var scalarDataType = require( '@stdlib/ndarray/base/scalar-dtype' );

var dt = scalarDataType( 3.0 );
// returns 'float64'

dt = scalarDataType( true );
// returns 'bool'

dt = scalarDataType( null );
// returns 'generic'

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• [RFC]: add ndarray/base/scalar-dtype #11002

Questions

Any questions for reviewers of this pull request?

Two:

1. I have not migrated ndarray/base/atleastnd or ndarray/from-scalar to use the new package, so it can be reviewed on its own. Would you prefer that folded in here, or as a follow-up?
2. Number and Boolean objects resolve to 'generic', because both existing call sites test with isPrimitive. I preserved that rather than widening it, since changing the behaviour would change both consumers the moment they adopt this — but say if you'd rather it accepted boxed primitives.

Other

Any other information relevant to this pull request?

The package follows ndarray/base/min-signed-integer-dtype as its structural reference, and is registered in the ndarray/base namespace (lib/index.js) and TypeScript declarations (docs/types/index.d.ts), placed between rotr90 and serialize-meta-data to match that file's package-path ordering.

A full npm install was not available in my environment, so I ran the test, example, and benchmark files directly rather than through make. Local results:

# tests 23
# pass  23
# ok

benchmark: ~18.4M ops/sec

Test coverage includes numbers (NaN and both infinities included), booleans, Complex128 and Complex64, a complex-like object with an unrecognized dtype, and the non-scalar cases — strings, null, undefined, arrays, plain objects, functions, and the boxed Number/Boolean cases above. Since lint was not run locally, please flag anything CI turns up and I will fix it.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance.

This PR was written with Claude Code. It was used to locate the duplicated logic from the TODO in #11002, to read min-signed-integer-dtype as a structural reference, and to draft the implementation, tests, benchmark, docs, and TypeScript declarations. I verified the behaviour case by case against the two existing implementations and ran the tests, examples, and benchmark locally before opening this.

---

@stdlib-js/reviewers

[stdlib-bot]

👋 Hi there! 👋

And thank you for opening your first pull request! We will review it shortly. 🏃 💨

Getting Started

• Please read our contributing guidelines if you haven't already.
• For development guidance, refer to the development guide.

Next Steps

1. A project maintainer will approve GitHub Actions workflows for your PR.
2. All CI checks must pass before your submission can be fully reviewed.
3. You'll need to address any failures in linting or unit tests.

Running Tests Locally

You can use make to run any of the CI commands locally from the root directory of the stdlib repository:

# Run tests for all packages in the math namespace:
make test TESTS_FILTER=".*/@stdlib/math/.*"

# Run benchmarks for a specific package:
make benchmark BENCHMARKS_FILTER=".*/@stdlib/math/base/special/sin/.*"

If you haven't heard back from us within two weeks, please ping us by tagging the "reviewers" team in a comment on this PR.

If you have any further questions while waiting for a response, please join our Zulip community to chat with project maintainers and other community members.

We appreciate your contribution!

Documentation Links

• Contributing Guidelines
• Development Guide
• Zulip Chat
• make rules for running examples
• make rules for running unit tests
• make rules for running benchmarks

[stdlib-bot]

Hello! Thank you for your contribution to stdlib.

We noticed that the contributing guidelines acknowledgment is missing from your pull request. Here's what you need to do:

1. Please read our contributing guidelines.

2. Update your pull request description to include this checked box:

   - [x] Read, understood, and followed the [contributing guidelines](https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md)

This acknowledgment confirms that you've read the guidelines, which include:

• The developer's certificate of origin
• Your agreement to license your contributions under the project's terms

We can't review or accept contributions without this acknowledgment.

Thank you for your understanding and cooperation. We look forward to reviewing your contribution!

[kgryte]

Similar comments as discussed in #11003 apply to this PR.

[kunalKumar-13]

Thanks for the quick pointer — and apologies, this is a duplicate. I missed #11003 before opening this, which is entirely my fault: I checked that #11002 was unassigned and had no comments, but did not finish checking for an existing open PR against it. @Aniket-SS opened both on the same day and has been on this since March; I shouldn't have landed on top of that.

Happy to close this in favour of #11003 — just say the word and I will. I'd rather not have two PRs sitting on one issue.

On the substance, you're right that the comments carry over. Mine returns plain strings:

return DEFAULT_REAL;   // 'float64'
...
return 'generic';

so it makes exactly the assumption you flagged on #11003. The one place the two differ is the other point: this PR only adds the package and doesn't touch atleastnd or from-scalar, which I think is the split you asked for there.

Since I'm here and it seems to be the open question that stalled #11003 — @Aniket-SS asked in March whether ndarray/base/dtype-objects is the right way to return dtype objects rather than strings, and I don't think that got an answer. Reading it, dtype-objects builds a table of DataType instances keyed by dtype string:

out[ dt[ i ] ] = new DataType( dt[ i ] );

so resolving through that table would return an object while keeping the four branches as they are. If that's the intended shape, I'm glad to hand it over — or to rework mine and close #11003 instead, whichever is less disruptive. @Aniket-SS, your call as much as anyone's; you filed the RFC.

Either way, sorry for the noise.