Strange math with rounding and multiplying - javascript

I have an odd problem. I'm grabbing numbers from the web audio API, what I get out is a constant list of:
3.1051260268969075e-28 etc etc
I want to round that figure, but using:
Math.round(magAmount);
Always returns 0. magAmount is the variable I store the number in. Another odd thing, if I multiply the number by 5 I get a value lower than the original, in this case 1.5525630134484537e-27.
Any ideas?
Thanks.

That number is 5 times bigger.
e-28 is smaller than e-27

Note that e-28 is *10^-28, so there's nothing strange in your code.
And since this number is tiny, rounding it will certainly returns a 0.

Math.round() will round to the next integer, so rounding 0.0000000000..00001 (which you are doing) will round to 0.
also e-27 is bigger than e-28, so your multiply is correct

Round to what precision? If you want
3.1051260268969075e-28 -> 3.1e-28 then
Math.round(3.1051260268969075e-28 * 1.0e+29) * 1.0e-29

Related

Rounding up or down when 0.5

I am having an issue with the way Javascript is rounding numbers when hitting 0.5.
I am writing levies calculators, and am noticing a 0.1c discrepancy in the results.
The problem is that the result for them is 21480.705 which my application translates into 21480.71, whereas the tariff says 21480.70.
This is what I am seeing with Javascript:
(21480.105).toFixed(2)
"21480.10"
(21480.205).toFixed(2)
"21480.21"
(21480.305).toFixed(2)
"21480.31"
(21480.405).toFixed(2)
"21480.40"
(21480.505).toFixed(2)
"21480.51"
(21480.605).toFixed(2)
"21480.60"
(21480.705).toFixed(2)
"21480.71"
(21480.805).toFixed(2)
"21480.81"
(21480.905).toFixed(2)
"21480.90"
Questions:
What the hell is going on with this erratic rouding?
What's the quickest easiest way to get a "rounded up" result (when hitting 0.5)?
So as some of the others already explained the reason for the 'erratic' rounding is a floating point precision problem. You can investigate this by using the toExponential() method of a JavaScript number.
(21480.905).toExponential(20)
#>"2.14809049999999988358e+4"
(21480.805).toExponential(20)
#>"2.14808050000000002910e+4"
As you can see here 21480.905, gets a double representation that is slightly smaller than 21480.905, while 21480.805 gets a double representation slightly larger than the original value. Since the toFixed() method works with the double representation and has no idea of your original intended value, it does all it can and should do with the information it has.
One way to work around this, is to shift the decimal point to the number of decimals you require by multiplication, then use the standard Math.round(), then shift the decimal point back again, either by division or multiplication by the inverse. Then finally we call toFixed() method to make sure the output value gets correctly zero-padded.
var x1 = 21480.905;
var x2 = -21480.705;
function round_up(x,nd)
{
var rup=Math.pow(10,nd);
var rdwn=Math.pow(10,-nd); // Or you can just use 1/rup
return (Math.round(x*rup)*rdwn).toFixed(nd)
}
function round_down(x,nd)
{
var rup=Math.pow(10,nd);
var rdwn=Math.pow(10,-nd);
return (Math.round(x*-rup)*-rdwn).toFixed(nd)
}
function round_tozero(x,nd)
{
return x>0?round_down(x,nd):round_up(x,nd)
}
console.log(x1,'up',round_up(x1,2));
console.log(x1,'down',round_down(x1,2));
console.log(x1,'to0',round_tozero(x1,2));
console.log(x2,'up',round_up(x2,2));
console.log(x2,'down',round_down(x2,2));
console.log(x2,'to0',round_tozero(x2,2));
Finally:
Encountering a problem like this is usually a good time to sit down and have a long think about wether you are actually using the correct data type for your problem. Since floating point errors can accumulate with iterative calculation, and since people are sometimes strangely sensitive with regards to money magically disappearing/appearing in the CPU, maybe you would be better off keeping monetary counters in integer 'cents' (or some other well thought out structure) rather than floating point 'dollar'.
The why -
You may have heard that in some languages, such as JavaScript, numbers with a fractional part are calling floating-point numbers, and floating-point numbers are about dealing with approximations of numeric operations. Not exact calculations, approximations. Because how exactly would you expect to compute and store 1/3 or square root of 2, with exact calculations?
If you had not, then now you've heard of it.
That means that when you type in the number literal 21480.105, the actual value that ends up stored in computer memory is not actually 21480.105, but an approximation of it. The value closest to 21480.105 that can be represented as a floating-point number.
And since this value is not exactly 21480.105, that means it is either slightly more than that, or slightly less than that. More will be rounded up, and less will be rounded down, as expected.
The solution -
Your problem comes from approximations, that it seems you cannot afford. The solution is to work with exact numbers, not approximate.
Use whole numbers. Those are exact. Add in a fractional dot when you convert your numbers to string.
This works in most cases. (See note below.)
The rounding problem can be avoided by using numbers represented in
exponential notation:
function round(value, decimals) {
return Number(Math.round(value+'e'+decimals)+'e-'+decimals);
}
console.log(round(21480.105, 2).toFixed(2));
Found at http://www.jacklmoore.com/notes/rounding-in-javascript/
NOTE: As pointed out by Mark Dickinson, this is not a general solution because it returns NaN in certain cases, such as round(0.0000001, 2) and with large inputs.
Edits to make this more robust are welcome.
You could round to an Integer, then shift in a comma while displaying:
function round(n, digits = 2) {
// rounding to an integer is accurate in more cases, shift left by "digits" to get the number of digits behind the comma
const str = "" + Math.round(n * 10 ** digits);
return str
.padStart(digits + 1, "0") // ensure there are enough digits, 0 -> 000 -> 0.00
.slice(0, -digits) + "." + str.slice(-digits); // add a comma at "digits" counted from the end
}
What the hell is going on with this erratic rouding?
Please reference the cautionary Mozilla Doc, which identifies the cause for these discrepancies. "Floating point numbers cannot represent all decimals precisely in binary which can lead to unexpected results..."
Also, please reference Is floating point math broken? (Thank you Robby Cornelissen for the reference)
What's the quickest easiest way to get a "rounded up" result (when hitting 0.5)?
Use a JS library like accounting.js to round, format, and present currency.
For example...
function roundToNearestCent(rawValue) {
return accounting.toFixed(rawValue, 2);
}
const roundedValue = roundToNearestCent(21480.105);
console.log(roundedValue);
<script src="https://combinatronics.com/openexchangerates/accounting.js/master/accounting.js"></script>
Also, consider checking out BigDecimal in JavaScript.
Hope that helps!

How to ensure integer division gives out correct results?

I am aware of the fact that floating point calculation is likely to be inaccurate. For example:
var x = 100*0.333;
Here x gets set to 33.300000000000004 rather than 33. This might seem to be a minor problem, but it becomes serious if rounding is involved. For example, Math.ceil(x) will be incorrect - will yield 34 rather than 33.
The problem is that I was told that JS doesn't make much difference between integers and floating points. So I'm becoming worried if there's any way to ensure that integral division is correct.
The usual formula for integer division in JS seems to be Math.floor(n/m), where n, m are integers. So now let's say that m divides n evenly. Since JS treats every number as if it was a floating point number, n/m will return a floating point number. If this floating point number is not exact, but is even a very little bit smaller than the actual calculation result, then Math.floor(n/m) will get rounded down to one integer below it should.
To illustrate: if, for example, 9/3 yields 2.999999999999999 rather than 3, then Math.floor(9/3) will incorrectly yield 2 rather than 3. Well, actually, Math.floor(9/3) does give out correct results, but this is of course only an example; substitute 9 and 3 with any unfortunate choice of integers.
Can such scenario ever happen? If so, is there any way to ensure correct results?
Can such scenario ever happen?
No. If they are integers (i.e. floating numbers with no fractional part) and evenly divide, then the result will be exact and an integer again.
If the don't evenly divide, the result will always be greater than the exact result from integer division. You'll never get a 2.9999999… number that was supposed to be a 3. The floating point results are as precise as representable, rounding does not destroy the total preorder.
if you want an exact integral division result. Then do this
Math.round((m - m%n)/n)
If the value of dividing two numbers is supposed to be 3 then it will be. If the value is supposed to be 2.999999999999, it will be. Java doesn't do some kind of strange hidden rounding, up or down. If you ALWAYS need to have the value round down then Use Floor(x/y) Even if the value is 2.99999999999999999999999999999999999 it will still come back as 2. That's what Floor does. Same thing with celling. if the value is 3.0000000000000000000001 then it will be set to 4. I teach this in college, this is how it's supposed to and does work.

parseInt changes the integer

I am trying to pull a number (72157648141531978), which starts at the 21st character, out of the title of a page like so:
parseInt(document.title.substring(21), 10);
This returns the string as an integer of 72157648141531980. I can't seem to figure out why it is changing the last two numbers. Any help would be appreciated.
According to What is JavaScript's highest integer value that a Number can go to without losing precision? the max value of an integer is 9007199254740992.
I tried your calculation on http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_parseint and I can confirm your problem.
It looks like an issue parsing beyond this max value and it is rounding the last 2 figures.
You have exceeded the limits of double-precision floating-point format, as used by JavaScript. You cannot use that precise number directly in JavaScript. You can use it as a string, but if you need to do arithmetic on it you will need a bignum library.

Better way of rounding off or rounding up in javascript

I have this problem with rounding up or rounding off with javascript. Well it gets the job done but there are some scenarios that it fails to do the job properly.
For example.
The price is 0.30 with a 15% discount should have 0.255 or 0.26 as result. (this is somehow okay)
The price is 79.99 with a 50% discount should have 40 as result. (actual result is 39.995)
Tried using this as reference Using toFixed(2) and math round to get correct rounding
also did this process Math.round(value*Math.pow(10,dec))/Math.pow(10,dec);
Any ideas?
Thanks
This is my initial test. Though this is just an initial test what I did is checked if the last two digits is greater than 5 then apply Math.ceil that would to the 0.255 to be 0.26 but when using 39.99 the result would still be 39.99 though 39.99 should use Math.round so that the result would be 40.
What I would like to accomplish is to be able to round up or round down any number if it needs rounding up or if it needs rounding up.
UPDATE
I was able to solve my own problem. (Atleast to my specific environment)
http://jsfiddle.net/xMj3M/4/
This is because of how floats are handled. I would suggest having your original numbers in integers only, so you would start with 7999. If you use this method, you will get the correct result.
In general, especially when dealing with money, it is always a good idea to work in pennies first, and then output it in the format of the currency.
You could try:
var someNumber = 36.7327;
var someNumberRoundedTo2Decimals = (Math.round((someNumber * 100)) / 100);
// = 36.73
basically this moves the decimal to the right 2 digits..
3673.27
then rounds it off to an int
3673
then moves the decimal back to the left 2 places
36.73

round in javascript stuck me

hello I want to round an amount in javascript but unable to do and totally stuck.
My scenario is, I have a base amount and marukup % on base. On the basis of these two I want to calculate total amount. I have calculated the amount but i want to round the result.
I have used following formula
amount=base+((base/100)*markup
This formula always give me result without decimal point. I want to get exact amount upto two decimal points. I have used math.round like this
amount=math.round(base+((base/100)*markup).toFixed(2)
but it always return result without decimal point. For example my base value is 121 and markup is 5%. The amount should be 127.05 . But above formula always returns 127. Any guidelines?
I'm pretty sure math.round returns an integer. Even if you round it then, it'll just be 127.00 anyway.
Here's the correct solution(but it isn't easy):
Do not use non-integer values for money!
It doesn't work.
Use an integer in cents.
That is, instead of 127, keep 12700 in your app.
That way all roundings should work fine.
The toFixed(n) function rounds the Number to n decimals, there is no need to use Math.round at all. Try:
total = function (base, markup) { return (base + (base * markup / 100)); };
amount = total(121,5).toFixed(2);
Note that amount will be typeof String and not Number.
This should work:
amout = (Math.round((base*(1+markup))*100)/100).toFixed(2)
By the way, i was using markup as 5/100...
Sound like a integer division problem to me. I'd guess that javascript is seeing the 100 as an int.
Try this:
amount=(base+((base/100.toFixed(2))*markup).toFixed(2)

Categories