feat: add number/float16/ctor

[gururaj1512]

---

type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes. report:

• task: lint_filenames status: passed
• task: lint_editorconfig status: passed
• task: lint_markdown status: passed
• task: lint_package_json status: passed
• task: lint_repl_help status: na
• task: lint_javascript_src status: passed
• task: lint_javascript_cli status: na
• task: lint_javascript_examples status: na
• task: lint_javascript_tests status: passed
• task: lint_javascript_benchmarks status: passed
• task: lint_python status: missing_dependencies
• task: lint_r status: na
• task: lint_c_src status: missing_dependencies
• task: lint_c_examples status: na
• task: lint_c_benchmarks status: na
• task: lint_c_tests_fixtures status: na
• task: lint_shell status: na
• task: lint_typescript_declarations status: passed
• task: lint_typescript_tests status: na
• task: lint_license_headers status: passed ---

Resolves None.

Description

What is the purpose of this pull request?

This pull request:

• feat: add number/float16/ctor

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• None

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

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 helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

{{TODO: add disclosure if applicable}}

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
number/float16/ctor	$\color{green}331/331$ $\color{green}+0.00%$	$\color{green}13/13$ $\color{green}+0.00%$	$\color{green}4/4$ $\color{green}+0.00%$	$\color{green}331/331$ $\color{green}+0.00%$

The above coverage report was generated for the changes in this PR.

[gururaj1512]

So this package should just contain

typedef struct {
	uint16_t bits;
} stdlib_float16_t;

If that's the case I think we would not need the addon to test as discussed.

[kgryte]

No, it should contain more. It was that you had included a subset of functions for which we have public APIs which exist elsewhere. Certainly most of the "from" APIs should remain in this package.

[gururaj1512]

The "from" APIs are internally using the stdlib_float16_from_float32 and that API if created in different package would require number/float16/ctor. This is creating deadlock.

[kgryte]

Ah, right, circular native dependencies. 🤦‍♂️ You're right. This is a pickle. It is either all or none. Yeah, maybe it is the case that this package only includes the stdlib_float16_t type definition. Otherwise, all conversion utils exist outside this package in various micro-modules.

[kgryte]

...otherwise, it is odd if JS conversion utils exist outside this package, but C conversion functions don't. Better to be consistent and co-localize JS/C functions. While it departs from complex128 and complex64, it is okay for those to be special. We'll likely need to do the same thing as float16 when we add int64 and uint64 value types.

[gururaj1512]

/stdlib update-copyright-years

[kgryte]

LGTM after refactoring. In particular, I went ahead and added small helper utilities for portably converting between an opaque float16 value and its binary representation, with support for native float16 support when available.

This means that the C implementation of to-word and from-word can be very thin wrappers around these helpers and we can avoid some of the hairy implementation details we needed to implement in JS.

[gururaj1512]

LGTM after refactoring. In particular, I went ahead and added small helper utilities for portably converting between an opaque float16 value and its binary representation, with support for native float16 support when available.

This means that the C implementation of to-word and from-word can be very thin wrappers around these helpers and we can avoid some of the hairy implementation details we needed to implement in JS.

Yeah, I see this way it makes much more sense and easier.