This question already has answers here:
What is JavaScript's highest integer value that a number can go to without losing precision?
(21 answers)
Closed 7 years ago.
Why is it apparently safe to use numbers as integers in Javascript? What I mean is that a loop such as the one below is generally "trusted" to run the expected number of times even though the final loop requires an exact compare of (10000 == 10000) when these two values are floats and not ints. Is there some sort of built-in rounding feature that makes this safe and reliable -- or is this horrible and untrustworthy coding? Thanks.
--edit--
It is interesting that there is a declared safe integer range. I was not aware of MAX_SAFE_INTEGER. We all know the standard whine that 2 + 2 = 3.9999. I note that MAX_SAFE_INTEGER is listed as ECMAScript-6 so does this imply that IEEE-754 does not actually mention a safe integer range?
var cnt = 0;
for (var i=0 ; i<=10000 ; i++){
// loop 10001 times
cnt++;
}
alert('cnt = '+ cnt);
IEEE-754 double-precision floating point numbers (the kind used by JavaScript) have a very wide range over which they precisely represent integers, specifically -9,007,199,254,740,991 through 9,007,199,254,740,991. (Those values are being added to JavaScript's Number function as constants: MIN_SAFE_INTEGER and MAX_SAFE_INTEGER.) Outside that range, you could indeed run into trouble.
In fact, if it weren't for safety, this loop would never end:
var n, safety;
safety = 0;
for (n = 9007199254740990; n != 9007199254740999; ++n) {
if (++safety === 20) { // Long after `n` should have matched
snippet.log("Had to break out!");
break;
}
snippet.log("n = " + n);
}
<!-- Script provides the `snippet` object, see http://meta.stackexchange.com/a/242144/134069 -->
<script src="http://tjcrowder.github.io/simple-snippets-console/snippet.js"></script>
Firstly, the final loop doesn't require the two values to be equal. Just that i is less than 10000.
Secondly, the Number type in JavaScript holds integer values accurately up (and down) to a point. You can access the Number.MAX_SAFE_INTEGER and Number.MIN_SAFE_INTEGER properties to see what the safe range is for your browser/engine.
And if you want to check if an instance of Number is an integer, just use the Number.isInteger() method.
var i = 10, e = document.getElementById('message');
if(Number.isInteger(i)) {
e.innerHTML = "i is an integer";
} else {
e.innerHTML = "i is not an integer";
}
<div id='message'></div>
Related
I am building a factorization program and I would like to change each BigInt type to regular Numbers when number <= Number.MAX_SAFE_INTEGER.
Instead of coding two functions for each case, it would be nice if I could keep it all into one function which could vary variables types accordingly (something like let myVar = 3n || 3 I guess).
function Factorize(dividend) {
let divisor = 2n;
//if number <= Number.MAX_SAFE_INTEGER then let divisor = 2. Same for all other bigInts.
let method1 = [], method2 = [];
while (dividend > 1n) {
if (dividend % divisor === 0n) {
method1.push(`${divisor}`);
method2.push(`${dividend} / ${divisor}`);
dividend /= divisor;
} else {
divisor++
};
};
return {
default: method1,
detailed: method2,
get isPrime() {
return this.default.length === 1 && this.default[0] !== 2;
}
};
};
const number = parseInt(prompt());
console.log(Factorize(BigInt(number)));
Thanks for your help.
What's the difficulty? Your comment contains half the required code already:
if (dividend <= Number.MAX_SAFE_INTEGER) {
divisor = 2;
dividend = Number(dividend);
}
And then you only need to replace the two strict equality comparisons === 0n and !== 2 with their non-strict variants. 0 == 0n returns true, 0n === 0n returns false.
Some other things worth mentioning:
(1) This method for factorization is extremely slow. There are prime numbers well below Number.MAX_SAFE_INTEGER for which this will take months. Depending on your use case, limiting the input size or implementing some sort of timeout (e.g., returning an error if a certain number of iterations wasn't enough to find the complete result) may be more important than supporting BigInts at all. (For inputs that have only small prime factors, even extremely huge inputs will still terminate quickly, so it's certainly possible to exceed Number range (even Number.MAX_VALUE) while still only taking a few milliseconds.)
(2) Using parseInt to get your input means that you're limiting yourself to Number precision; converting that Number to a BigInt afterwards doesn't bring the lost bits back. For example, if someone enters '12157665459056928801' (which is 3n ** 40n), parseInt will truncate that and your program will hence compute the wrong result. To avoid that, use the fact that the BigInt() constructor can convert strings directly, i.e.: BigInt(prompt()).
(3) While it's sometimes possible to write code that can work on both Numbers and BigInts, doing so is generally not recommended (and often not even useful), because the two types of values (intentionally!) behave differently in a number of ways (otherwise we wouldn't need both of them), so there is a large risk of such code not doing what you think it'll do. In this particular case it should be okay; I'm just advising not to generalize from this example.
I am looking for a portable algorithm for creating a hashCode for binary data. None of the binary data is very long -- I am Avro-encoding keys for use in kafka.KeyedMessages -- we're probably talking anywhere from 2 to 100 bytes in length, but most of the keys are in the 4 to 8 byte range.
So far, my best solution is to convert the data to a hex string, and then do a hashCode of that. I'm able to make that work in both Scala and JavaScript. Assuming I have defined b: Array[Byte], the Scala looks like this:
b.map("%02X" format _).mkString.hashCode
It's a little more elaborate in JavaScript -- luckily someone already ported the basic hashCode algorithm to JavaScript -- but the point is being able to create a Hex string to represent the binary data, I can ensure the hashing algorithm works off the same inputs.
On the other hand, I have to create an object twice the size of the original just to create the hashCode. Luckily most of my data is tiny, but still -- there has to be a better way to do this.
Instead of padding the data as its hex value, I presume you could just coerce the binary data into a String so the String has the same number of bytes as the binary data. It would be all garbled, more control characters than printable characters, but it would be a string nonetheless. Do you run into portability issues though? Endian-ness, Unicode, etc.
Incidentally, if you got this far reading and don't already know this -- you can't just do:
val b: Array[Byte] = ...
b.hashCode
Luckily I already knew that before I started, because I ran into that one early on.
Update
Based on the first answer given, it appears at first blush that java.util.Arrays.hashCode(Array[Byte]) would do the trick. However, if you follow the javadoc trail, you'll see that this is the algorithm behind it, which is as based on the algorithm for List and the algorithm for byte combined.
int hashCode = 1;
for (byte e : list) hashCode = 31*hashCode + (e==null ? 0 : e.intValue());
As you can see, all it's doing is creating a Long representing the value. At a certain point, the number gets too big and it wraps around. This is not very portable. I can get it to work for JavaScript, but you have to import the npm module long. If you do, it looks like this:
function bufferHashCode(buffer) {
const Long = require('long');
var hashCode = new Long(1);
for (var value of buff.values()) { hashCode = hashCode.multiply(31).add(value) }
return hashCode
}
bufferHashCode(new Buffer([1,2,3]));
// hashCode = Long { low: 30817, high: 0, unsigned: false }
And you do get the same results when the data wraps around, sort of, though I'm not sure why. In Scala:
java.util.Arrays.hashCode(Array[Byte](1,2,3,4,5,6,7,8,9,10))
// res30: Int = -975991962
Note that the result is an Int. In JavaScript:
bufferHashCode(new Buffer([1,2,3,4,5,6,7,8,9,10]);
// hashCode = Long { low: -975991962, high: 197407, unsigned: false }
So I have to take the low bytes and ignore the high, but otherwise I get the same results.
This functionality is already available in Java standard library, look at the Arrays.hashCode() method.
Because your binary data are Array[Byte], here is how you can verify it works:
println(java.util.Arrays.hashCode(Array[Byte](1,2,3))) // prints 30817
println(java.util.Arrays.hashCode(Array[Byte](1,2,3))) // prints 30817
println(java.util.Arrays.hashCode(Array[Byte](2,2,3))) // prints 31778
Update: It is not true that the Java implementation boxes the bytes. Of course, there is conversion to int, but there's no way around that. This is the Java implementation:
public static int hashCode(byte a[]) {
if (a == null) return 0;
int result = 1;
for (byte element : a) result = 31 * result + element;
return result;
}
Update 2
If what you need is a JavaScript implementation that gives the same results as a Scala/Java implementation, than you can extend the algorithm by, e.g., taking only the rightmost 31 bits:
def hashCode(a: Array[Byte]): Int = {
if (a == null) {
0
} else {
var hash = 1
var i: Int = 0
while (i < a.length) {
hash = 31 * hash + a(i)
hash = hash & Int.MaxValue // taking only the rightmost 31 bits
i += 1
}
hash
}
}
and JavaScript:
var hashCode = function(arr) {
if (arr == null) return 0;
var hash = 1;
for (var i = 0; i < arr.length; i++) {
hash = hash * 31 + arr[i]
hash = hash % 0x80000000 // taking only the rightmost 31 bits in integer representation
}
return hash;
}
Why do the two implementations produce the same results? In Java, integer overflow behaves as if the addition was performed without loss of precision and then bits higher than 32 got thrown away and & Int.MaxValue throws away the 32nd bit. In JavaScript, there is no loss of precision for integers up to 253 which is a limit the expression 31 * hash + a(i) never exceeds. % 0x80000000 then behaves as taking the rightmost 31 bits. The case without overflows is obvious.
This is the meat of algorithm used in the Java library:
int result 1;
for (byte element : a) result = 31 * result + element;
You comment:
this algorithm isn't very portable
Incorrect. If we are talking about Java, then provided that we all agree on the type of the result, then the algorithm is 100% portable.
Yes the computation overflows, but it overflows exactly the same way on all valid implementations of the Java language. A Java int is specified to be 32 bits signed two's complement, and the behavior of the operators when overflow occurs is well-defined ... and the same for all implementations. (The same goes for long ... though the size is different, obviously.)
I'm not an expert, but my understanding is that Scala's numeric types have the same properties as Java. Javascript is different, being based on IEE 754 double precision floating point. However, with case you should be able to code the Java algorithm portably in Javascript. (I think #Mifeet's version is wrong ...)
I am trying to build a function that takes a price with 2 decimal points and finds the next highest palindrome. I know there are several other ways to approach this, but I am curious why my method is not working. I am new to JS so this might be a simple one. Any advice would be great.
I broke it into smaller chunks with explanations of what I want it to do below:
var ask = prompt("Enter a price");
var reverseIt = function (x) {
x = (parseFloat(x) * 100).toString();
for (var i = (x.length - 1); i >= 0; i--) {
x.substr(i, 1);
}
return
};
The reverseIt function takes an argument removes the decimal (* 100) and reverses the number.
var removeDec = function (j) {
return (parseFloat(j) * 100).toString();
}
The removeDec function takes an argument, removes the decimal point (* 100), and converts it back to a string. Is this redundant for comparing two "number" strings? Should I use the Number() and String() functions instead?
var findDrome = function (i) {
for (var i; removeDec(i) != reverseIt(i); i += (1 / 100)) {
if ((removeDec(i) + 1).toString() == reverseIt(i)) {
document.write(i + (1 / 100));
}
} return
};
findDrome(ask);
The findDrome function takes the ask prompt at the start as an argument. If the number without a decimal doesn't match the reverse without a decimal, then increments it by 0.01. Right before the loop ends, I wanted it to check if the number prior +1 (since it is * 100) is equal to the reverse and if so write the next number.
It wasn't working, so I tried adding parseFloat and toString to specify stricter/more explicit conversions. I also used the loose equality operators, but it's still not working.
My questions: Is this a conversion or syntactical problem or can you not compare the output of 2 functions? Should I instead compare 2 variables and if so how do I assign the for loop in the reverseIt function to a variable?
Your program has a number of issues. First, your reverseIt function never returns a reversed value. The variable x is passed in but it's never updated in the for loop - x.substr() creates a new string instance but it's never assigned back to x so its value never changes. As it is, your for loop in findDrome goes infinite since reverseIt returns undefined.
Another - possible - problem is that you're incrementing a floating-point number by 1/100 but floating point values have no exact representation. I don't know if this is actually affecting your code (since it currently never returns a proper value) but it's something you may have to worry about. This would likely affect parseFloat (which may return a slighly different floating-point value than the string it parses).
Using toFixed() would truncate the number to 2 decimal digits. You could then turn the number to a string and remove the decimal dot character, rather than converting the number back and forth between string and number.
You may want to read up on floating-point arithmetic (if you're not already familiar with it).
As a last comment, you should never, ever rely on Javascript terminating your statements - you should always use ; to terminate a statement like in other proper C-style languages. Leaving out ;-s (even if Javascript lets you get away with it) is considered very poor practice.
I figured it out thanks to the help above! Here is how the fixed program works:
var ask = prompt("Enter a price to find the next palindromic price");
var removeDec = function (j) {
return parseInt(j * 100);
};
var c = removeDec(ask);
This prompts a price and multiplies it by 100 to remove the decimal point and avoid floating point arithmetic. The parseInt removes any decimals smaller than the hundredths place.
var reverseIt = function (x) {
var a = ""
x = x.toString();
for (var i = (x.length - 1); i >= 0; i--) {
a = (a + String(x.substr(i, 1)));
}
return Number(a);
};
var b = reverseIt(c);
The reverseIt function takes an argument, converts it to string and adds each character in reverse to an empty string (a=""). Var a is then returned as a number. The empty string is important for storing the reverse number and is a big reason why my code wasn't working before.
var e = Math.pow(10, (String(c).length - 1));
Var e was added to take into account varying place values to left side of the decimal. Later this helps check if a number is equal to its reverse by adding a 1 to both sides of the number. Var e counts the length of var c (entered value with decimal removed) and finds the appropriate power of 10 to add later. So if you entered 14.40 * 100 then later it will check if 1440 + 1 is equal to 0441 + 1000.. or 10^3. This test is important later in order to exit the loop. This is where my code was failing before because I didn't take adding a number to the reverse into account and I was trying to add decimals which aren't as predictable.
if (c == b) {
document.write("$" + (c / 100) + "... This price is already palindrome!")
} else {
for (c; c !== b; c++) {
b = reverseIt(c);
if ((c + 1) == (b + e)) {
document.write("The next palindromic price is $" + ((Number(c) + 1) / 100));
break;
}
}
}
Here, If the original number and it's reverse are not equal then a loop begins that increments the value by 1 until the entered number + 1 is equal to the reversed number + e. So effectively the loop finds the number right before the loop ends, writes it and then breaks out of the loop. This palindrome finder seems to work smoothly with values big and small, no matter where you put the decimal point. Glad I got it working... it was a great learning experience figuring it out!
Are there any standard hash functions/methods that maps an arbitrary 9 digit integer into another (unique) 9 digit integer, such that it is somewhat difficult to map back (without using brute force).
Hashes should not collide, so every output 1 ≤ y < 10^9 needs to be mapped from one and only one input value in 1 ≤ x < 10^9.
The problem you describe is really what Format-Preserving Encryption aims to solve.
One standard is currently being worked out by NIST: the new FFX mode of encryption for block ciphers.
It may be more complex than what you expected though. I cannot find any implementation in Javascript, but some examples exist in other languages: here (Python) or here (C++).
You are requiring a non-colliding hash function with only about 30 bits. That's going to be a tall order for any hash function. Actually, what you need is not a Pseudo Random Function such as a hash but a Pseudo Random Permutation.
You could use an encryption function for this, but you would obviously need to keep the key secret. Furthermore, encryption functions normally bits as input and output, and 10^9 is not likely to use an exact number of bits. So if you are going for such an option you may have to use format preserving encryption.
You may also use any other function that is a PRP within the group 0..10^9-1 (after decrementing the value with 1), but if an attacker finds out what parameters you are using then it becomes really simple to revert back to the original. An example would be a multiplication with a number that is relatively prime with 10^9-1, modulo 10^9-1.
This is what i can come up with:
var used = {};
var hash = function (num) {
num = md5(num);
if (used[num] !== undefined) {
return used[num];
} else {
var newNum;
do {
newNum = Math.floor(Math.random() * 1000000000) + 1;
} while (contains(newNum))
used[num] = newNum;
return newNum;
}
};
var contains = function (num) {
for (var i in used) {
if (used[i] === num) {
return true;
}
}
return false;
};
var md5 = function (num) {
//method that return an md5 (or any other) hash
};
I should note however that it will run into problems when you try to hash a lot of different numbers because the do..while will produce random numbers and compare them with already generated numbers. If you have already generated a lot of numbers it will get more and more unlikely to find the remaining ones.
Does JavaScript optimize the size of variables stored in memory? For instance, will a variable that has a boolean value take up less space than one that has an integer value?
Basically, will the following array:
var array = new Array(8192);
for (var i = 0; i < array.length; i++)
array[i] = true;
be any smaller in the computer's memory than:
var array = new Array(8192);
far (var i = 0; i < array.length; i++)
array[i] = 9;
Short answer: Yes.
Boolean's generally (and it will depend on the user agent and implementation) will take up 4 bytes, while integer's will take up 8.
Check out this other StackOverflow question to see how some others managed to measure memory footprints in JS: JavaScript object size
Edit: Section 8.5 of the ECMAScript Spec states the following:
The Number type has exactly 18437736874454810627 values, representing the doubleprecision 64-bit format IEEE 754 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic
... so all numbers should, regardless of implementation, be 8 bytes.
Well, js has only one number type, which is a 64-bit float. Each character in a string is 16 bits ( src: douglas crockford's , javascript the good parts ). Handling of bools is probably thus interpreter implementation specific. if I remember correctly though, the V8 engine surely handles the 'Boolean' object as a 'c bool'.