Skip to content

Conversation

@reteps
Copy link

@reteps reteps commented Jan 7, 2026

This PR adds a new adaptiveScientific mode which is a combination of the auto and scientific modes. Disclosure: this PR was written by Claude 4.5 Opus in planning mode, and manually iterated

value          | adaptiveScientific  | auto                | scientific        |
--------       | -----------------   | ------------------- | ------------------ |
1 / 7000000    | 0.000000142857...   | 0.000000142857...   | 1.42857... * 10^-7 |
1 / 70000000   | 1.42857... * 10^-8  | 142857 ... * 10^-23 | 1.42857... * 10^-8 |

@reteps reteps changed the title Fix normalization, add tests fix: normalize small numbers in scientific notation correctly Jan 7, 2026
@reteps reteps closed this Jan 8, 2026
@reteps reteps deleted the normalized-scientific-notation-fix branch January 8, 2026 06:01
@reteps reteps reopened this Jan 12, 2026
// If we have some fractional digits *and* an exponent, we need to
// adjust the whole part to include the fractional part.
// 1.23e4 -> 123e2
if (exp !== 0 && fractionalPart) {
Copy link
Author

Choose a reason for hiding this comment

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

This code seems wrong -- why would we ever want this?

Copy link
Member

Choose a reason for hiding this comment

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

To avoid having both a fractional part and an exponent. As the comment says, it's to have "123e2" instead of "1.23e4".

Copy link
Author

Choose a reason for hiding this comment

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

Put differently: how can I avoid / opt-out of this behavior?

Copy link
Author

@reteps reteps Jan 13, 2026

Choose a reason for hiding this comment

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

I always either want the decimal version of a number (when numbers are within the avoidExponents range), or normalized scientific notation.

Copy link
Member

Choose a reason for hiding this comment

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

ah.... OK, so you want a scientific notation with an avoidExponentsRange, a non-normalized scientific notation.

Copy link
Author

@reteps reteps Jan 13, 2026

Choose a reason for hiding this comment

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

value          | desired             | auto                | scientific        |
--------       | ---------------     | ------------------- | ------------------ |
1 / 7000000    | 0.000000142857...   | 0.000000142857...   | 1.42857... * 10^-7 |
1 / 70000000   | 1.42857... * 10^-8  | 142857 ... * 10^-23 | 1.42857... * 10^-8 |
  • Within the avoidExponentsRange, we want the "auto" behavior
  • Outside of the avoidExponentsRange, we want the "scientific" behavior

Copy link
Author

Choose a reason for hiding this comment

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

I'm happy to put up a PR implementing an option so that we can have this behavior, I'm just not sure what the API design should be.

Copy link
Member

Choose a reason for hiding this comment

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

"adaptiveScientific": Uses fixed decimal notation within a specified exponent range and strict scientific notation otherwise

Copy link
Author

Choose a reason for hiding this comment

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

Thanks, I fixed up this PR to document and add such an option.

@arnog
Copy link
Member

arnog commented Jan 12, 2026

The first test is incorrect: 1 / 7000000 is 14\,285\,714\,285\,714\,285\cdot10^{-23} which is not inside the default "avoidExponentInRange". Also, bug 245 is that when specifying a notation of "scientific", the result does not always return the scientific notation. This is not what these tests are testing.

@reteps
Copy link
Author

reteps commented Jan 12, 2026

@arnog Should I file a new issue? I interpreted bug 245 as meaning that the input may be in scientific notation. Also, Google shows that 1 / 7000000 is ~1.42857143e-7 which is in the default range. Otherwise, the test would be failing, no?

Regardless of #245 , the block of code I delete in this PR seems obviously wrong, unless I am missing something. The tests I add to this PR will both fail on master.

@arnog
Copy link
Member

arnog commented Jan 13, 2026

It seems like you are looking for a notation which is neither "auto", nor the "scientific" notation.

It would be helpful if you could file a new issue describing the notation you're looking for, either with a definition of this notation explaining the relationship between the mantissa and the exponent.

@reteps reteps changed the title fix: normalize small numbers in scientific notation correctly feat: add adaptiveScientific mode Jan 13, 2026
@reteps reteps marked this pull request as draft January 13, 2026 15:54
} else if (options.notation === 'scientific') {
result = serializeScientificNotationNumber(num.toExponential(), {
...options,
avoidExponentsInRange: null, // Scientific notation should always use exponents
Copy link
Author

Choose a reason for hiding this comment

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

I think this resolves #245

@reteps reteps marked this pull request as ready for review January 13, 2026 17:11
@reteps reteps requested a review from arnog January 13, 2026 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants