Skip to content

fix: change the calculation of precision in round method#21123

Closed
SihongShen wants to merge 1 commit intoapache:masterfrom
SihongShen:fix-16266
Closed

fix: change the calculation of precision in round method#21123
SihongShen wants to merge 1 commit intoapache:masterfrom
SihongShen:fix-16266

Conversation

@SihongShen
Copy link
Copy Markdown
Contributor

Brief Information

This pull request is in the type of:

  • bug fixing
  • new feature
  • others

What does this PR do?

Revise the calculation of precision in round function based on PR #16286 .

Fixed issues

#16266

Details

Before: What was the problem?

The dataset ['0.000000000012', '0.000000000034', '0.000000000010', '0.000000000038'] was round to 0 as data are too small.

After: How does it behave after the fixing?

The dataset can be displayed normally after changing the precision based on the review suggestions in PR #16286. The testing examples is added to /test/logScale.html .

Document Info

One of the following should be checked.

  • This PR doesn't relate to document changes
  • The document should be updated later
  • The document changes have been made in apache/echarts-doc#xxx

Misc

ZRender Changes

  • This PR depends on ZRender changes (ecomfe/zrender#xxx).

Related test cases or examples to use the new APIs

N.A.

Others

Merging options

  • Please squash the commits into a single one when merging.

Other information

export function round(x: number | string, precision?: number, returnStr?: boolean): string | number {
if (precision == null) {
precision = 10;
const expStr = (x + '').split('e')[1];
Copy link
Copy Markdown
Member

@100pah 100pah Jul 22, 2025

Choose a reason for hiding this comment

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

Computing precision relying solely on scientific notation is not reliable enough.
e.g. , 0.0000010000000001 + '' => 0.0000010000000001 + '', not scientific notation, even if it's fractional digits are over 10.

There is a method getPrecision in this file that provides the precision calculation.
But I'm afraid it doesn't seems reasonable to "round based on the precision of a number" - the result appear to be that nothing happens.

This method is meant to round the input number with a given precision. The default value 10, by historical reasons, is an arbitrary value, and perhaps it shouldn't be provided - the caller should always provide a precision based on the scenario, and there is no universally adaptable default precision.

The bad case (as posted in #16266) results from the calling of this method from https://github.com/apache/echarts/blob/5.6.0/src/scale/Interval.ts#L284 uses the default precision 10.
Actually, I think a this._intervalPrecision should be used here to fix this bug.

A quick fix: #21126 to hitch a ride on this v6.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants