New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow configurable precision in format when in "engineering" mode #1147
Comments
Unfortunately, math.js does not have any mechanism to keep track of significant figures. In your example, both numbers are converted to the same floating point representation the moment they are encountered. There's no reason such a feature couldn't be added, which would propagate errors through each calculation and automatically format the result with the correct number of significant figures, but it would be a tremendous undertaking. The decimal.js library, which math.js's BigNumber type is based on, probably comes closest to realizing such a capability. |
Thank you for your reply, good to know that it is an complex problem and I wasn't missing something obvious. I was hoping that I could get the functionality that I wanted by specifying the precision; however, I am a bit confused about specifying precision when formatting with engineer mode. When formatting numbers that have zeros that trail a decimal place then it seems that the behaviour of the exponential mode is what I expected; however, for engineering mode the behaviour isn't analogous to that seen in the exponential mode. For instance, compare lines 4 and 9 below.
|
The documentation doesn't actually specify what meaning Do you have any interest in tackling this yourself? |
Have changed the title 😄 |
Thanks for opening this discussions @ewanorr . It's ok with me to change the behavior of Maybe instead of using |
Hi @ericman314 thank you for looking at this. At the moment I probably wouldn't know where to begin with attempting to change the behaviour of engineering notation. If me and one of my colleagues get free time in a few weeks time I might see if he is keen and able to have a look at this with me. |
No worries, @ewanorr. I'm sure someone here will be happy to take care of it. @josdejong, looking more closely at the code for engineering mode, it looks like the original intent of engineering mode was to add zeroes if necessary to produce a number with Lines 267 to 268 in f0e5ed5
Which means in this example from @ewanorr, the expected result is the intended result: format(12400.00, {notation: "engineering", precision: 7})
actual 12.400e+3, expected 12.40000e+3 I checked and there are no tests cases that require adding zeroes, so I think this is a bug that has gone unnoticed a very long time. So I think this would actually be a bug fix and not a breaking change. And to keep things simple, I would be okay with just sticking with the |
Another thought: we could remove the |
@ericman314 I think you're right, the intention was to add trailing zeros to note real significant digits, so this is about a bug in the I like your proposal to keep |
I've submitted a PR #1163 which hopefully fixes the bug. |
Should be fixed now in |
The "engineering" mode in the format function seems to ignore significant figures that occur after a decimal point. Considering the following two examples, the first performs as expected; however I expected that the second example would be more precise.
format(12400,{notation: "engineering"})
"12.400e+3" // expected "12.400e+3"
format(12400.00,{notation: "engineering"})
"12.400e+3" // expected "12.40000e+3"
The text was updated successfully, but these errors were encountered: