Fixes #3100 Bug on simple rounding

[BrianFugate]

Fixed rounding bug described by @adshrc in issue #3100. I started with Jos' advice in the comments of the issue and also found help from the mathjs documentation here and from a similar issue here.

I addition to fixing the bug, I added two lines to the round function unit test. One for @adshrc's exact bug and a second for essentially the same bug that would also occur if the number of digits was specified with a second arg to the function call.

Thanks for the opportunity to contribute!

FYI, I didn't move David's name in the AUTHORS file. It looks like it made the opposite move in his last pull request that you just approved...

[josdejong]

Thanks Brian for your PR! Indeed you can leave AUTHORS untouched, I normally update that when doing a release.

A bit more context: in mathjs, there are two "levels" of functions:

• low level "plain" JS functions
• high level functions with runtime type-checking, dependency injection and for example config

Some feedbacks:

1. In this case, I think we should implement a solution in the high level function round, not in the low level function roundNumber, since the latter doesn't have access to config.epsilon. Can you move the implementation and tests to round.js? You can look up equalScalar.js to see how to use config.epsilon.
2. Instead of parseFloat(value).toFixed(14) I think we can use roundNumber itself.
3. I think we should use a value based on config.epsilon instead of 14, does that make sense?
4. I think we also need the BigNumber implementation in function round to use a nearly equal comparision.

[BrianFugate]

Thank you @josdejong for the detailed feedback!

1. In this case, I think we should implement a solution in the high level function round, not in the low level function roundNumber, since the latter doesn't have access to config.epsilon. Can you move the implementation and tests to round.js? You can look up equalScalar.js to see how to use config.epsilon.

My first solution for this bug was actually in the high level function round. However, after I realized that the bug also affected round((0.145*100), 0), and tried unsuccessfully to correct that version of the bug, I changed gears and moved to the low level function. I will have to spend some time figuring out how your runtime type-checking and dependency injection work because my working bug fix for number: just threw errors when I put the same logic in for 'number, number': when I ran the test in Mocha.

2. Instead of parseFloat(value).toFixed(14) I think we can use roundNumber itself.
3. I think we should use a value based on config.epsilon instead of 14, does that make sense?
4. I think we also need the BigNumber implementation in function round to use a nearly equal comparision.

I will get to work on these revisions today. Thanks again!

[BrianFugate]

I believe I implemented the changes you requested to this bug fix, @josdejong. Let me know if you want me to adjust anything else.

Thanks!

[josdejong]

Thanks for the updates, this looks good! I made a few inline remarks, can you have a look at those?

[BrianFugate]

I fixed the missing argument in the two regular number functions. I also converted the if...else statements to use the ternary operators as you suggested, and I feel it does make the code look much cleaner.

You also asked for unit tests to verify an edge case where a number rounded to the precision of epsilon is not nearly equal to the original number. I spent more time trying to come up with an input that could make that happen than I did making the revisions to the code, but I could not come up with anything. Admittedly, I am not a mathematician (I even had to google the spelling of mathematician, lol) I am just an aspiring software developer pretending to be good at math to work on your software. 😉 But here is the logic as I understand it:

Rounding a number to the precision of an epsilon value can not change the number by more than half of the epsilon, which using our default epsilon of 1e-12 would be 5e-13. I ran a bunch of tests while watching the values calculated in nearlyEqual and the relative error that our difference is compared to was usually in the range of xe-11 as shown here using the original value from the bug report:

$ node roundtesting.js

config.epsilon 1e-12
epsilonExponent 12
x 14.499999999999998
xEpsilon 14.5

nearlyEqual relative error 1.45e-11
nearlyEqual return true

round(0.145 * 100) returns 15

If you know of an edge case, or can steer me in the right direction to figure one out, I'd be happy to add some lines to the test file for this. Otherwise, I'm content knowing that we should never actually get a false value returned from the nearlyEqual function call.

Let me know what you think, I welcome any advice you have good or bad.

Thanks!

[josdejong]

I am just an aspiring software developer pretending to be good at math

😂 I appreciate your work, thanks!

You also asked for unit tests to verify an edge case where a number rounded to the precision of epsilon is not nearly equal to the original number.

Thinking about it, it makes sense that we do not reach this second case of the original if/else: first we round x to epsilon digits, and next we check if the difference between the original and the rounded value is less than epsilon, which indeed is always the case. That is quite funny. So I guess we can simplify the code to:

function (x, n) {
  const xEpsilon = roundNumber(x, epsilonExponent)
  return roundNumber(xEpsilon, n)
}

I think that makes sense: the first step gets rid of any round-off errors, and the second step does the rounding to the actually desired precision.

I had one more thought: in case of BigNumber (defaulting to 64 digits), the user will not be able to round to say 20 digits with the default configuration of epsilon: 1e-12, since the 20 will be overwritten with 12. What do you think, should we add a case that calculates the applied epsilon as the max of the configured config.epsilon and the provided n?

[BrianFugate]

I removed the nearlyEqual comparisons and added a dynamic epsilon to the big number logic to cover cases where users asked for numbers to be rounded to a higher precision than epsilon. I then realized that the same thing could occur if a user tries to round a regular number to more than 12 decimals, so I added the dynamic epsilon there as well.

In addition, I added test cases to cover the dynamic epsilon logic and threw in some comments so others will know what the logic is for.

Let me know what you think.

Thanks!

[josdejong]

Thanks for the updates. You're right, we have to respect the n argument too. Thanks for adding all tests. I made a few new inline comments, can you have a look at those?

[BrianFugate]

I cannot find any new inline comments. I can see the old resolved ones if I look at the older commits, but I see no comments on the newest commit.

[josdejong]

You should see them when scrolling up in this very tab "Conversation"

[BrianFugate]

Unfortunately, I do not see them in the 'Conversation' tab either. Did you hit 'Submit' on your review in the 'Code' tab? I believe that will prevent others from seeing your comments.

[josdejong]

That's odd. This is what the current page looks for me, inside the red rectangle are the comments that I mean:

[BrianFugate]

I found this thread at Stack Overflow ealier when I was looking for the missing comments:

https://stackoverflow.com/questions/10248666/how-to-view-line-comments-in-github

Apparently, if the comments show 'pending' on your screen nobody else can see them. The first answer talks about how to resolve them being pending. However, I can see them in your screenshot so I'll get to work on them.

As far as the (n < 15) and (n < 64) comparison, the low level roundNumber function will only round to 15 decimal places so if I add one to n and it is already 15 it will cause an error. I was under the impression that big numbers were limited to 64 decimals and was making a similar verification. What is the max number of decimals for a big number then?

Regarding the new Bignumber and toNumber() logic, that was the only way to make the unit test pass. If I did it any other way it would make other scenarios not work (I believe it was the complex number one). The logic in my head was that the original function was supposed to have a big number type as both the x and the n so I decided to give big number types to the returned function and use it as written (except for the xEplsilon part). This was the original returned funtion:

return x.toDecimalPlaces(n.toNumber())

I can try to find another solution though, if you'd like.

[josdejong]

I clicked "submit review" now, can you see the comments now?

[BrianFugate]

Yes, I can see them now

[BrianFugate]

Well, I have no new commits for you today. In fact, I am leaning towards recommending for you to just reject this pull request and the associated issue all together. I thought rounding to epsilon precision before rounding a number to a whole value was safe mathematically and would handle round off error. I later on thought that if someone wanted to round to a higher precision than epsilon, we could just round to one higher decimal place first, then round to what they requested. However, I have now found an edge case than breaks both of those theories.

If a user wants to round the actual number of 1.4999999999995 (13 decimal places) without specifying a number of decimal places and we round it to epsilon precision first it will round to 2 instead of 1 like it should. This example could also be changed to break any epsilon with a negative 'e' value.

Similarly, if the user wants round(0.0149999999995, 2) they will get 0.02 instead of 0.01. And you can find similar examples that break our logic by moving the decimal place depending on what the user requested.

We cannot use nearly equal to compare the final rounding number or the solution wouldn't fix the example in the example posted in the issue. So, what is worse round off errors or these errors that we would induce with the fix to round off errors?

[josdejong]

Yes, I can see them now

😅 that's good to hear. Sorry, my bad. I didn't see that I was inside a review mode and that the comments where pending.

However, I have now found an edge case than breaks both of those theories.

Hm. Good to think this through. Isn't the thing that you can't fully represent 1.4999999999995 (13 decimal places) when you have selected epsilon to be 12 digits (the default)? That would make sense, right? Similarly, you can't represent a BigNumber with 66 digits when you've configured them to have max 64 digits?

[josdejong]

@BrianFugate I have given this some more thought. As far as I can see though there is not a problem, as long as you recon with the configured epsilon. If you want to support 1.4999999999995 (13 decimal places), you'll have to configure epsilon to be 1e-14 for example, then it will work, right?

[dvd101x]

Hi, just a comment

Configuring epsilon to be 1e-14 to get 13 decimal places isn't assuming that epsilon is the absolute tolerance?

Previously I mistakenly thought that epsilon did not work. My mistake was because I thought it was absolute when currently it's relative.

[josdejong]

@dvd101x ah, you're right. Originally Brian had this construct nearlyEqual(x, roundNumber(x, epsilonExponent), config.epsilon) but I couldn't come up with a case where this would be false. Probably it should because nearlyEqual is using a relative difference. Can you come up with a case where this will return false?

[BrianFugate]

With this latest commit I removed the dynamic epsilon logic and made it just skip the roundoff error correction if the user requests the same or more decimals as config.epsilon has.

I also added a test to the unit test file to verify that our outputs change if epsilon is changed during runtime. Look closely at the values of the assertations so you are sure this is how you want it to operate.

Let me know what you think.

Thanks!

[josdejong]

Thanks for the updates Brian, I think this is exactly what we're looking for. I still want to think it over in the weekend to be sure we're not overlooking anything obvious here 🤔. Do you still have concerns on whether this actually makes sense?

[dvd101x]

@josdejong by trying a shotgun approach of testing:

• epsExp from 1 to 15
• x from 1, 0.1, 0.001 ... to 1e-16
• default value of config epsilon

I found the following cases where the expression nearlyEqual(x, roundNumber(x, epsilonExponent), config.epsilon) yields false

x	epsExp
0.01	1
0.001	1
0.001	2
0.0001	1
0.0001	2
0.0001	3
0.00001	1
0.00001	2
0.00001	3
0.00001	4
0.000001	1
0.000001	2
0.000001	3
0.000001	4
0.000001	5
1e-7	1
1e-7	2
1e-7	3
1e-7	4
1e-7	5
1e-7	6
1e-8	1
1e-8	2
1e-8	3
1e-8	4
1e-8	5
1e-8	6
1e-8	7
1e-9	1
1e-9	2
1e-9	3
1e-9	4
1e-9	5
1e-9	6
1e-9	7
1e-9	8
1e-10	1
1e-10	2
1e-10	3
1e-10	4
1e-10	5
1e-10	6
1e-10	7
1e-10	8
1e-10	9
1e-11	1
1e-11	2
1e-11	3
1e-11	4
1e-11	5
1e-11	6
1e-11	7
1e-11	8
1e-11	9
1e-11	10
1e-12	1
1e-12	2
1e-12	3
1e-12	4
1e-12	5
1e-12	6
1e-12	7
1e-12	8
1e-12	9
1e-12	10
1e-12	11
1e-13	1
1e-13	2
1e-13	3
1e-13	4
1e-13	5
1e-13	6
1e-13	7
1e-13	8
1e-13	9
1e-13	10
1e-13	11
1e-13	12
1e-14	1
1e-14	2
1e-14	3
1e-14	4
1e-14	5
1e-14	6
1e-14	7
1e-14	8
1e-14	9
1e-14	10
1e-14	11
1e-14	12
1e-14	13
1e-15	1
1e-15	2
1e-15	3
1e-15	4
1e-15	5
1e-15	6
1e-15	7
1e-15	8
1e-15	9
1e-15	10
1e-15	11
1e-15	12
1e-15	13
1e-15	14

[josdejong]

Thanks @dvd101x, this helps a lot.

So, we need to test (a couple of) these cases to see whether the current implementation of this PR gives the right results. If not, I think we have to re-introduce the initial approach of @BrianFugate with nearlyEqual(x, roundNumber(x, epsilonExponent), config.epsilon) instead of just a two-stage roundNumber.

[BrianFugate]

I reintroduced the nearlyEqual comparison and immediately realized that my test case for changing epsilon at runtime was also a false case in the nearlyEqual comparison. In addition, I added a test using bignumbers to the same changing epsilon test and it also is a false in with nearly equal.

I feel confident in this now finally, thank you @dvd101x for helping get me back on track!

Thanks!

[josdejong]

@BrianFugate @dvd101x can you come up with a unit test for each of the four function signatures that fails when we remove the nearlyEqual part from the code? It makes sense to add the nearlyEqual step, but if it makes sense, there should be a case to prove it 🤔. Right now, when I remove the nearlyEqual part, only one BigNumber test fails.

EDIT: sorry, I see that both number and BigNumber implementations of round(x, n) have a failing test without the nearlyEqual part. So only for the round(x) implementations there is no test that fails without the nearlyEqual section.

[BrianFugate]

I do not think there is a case where we can make round(x) fail the nearly equal test and here are my reasons:

1. The smallest number that can be flipped to round up to 1 is 0.45 if rounded to 1 decimal first (i.e. 1e-1 epsilon)
2. According to @dvd101x 's shotgun test, with a 1e-1 epsilon, 0.1 passes the nearlyEqual test and 0.01 fails it. Regardless of where the actual breakover point is between those two numbers we will always round down to 0 regardless of the nearlyEquals result.
3. Using 1e0 for our epsilon is the same as removing our two stage rounding process, because we will just round to 0 decimal places twice.

Unless there are plans to make the low level function roundNumber accept negative decimals (maybe for rounding to the tens or hundreds) or decimal.js doing the same for .toDecimals, or you are planning on changing how nearlyEqual uses epsilon in @dvd101x 's pull request #3152, then I do not think the nearlyEqual verification is necessary for round(x). Do you want me to remove it or leave it in place just in case something else changes in the future?

[josdejong]

I think indeed that we could remove the nearlyEqual check in the round(x) signatures. We can go both ways. Your reasoning about possible future changes is a good one though. Keeping the logic the same ensures that there cannot be subtle edge-cases where the behavior differs. Also, it is easier to understand the code of round when it has 4x the exact same logic rather than two different implementations.

OK then, let's leave it as it is right now, with 4x the same implementation, OK?

[BrianFugate]

Sounds good to me!

[josdejong]

OK merging your PR now.

Brian, thanks a lot for your patience and for thinking along. This was trickier than I had expected.

[josdejong]

Published now in v12.4.0, thanks again!