Solving round number in JS by using String

Question

Whatever language you choose, you may encounter a rounding problem. In fact, this is due to the limit of the required number of bits needed to get the right number after a calculation.

Simple example:

In javascript (like any other language), you may want to use a function to round the result after even a simple sum (with decimals) :

Unfortunately it's not always working as we expect.

That's why I created my own function which is based on a string version. I read every char and make the round by myself so I'm not limited by the number of bits.

round(number, decimalsLength) {

// If the number does contains a scientific notation, we use a more traditionnal calculation method
if(number.toString().includes("e"))
    number = parseFloat(number.toFixed(4));

// Split the integer part and the decimal part
var number = (typeof number === "number") ? number : (number != null) ? parseFloat(number) : 0; // Return NaN for [null; {}]
var decimalsLength = decimalsLength || 0;
var array = (number+"").split(".");
var left = array[0];
var right = "1"+(array[1] || 0); // We add 1 to keep the left 0

// Round only if we have more decimal than needed
if(right.length-1 >= decimalsLength) {

    // Round up
    if(parseInt(right.substr(decimalsLength+1, 1)) >= 5)
        right = parseInt(right.substr(0, decimalsLength+1))+1;

    // If we moved to the upper integer
    if(right.toString().substr(0, 1) == 2) { // If the added 1 has became a 2
        var noDecimal = parseInt(right.toString().substr(1, decimalsLength)) == 0; // Return an integer if we no longer have any decimal
        left = (parseInt(left) + (number > 0 ? 1 : -1)).toString();
        return parseFloat(left + (noDecimal ?"":".") + (noDecimal?"":right.toString().substr(1, decimalsLength)));
    }
}

// Else, we don't need to round
var noDecimal = parseInt(right.toString().substr(1, decimalsLength)) == 0;
return parseFloat(left + (noDecimal?"":".") + (noDecimal?"":right.toString().substr(1, decimalsLength)));

}

I wanted to share this with you in case it can help, but also to have a feedback and improve the function if you find it useful.

Answer 1

document the return value

round(number, decimalsLength) {

The name suggests something similar to this documented function:

Math.round()

The Math.round() static method returns the value of a number rounded to the nearest integer.

That's a crystal clear guarantee about the return value.

Your function offers no assurances at all about what's returned.

---

document the input value

var number = (typeof number === "number") ? number : (number != null) ? parseFloat(number) : 0; // Return NaN for [null; {}]

Your round() is a total function. Silently accepting any and all types for what ostensibly should be a number, and mapping a subset of them to 0, sounds disastrous for the caller.

Much better to insist on one-or-more input types, perhaps FP and string, and throw a fatal error if caller messed up by passing in some random object.

---

be direct

var right = "1"+(array[1] || 0); // We add 1 to keep the left 0

Hacks such as this do not lead to maintainable code.

Say what you mean and mean what you say. Starting with "234.567" and then assigning right = "1567" tells the reader that right does not mean "the digits to the right of the decimal point". We're left with the identifier not having a clear meaning. Break this out as a well-named helper if there's a transform you need.

---

solve a general problem

if(right.length-1 >= decimalsLength) {
    ...
    if(parseInt(right.substr(decimalsLength+1, 1)) >= 5)
        right = ... [an integer expression, definitely not a string] ...

    if(right.toString().substr(0, 1) == 2) { 
        ...
        return ...
    }
}
...
return ... [expression which involves 'right'] ...

Wow, that's a lot of special cases.

First, extract helper, which would give you an opportunity to name and to document that you're transforming from this to that. Plus you could separately unit test the helpers.

Second, consider using FP arithmetic to solve this problem. Your chief complaint seems to be that FP quantities describe intervals on the real number line, and some are "a bit off", a bit negative. You give the example of 10.395, which encodes an interval that contains 10.395, but which starts at 10.394999...99905, leading to unfortunate truncated string results. For restricted input ranges, which you'd need to document, you might be able to get away with always adding epsilon = 1e-12 to the input number, and then rounding, obviating the need for many ifs.

Obtaining 100% code coverage via unit tests would pose some slight challenge, given the current code.

---

scaled integer

No app-level motivating use case was offered in the original submission.

It is possible that an app which cares about rounding details of a very large set of FPs which includes 10.395 may want a different approach. Let's focus on the "two decimal places" case.

Consider advising app developers to work with integer number of cents, rather than FP decimal number of dollars. Format with two decimal places upon display. For FP operations on a restricted range of integers, conservatively the natural numbers less than a trillion, FP calculations are always exact. Fifty-three bits of significand is a lot of bits to represent exact integer quantities.

---

As a consumer of this code, I would not want to call into it, as it is unclear what value it might return.

As a QA tester, I would not want to be tasked with obtaining 100% code coverage. (The OP, alas, did not include any automated testing.)

As a maintenance engineer on the team responsible for this library routine, I would not be able to confidently add features or fix bugs, as the current contract is unclear. Recommend revising this code before attempting to merge it down to main.

Answer 2

Questionable goal

Code suffers from/abuses double rounding.

Javascript numbers use binary64 encoding. That provides about 10¹⁹ different values.
10.395 is not one of them as it is not a dyadic rational, an integer times a power of 2.

In the vicinity of 10.395 are encodable values:
10.394999999999999573674358543939888477325439453125
10.3950000000000013500311979441903531551361083984375

As a string "10.395" converted to a number, it is convert to the closer, yet lesser one.

With OP's code, both of these return a value near 10.40.

So if number is a string like "10.395", 10.40 is a good result. Yet if number is a number prints like 10.395, it really is 10.394999... and 10.39 is a good result.