Skip to content

Conversation

@Neerajpathak07
Copy link
Member

Resolves none.

Description

What is the purpose of this pull request?

This pull request:

  • Adds number/float16/base/ulp-difference

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.

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

@Neerajpathak07 Neerajpathak07 added the Feature Issue or pull request for adding a new feature. label Dec 23, 2025
@stdlib-bot
Copy link
Contributor

stdlib-bot commented Dec 23, 2025

Coverage Report

Package Statements Branches Functions Lines
number/float16/base/ulp-difference $\color{green}161/161$
$\color{green}+0.00%$
$\color{green}9/9$
$\color{green}+0.00%$
$\color{green}2/2$
$\color{green}+0.00%$
$\color{green}161/161$
$\color{green}+0.00%$

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

@Neerajpathak07 Neerajpathak07 marked this pull request as ready for review December 23, 2025 07:45
@stdlib-bot stdlib-bot added the Needs Review A pull request which needs code review. label Dec 23, 2025
@kgryte kgryte removed the Needs Review A pull request which needs code review. label Dec 25, 2025
if ( isnan( x ) || isnan( y ) ) {
return NaN;
}
// Convert input values to unsigned 32-bit integers corresponding to the IEEE 754 binary representation of half-precision floating-point numbers:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused. Why 32-bit integers? IIUC, toWord returns "16-bit" integers?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh right forgot to change the call should be:-

Suggested change
// Convert input values to unsigned 32-bit integers corresponding to the IEEE 754 binary representation of half-precision floating-point numbers:
// Convert input values to unsigned 16-bit integers corresponding to the IEEE 754 binary representation of half-precision floating-point numbers:


// MODULES //

var isnan = require( '@stdlib/math/base/assert/is-nan' );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In JS, using this util is likely fine, given that numeric values in JS are all implicitly doubles.

*/
function monotoneKey( word ) {
if ( word & SIGN_MASK ) { // x < 0
return ( ~word + 1 ) &UINT16_MAX; // two's-complement negation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am guessing that you are AND'ing the bits because you've done ~word negation and because JS only has 32-bit integer ops, the leading zeros all get flipped on during negation and we want them to remain off. Am I correct?

The question I have, however, is whether two's complement negation actually works here, as the +1 no longer causes the word to overflow as a 32-bit integer does. Have you actually verified that the negation logic works as you expect?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just so we are clear, the negation and +1 is intended to convert values to allow lexicographic ordering. So it is important that we ensure this logic works as expected.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right so far while testing for specific range values it provides the desired result. What I had in mind is what you guessed right. The only way I can find out whether the complement negation is working out is by test it a few edge cases close to around 16-bit integer ops.
Also I'll take a look at a few references just to be on the safer side.

return ( ~word + 1 ) &UINT16_MAX; // two's-complement negation
}
// x >= 0
return ( word | SIGN_MASK ) &UINT16_MAX; // push +0 to just above -0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to & UINT16_MAX here?

Copy link
Member Author

@Neerajpathak07 Neerajpathak07 Dec 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used &UINT16_MAX to force the result to stay within 16 bits just so that monotone key would not be corrupted by sign-extension and overflow.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return ( word | SIGN_MASK ) &UINT16_MAX; // push +0 to just above -0
return ( word | SIGN_MASK ) >>> 0; // push +0 to just above -0

Copy link
Member

@kgryte kgryte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, this looks good. My main question is around monotone key conversion.

@kgryte kgryte added the Needs Changes Pull request which needs changes before being merged. label Dec 25, 2025
@Neerajpathak07
Copy link
Member Author

Neerajpathak07 commented Dec 25, 2025

Tested the two-complements negation logic with the following edge cases:-

d = ulpdiff( -1.1920928955078125e-7, -5.960464477539063e-8 );
console.log( d );
// => 1.0

d = ulpdiff( -5.960464477539063e-8, 5.960464477539063e-8 );
console.log( d );
// => 2.0

output log:-

[Running] node "c:\Users\HP\Stdlib\stdlib\lib\node_modules\@stdlib\number\float16\base\ulp-difference\test\edgeCase.js"
1
2
  1. adjacent negative values should differ by exactly 1 ULP, and it's returning 1 correctly.
  2. to confirm if sign boundary ordering is correct (same as SMALLEST_SUBNORMAL).

what I believe if the logic was broken it would have provided huge ulp diff.

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

Labels

Feature Issue or pull request for adding a new feature. Needs Changes Pull request which needs changes before being merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants