Writing some test cases for my Javascript program that deals with binary and right now I'm just using stringify to check if the value and expected values are equal:
JSON.stringify(val) === JSON.stringify(expected)
This works fine except for when I have floating point values. This is what happens:
Given Value: [10,20,30,32.400001525878906,{"test":3,"asdf":23}]
Expected Value: [10,20,30,32.4,{"test":3,"asdf":23}]
Test Failed!
So I guess I can't use stringify anymore to check if my two objects/arrays are equal. What's a good way to check if two potentially deeply nested objects/arrays are equal while also taking in to account floating point values? That is, two floating point values should be considered equal if they are 99.99% the same or whatever.
You'll need to test each element in the array in order, and you'll need to do it recursively for objects. This is typically known as a deep comparison or deep equality. You should be able to do this using a recursive function that checks the type(s) of the comparands.
When comparing floating point values, you'll want to use a tolerance. You do this by taking the absolute value of subtracting the two numbers from each other, and then comparing that to either a fixed tolerance value of your choosing, or a small number known as an epsilon.
In JavaScript, the machine epsilon is available as Number.EPSILON, and is defined to be the difference between 1 and the smallest number that is greater than 1 and can be represented as a Number. Similar constants are available in most languages and are typically used for tolerance-based comparisons.
Tolerance-based comparison turns floating point comparisons from simple equality into a subtract and compare. If you'd normally write
if (a === b) { ... }
you'd write that using the absolute value and a tolerance to eliminate floating point weirdness:
var tolerance = Number.EPSILON;
if (Math.abs(a - b) < tolerance) { ... }
If the difference between a and b is smaller than tolerance, you treat them as equal.
For a more nuanced (but possibly overkill for your case) approach, see The Floating Point Guide's section on comparison. The implementation presented there is in Java, but is likely portable to JavaScript without much effort.
Related
Since in Javascript all the numbers are double precision float is just a matter of he memory representation or numerical operation are as well all the same?
E.g. regarding computation complexity
15 / 3
14 / 3
would these operation cost the same computational resources or would v8 optimize integer devision case?
(V8 developer here.)
Short answer: It's complicated! And (as axiac points out) also not worth worrying about.
Long answer:
First off, when you have a division of number literals like 15 / 3 in your source, then V8 will constant-fold that at parsing time, so the division will only be performed once, and it doesn't really matter whether it's optimized in any way or not. For example, if you write function f() { return 15/3; }, then that will get compiled to function f() { return 5; }.
The next important observation is that the only way to tell whether a division will have an integer result is to actually perform the division and look at the result. Concretely, if an engine wanted to have something like:
function implementation_of_/_operator(x, y) {
if (division_result_will_be_integer(x, y)) {
return integer_division(x, y);
else {
return floating_point_division(x, y);
}
}
then it would have to implement division_result_will_be_integer somehow, for which there are two options:
function division_result_will_be_integer(x, y) {
if (!is_integer(x) || !is_integer(y)) return false;
return is_integer(floating_point_division(x, y));
}
// or:
function division_result_will_be_integer(x, y) {
if (!is_integer(x) || !is_integer(y)) return false;
(quotient, remainder) = integer_division_with_remainder(x, y);
return remainder == 0;
}
Clearly, performing a division just to decide which additional division to perform afterwards is silly, and it would be faster to skip that whole dance and just always do a floating-point division directly.
The third relevant point is that the hardware instruction for integer division can be quite slow. In particular, for large dividends and small divisors, it tends to be slower than floating-point division instructions. So what your question assumes to be an "optimization" may well reduce performance in practice.
Regardless of integer or floating-point domain, divisions are always fairly expensive operations. In case both operands are integers, divisions can be replaced by multiplications with the "multiplicative inverse" of the divisor. Finding this multiplicative inverse again involves a division though, so this technique only improves performance if you expect to perform many divisions with the same divisor -- such as when the divisor is a constant, e.g. f(x) { return x / 3; }. Also, operating on integers means that only integer results can be represented; if someone called f(14) in this example, then the multiplication-by-inverse technique would produce an incorrect result.
V8 uses this approach in optimized code if (1) the divisor is a constant and (2) at the time of optimizing the given function, all results it's previously seen produced at this particular division were integers. Such optimized code must then still contain a check to verify that all future results are also integers, i.e. it must check that division_result * dividend === divisor, and otherwise bail out to a floating-point division.
Lastly, there's the somewhat special handling of asm.js-style code. If you write f(x, y) { return ((x | 0) / (y | 0) | 0); }, then V8 will use an integer division instruction in that function. Obviously, the |0 operations mean that this function truncates both inputs and its result to 32-bit integers, which may or may not be acceptable for your use cases. Whether this will be faster or slower than a plain simple worry-free function f(x, y) { return x / y; } also depends on your use cases.
The following code simply creates an array and sort it. It is very strange that on my 2013 Macbook Pro, it took 5.8 seconds to sort the 30-bit numbers:
n = 10000000;
numMax = 1000000000;
console.log(`numMax is how many bits: ${Math.ceil(Math.log(numMax) / Math.log(2))}`)
console.log("\n## Now creating array");
let start = Date.now();
let arr = new Array(n);
for (let i = 0; i < arr.length; ++i)
arr[i] = Math.floor(Math.random() * numMax);
console.log(`took ${(Date.now() - start)/ 1000} seconds to create the array`);
console.log("\n## Now sorting it");
start = Date.now();
arr.sort((a, b) => a - b);
console.log(`took ${(Date.now() - start)/ 1000} seconds to sort`);
But let's say we make it 34-bit numbers. Now it takes 12.7 seconds to run:
n = 10000000;
numMax = 10000000000;
console.log(`numMax is how many bits: ${Math.ceil(Math.log(numMax) / Math.log(2))}`)
console.log("\n## Now creating array");
let start = Date.now();
let arr = new Array(n);
for (let i = 0; i < arr.length; ++i)
arr[i] = Math.floor(Math.random() * numMax);
console.log(`took ${(Date.now() - start)/ 1000} seconds to create the array`);
console.log("\n## Now sorting it");
start = Date.now();
arr.sort((a, b) => a - b);
console.log(`took ${(Date.now() - start)/ 1000} seconds to sort`);
On NodeJS (update: I am using v12.14.0), the difference is even more: 5.05 seconds vs 28.9 seconds. Why is the difference so big? If it is due to Chrome or NodeJS able to optimize it by using 32-bit integers, vs using 64-bit integers, or IEEE 754 Numbers, would it take exactly one clock cycle to do the compare during the sort (and moving the data during the "partition phase" of Quicksort)? Why would it take more than 2 times or even 5 times the time to do it? Does it also have something to do with fitting all data in the internal cache of the processor and whether the internal cache can support 32 bit but not IEEE 754 numbers?
V8 developer here. In short: this is why V8 uses "Smis" (small integers) internally when it can.
In JavaScript, any value can generally be anything, so engines typically represent values in some format that stores type information along with the value itself. This includes numbers; so a number on the heap is an object with two fields: a type descriptor, and the actual number value, which is an IEEE-754 64-bit double value per JavaScript spec. Since small-ish, integer-valued numbers are particularly common, V8 uses a special trick to encode them more efficiently: they're not stored as an object on the heap at all, instead the value is directly encoded into the "pointer", and one of the pointer's bits is used to tag it as a so-called Smi. In all current versions of Chrome, V8 uses 32-bit heap pointers, which leaves 31 bits for the payload of a Smi. Since arrays of numbers are also fairly common, storing a type descriptor for each element is fairly wasteful; instead V8 has double arrays, where the array itself remembers the fact (only once!) that all its elements are doubles; those elements can then be stored directly in the array.
So in the 30-bit version of your code, the array's backing store is an array full of Smis, and calling the comparator function can pass two of those directly. That function, in turn, can quickly Smi-check and untag the values to perform the subtraction.
In the 34-bit version, the array's backing store stores doubles. Every time the comparator needs to be called, two raw doubles are read from the array, are boxed as "heap numbers" in order to be used as parameters for the function call, and the comparator function has to read the value from the heap before being able to subtract them. I'm actually surprised that this is only about twice as slow :-)
To play with the performance details of this testcase a bit, you can force the array to store heap numbers instead of unboxed doubles. While that consumes more memory up front and has a performance cost for many use cases, in this particular case it actually saves about 10% of the time, since less short-lived garbage is allocated during execution. If you additionally force the comparator's result to be returned as a Smi:
arr.sort((a, b) => a > b ? 1 : a < b ? -1 : 0);
it saves another 10%.
On NodeJS, the difference is even more: 5.05 seconds vs 28.9 seconds.
With Node 13.11 I can't reproduce that; I'm getting almost exactly the same numbers as with Chrome 81.
Chrome or NodeJS able to optimize it by using 32-bit integers, vs using 64-bit integers, or IEEE 754 Numbers
Being able to use 32-bit integer CPU instructions is a side effect of using the Smi representation, but it's not the (primary) cause of the performance difference here. Using 64-bit integers internally would be a violation of the JavaScript spec (unless the engine were very careful to detect and avoid results that are too precise).
would it take exactly one clock cycle to do the compare
Estimating clock cycles on modern CPUs is very difficult, and almost nothing is as simple as "exactly one clock cycle". On the one hand, CPUs can execute (parts of) more than one instruction per cycle, on the other hand they have pipelines, which means that finishing the execution of just one instruction takes many cycles. In particular, frequent branching (i.e. "decision-making" inside the CPU), as sorting algorithms typically have to do, tends to suffer from pipeline-related latencies.
the "partition phase" of Quicksort
V8 does not use Quicksort any more. That said, of course all sorting algorithms have to move data around.
Does it also have something to do with fitting all data in the internal cache of the processor and whether the internal cache can support 32 bit but not IEEE 754 numbers?
The CPU's cache does not care about the type of data. The size of the data (64-bit doubles are twice as big as 32-bit integers) can cause caching-related performance differences though.
V8 is capable of optimizing the numeric storage type if the optimizer can deduce that all the values in the array will fit in that size
Almost; there are no deductions involved: the array optimistically starts with a Smi backing store, and generalizes that as needed, e.g. when the first double is stored, the storage is switched over to a double array.
You are probably seeing the effect of "just-in-time compiling."
Not really. Of course all modern engines JIT-compile your code, but that's true for all code, and doesn't explain the difference here.
I've got two numbers that I want to compare. The numbers in the following example are the result of 26^26 computed in two different systems. One of which is my javascript code.
However, when comparing the two numbers I end up with something like this:
AssertionError [ERR_ASSERTION]: 4.0329146112660565e+26 == 4.0329146112661e+26
They're obviously not equal, but theoretically they should.
What's the proper way to perform equality on big numbers in javascript (even if it's an approximation)?
If what you're trying to do is determine if two numbers are practically equivalent you'll have to come up with your margin of error. One way to do this is to compute the difference between the numbers and then determine if that difference is significant or not.
So, taking your numbers from before, we could evaluate the difference between these numbers through subtraction. Since we don't really care about the sign of this difference, I'll go ahead and get the absolute value of the difference.
Math.abs(4.0329146112660565e+26 - 4.0329146112661e+26) === 4329327034368
(Sidenote: Now is not the time to explain why, but the == operator in JavaScript has confusing and error-prone behavior, use === when you want to compare values.)
That difference is a HUGE number, but related to how big our numbers are in the first place, it's rather insignificant. Intuitively, I'm tempted to divide the difference by the smallest of our original numbers like so:
4329327034368 / 4.0329146112660565e+26 === 1.0734983136696987e-14
That looks like a pretty small number. Repeat that same operation with a bunch of values and you should be able to determine what you want your margin of error to be. Then, all you'll have to do is perform the same operations with arbitrary numbers and see if that "difference ratio" is small enough for you.
function similar(a, b) {
let diff = Math.abs(a - b);
let smallest = Math.min(Math.abs(a), Math.abs(b));
let ratio = diff / smallest;
return ratio < MARGIN_OF_ERROR;
}
Now I just came up with that way of determining the importance of the difference between two numbers. It might not be a very smart way to compute it, it might be appropriate to some situations and not to others. But the general idea is that you'll have to make a function that determines if two values are close enough with your own definition of "close".
Be aware though, JavaScript is one of the worst languages you can be doing math in. Integers become imprecise when they go beyond Number.MAX_SAFE_INT (which seems to be 9007199254740991 according to Chrome, not sure if it varies between browsers or if that's a standardized constant).
Update: If your target engine is es2020 or above, you can use the new BigInt javascript primitive, for numbers higher than Number.MAX_SAFE_INTEGER
BigInt(4.0329146112660565e+26) === BigInt(4.0329146112661e+26)
//false
See more information in MDN
var a = 4.0329146112660565e+26;
var b = 4.0329146112661e+26;
a = Math.round(a/10e+20)*10e+20
b = Math.round(b/10e+20)*10e+20
a == b;
I would suggest to use one of big numbers library:
big.js (https://www.npmjs.com/package/big.js)
Example:
var x = new Big('4.0329146112660565e+26');
var y = new Big('4.0329146112661e+26');
// Should print false
console.log('Comparision result' + x.eq(y));
big-numbers (https://www.npmjs.com/package/big-numbers)
Example:
var x = bn.of('4.0329146112660565e+26');
var y = bn.of('4.0329146112661e+26');
// Should print false
console.log('Comparision result' + x.equals(y));
I'm doing some math in Node.js, and I've run into some situations in which a calculation that I would expect to give an error, such as division by 0 and the logarithm of 0, does not do so.
I've read the documentation and some other Q/As, and I understand that returning things like Infinity and -Infinity is normal behavior in Javascript. I'm not arguing for/against this.
I'm wondering, however, if there's a clever way to make JavaScript give me an error instead of continuing the calculations when this happens. The biggest issue is sometimes, an Infinity or -Infinity will get generated in the middle of a long and complex calculation, and that number will continue to be used, and eventually the overall calculation will simply return a normal number which is simply wrong. It's difficult to debug because we have no way of knowing right off the bat where the error happened, since no error is getting thrown and Infinity is an acceptable number in JS.
While the answer to Best way to prevent/handle divide by 0 in javascript provides an answer for specific, known cases where this might occur, I am seeking a catch-all solution for detecting when this might occur, rather than hunt down every case where it might occur or discover each case as I go.
The short answer is don't use javascript for any serious math. Javascript is fault-tolerant (which is why it has Infinity, -Infinity, -0, and NaN), but math isn't. Math is supposed to fail when you try impossible things.
As Gothdo has stated, creating custom functions for the behavior would work.
If you're doing math on more complicated objects (such as Points, or Vectors, or Spaces) that can be represented by a JSON object, there's a way to overload the vanilla operators.
http://www.2ality.com/2011/12/fake-operator-overloading.html
full source at
https://github.com/rauschma/op_overload
It's slightly tricky, and it's not really any more practical than just using functions, but it's kinda cool.
You can for example make a function divide that throws error if the result if the division is Infinity:
const divide = function(dividend, divisor) {
const result = dividend / divisor
if (Math.abs(result) === Infinity) {
throw new Error("Division by zero")
}
return result
}
Then in calculations, instead of using the division operator, use that function:
const fourDividedByTwo = divide(4, 2) // gives 2
const oneDividedByZero = divide(1, 0) // throws error
This output should be true.but it give false always.
Number.isInteger(parseFloat('134965.83') / parseFloat('0.01'))
Floating point arithmetic in Javascript is broken and in general as well.
It has nothing to do with division, it will return false if you don't do division since you are checking float value.
Number.isInteger(parseFloat('134965.83') / parseFloat('0.01')) translates to Number.isInteger(13496582.999999998) -> false
Check these examples.
Number.isInteger(parseFloat('134965.83') )// outputs false without division
As per the spec
If Type(argument) is not Number, return false.
If floor(abs(argument)) ≠ abs(argument), return false.
This happens because the outcome of the division is not an integer but something like 13496582.999999998.
Some floating numbers require a very small precision that is limited by the data type used. For example, the number 1/3 can never be expressed entirely as 0.333333333333 because there is a limitation to the data type size. Therefore there will always be a tiny rounding error involved in floating operations.
Edit: In response to the comment asking for a recommendation on how to deal eith this, actually there are several possibilities. It depends on the context and on accuracy required.
In short, to overcome this use a very small constant Number.EPSILON (see also this) and use it in comparisons. Disclaimer: this is just a quick example, read extensively the implications on the links provided.
var myIsInteger = function(n) {
return (n % 1) > Number.EPSILON
};
We effectively check that the residual of the division with 1 is within the constant.
parseFloat('134965.83') / parseFloat('0.01') = 13496582.999999998
And when Number.isInteger(13496582.999999998) will always return false