We Keep Coding

Subtracting 2 decimal numbers javascript

Hi im trying to subtract 2 decimal numbers and it keeps returning some weird number.
var x = 0.00085022
var y = 0.00085050
var answer = x - y
alert(answer)
This is the number its returning -2.8000000000007186e-7

The maximum number of decimals is 17, but floating point arithmetic is not always 100% accurate
http://www.w3schools.com/js/js_numbers.asp
Try this:
var x = 0.00085022 * 100000000;
var y = 0.00085050 * 100000000;
var answer = (x - y) / 100000000;
alert(answer);

You are subtracting with a higher number and the calculations are traversing to an even lower number. Yes -2.0 is lower and the decimal places precision is reaching exponentially higher.
If we round them up we get:
var x = 85022
var y = 85050
var answer = x - y
alert(answer); // = -28

How do I avoid or work around the floor function and incorrectly represented integers?

So I am trying to take a number that can be in any positive form and cut it to two decimal places. So for example I have an input of 145.26. However in my code this is being rounded down to 145.19. Here is the code I am using:
var multiplier = 100;
var adjustedNum = input * multiplier;
var truncatedNum = Math[adjustedNum < 0 ? 'ceil' : 'floor'](adjustedNum);
var fixedResult = truncatedNum / multiplier;
So basically my 'input' should become 145200. However it is actually becoming 145199.9999995 or something to that effect. This is causing the Math.floor method to round it down. Is there any way to workaround or avoid this?

Multiply the number by an additional factor of 10 to round it. Then divide it by 10 to apply the floor or ceil.
var multiplier = 100;
var adjustedNum = Math.round(input * multiplier * 10);
var truncatedNum = Math[adjustedNum < 0 ? 'ceil' : 'floor'](adjustedNum/10);
var fixedResult = truncatedNum / multiplier;

As one variable decreases another one increases

I have the following math problem inside JavaScript.
The problem: As x decreases, I need y to decrease proportionately to x as y approaches 0%.
And so when x = 0%, y = 0%.
<script type="text/javascript">
x = 0.50;
y = 0.30;
if (x < 0.50){
// set y here somehow to gradually increase
}
</script>

Change in y would be 0.6 times the change in x (assuming you want y to decrease linearly from 0.3 to 0.0 as x decreases from 0.5 to 0.0):
if (x < 0.50)
{
y = 0.3 - 0.6*x;
}

Quadratic function for increment speedup of countup

I'm writing a jQuery plugin for fast-counting up to a value when a page loads. Since javascript can't run as fast as I want it to for larger numbers, I want to increase the increment step so that it completes within a given timeframe, so I'd need a quadratic function that passes through origo and has it's turning point at y = target counting value and x = target duration, but I can't get a grip on the math for doing this. Since both the number and the duration can change, I need to be able to calculate it in javascript aswell.
Hopefully someone can help me with this one!

Let's formalize the statement a bit.
We seek an equation of the form
y = a*x*x + b*x + c
where x is the time axis and y is a count axis. We know that one point on the curve is (0,0) and another point is (xf, yf) where xf is the final time and yf is the target count. Further, you wish for the derivative of this equation to be zero at (xf, yf).
y' = 2*a*x + b
So I have three equations and three unknowns:
(0,0) => 0 = c
(xf, yf) => yf = a*xf*xf + b*xf + c
y' = 0 # (xf, yf) => 0 = 2*a*xf + b
You should be able to solve it from there.

// Create a quadratic function that passes through origo and has a given extremum.
// x and y are the coordinates for the extremum.
// Returns a function that takes a number and returns a number.
var quadratic = function (x, y) {
var a = - (y / (x * x));
var b = (2 * y) / x;
return function (x) {
return a * x * x + b * x;
};
};

Javascript: Precision strange behavior [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is JavaScript's Math broken?
Suppose,
var x = .6 - .5;
var y = 10.2 – 10.1;
var z = .2 - .1;
Comparison result
x == y; // false
x == .1; // false
y == .1; // false
but
z == .1; // true
Why Javascript show such behavior?

Because floating point is not perfectly precise. You can end up with slight differences.
(Side note: I think you meant var x = .6 - .5; Otherwise, you're comparing -0.1 with 0.1.)
JavaScript uses IEEE-754 double-precision 64-bit floating point (ref). This is an extremely good approximation of floating point numbers, but there is no perfect way to represent all floating point numbers in binary.
Some discrepancies are easier to see than others. For instance:
console.log(0.1 + 0.2); // "0.30000000000000004"
There are some JavaScript libraries out there that do the "decimal" thing a'la C#'s decimal type or Java's BigDecimal. That's where the number is actually stored as a series of decimal digits. But they're not a panacea, they just have a different class of problems (try to represent 1 / 3 accurately with it, for instance). "Decimal" types/libraries are fantastic for financial applications, because we're used to dealing with the style of rounding required in financial stuff, but there is the cost that they tend to be slower than IEEE floating point.
Let's output your x and y values:
var x = .6 - .5;
console.log(x); // "0.09999999999999998"
var y = 10.2 - 10.1;
console.log(y); // "0.09999999999999964"
No great surprise that 0.09999999999999998 is != to 0.09999999999999964. :-)
You can rationalize those a bit to make the comparison work:
function roundTwoPlaces(num) {
return Math.round(num * 100) / 100;
}
var x = roundTwoPlaces(0.6 - 0.5);
var y = roundTwoPlaces(10.2 - 10.1);
console.log(x); // "0.1"
console.log(y); // "0.1"
console.log(x === y); // "true"
Or a more generalized solution:
function round(num, places) {
var mult = Math.pow(10, places);
return Math.round(num * mult) / mult;
}
Live example | source
Note that it's still possible for accuracy crud to be in the resulting number, but at least two numbers that are very, very, very close to each other, if run through round with the same number of places, should end up being the same number (even if that number isn't perfectly accurate).