I am trying to pass a big int to a function from an onclick event in HTML. The ints are always very long, and I cannot seem to pass it to my function without rounding. I have tried some bigInt libraries to the same end, though I would much rather prefer simple string casting.
My js function:
function initBuy(id){
console.log(id.toString());
}
and my HTML event:
<dt></dt><dd><a id="buy" onclick="initBuy(String(' + all_data[index].listing_id + '))" class="btn btn-success">Buy This Item</a></dd>
An example of a passed int:
13934317650292905813
and the result of clicking the button:
"13934317650292906000"
The passed int looks fine when I write it to an elements' text. When I pass it to a function, however, it's rounding it.
From the post here the maximum value an integer in Javascript could take is 9007199254740992
Your number 13934317650292905813 is far bigger than that.
From this post here you can use BigInteger.js to accommodate big integers
You say in your (ambiguous) question:
'The passed int looks fine when I write it to an elements' text. When I pass it to a function, however, it's rounding it.'
and in your comment:
If I set all_data[index].listing_id to an elements text, it works.
That means you are already getting the 'integer' as text-string in JSON.
Nothing in your current question converts the string to a number (I tested it).
As soon as the string would be converted to a number it would overflow IEEE 754's max accuracy of 2^53=9007199254740992.
Note that: initBuy(String(' + all_data[index].listing_id + '))
will return the string + all_data[index].listing_id + (as it should).
Passing the string '13934317650292905813' to your initBuy function also returns string '13934317650292905813' (as it should).
In other words, I can not reproduce your problem using the code you have supplied.
I assume you have simplified your initBuy function for this question (you'd have to post the original one for further examination, preferably together with an excerpt of a relevant part of the raw JSON string).
I assume you might accidentally convert the string to a number (probably using a +) inside that function!
Related
In my code, the value of a particular var can originate from any one of a number of different json sources. For some of those sources, the json element concerned will be a string (e.g. "temp": "10.2"), while for other sources the json element will already be a float (e.g. "temp": 10.2).
Does it do any harm (is anything likely to break) if I just pass the json element (from whatever source) through a parseFloat(), even if it's already a float? It seems to work; I'm just thinking about good/bad practice and possible breakage in future or on a different platform.
Thanks.
You should be able to call parseFloat() on a float or a string without any problems. If it is a float already, it's converted to a string first, and then to a float again, so it's a little less efficient, but it shouldn't matter too much.
You should still check the result for NaN, in case there's something unexpected in the data.
The most appropriate method to convert any datatype to a number is to use the Number function:
In a non-constructor context (i.e., without the new operator),
Number can be used to perform a type conversion.
Number("1234") // 1234
Number(1234) // 1234
This method differs from parseFloat in these ways at least:
Number function does not perform "double-conversion" if the input is already a number (ref)
Parse float converts the input to a string then extracts the number (ref)
Number function returns common sense values for most datatypes e.g. Number(true) yields 1
Parse float uses the string value of input so parseFloat(true) tries to parse number from "true" and yields NaN
Number function fails when input string is an invalid number e.g. Number("123abc") yields NaN
Parse float tries to parse as much of a number as possible e.g. parseFloat("123abc") yields 123
If you are sure the value is always a valid number, you should use Number(stringOrNumber).
If you need some additional safety using parseFloat() you could also write your own function which is also performance optimized:
function toFloat(value) {
return typeof value === 'number' ? value : parseFloat(value);
}
I also created a jsPerf test case that shows the performance is >30% better than the plain parseFloat() for a 1:1 ratio between strings and numbers as input values.
Nope there is no problem with passing a number to it
MDN says as long as it can be converted to a number, nothing breaking should happen.
If the first character cannot be converted to a number, parseFloat returns NaN.
As an alternative, you could use the unary operator + which does basically the same thing as parseFloat and also returns NaN if it didn't work.
For instance:
var myFloat = +('10.5');
var myOtherFloat = parseFloat('10.5', 10);
var alreadyAFloat = parseFloat(10.5, 10);
console.log(myFloat === myOtherFloat && myOtherFloat === alreadyAFloat); // true
Wether it's a float or a String using parseFloat() is much safer to avoid all kind of errors.
As you said it will always work, but if you enforce it to be a float you will avoid getting any Exception.
For Example:
Both parseFloat('10.2', 10) and parseFloat(10.2, 10) will work
perfectly and will give you the same result which is 10.2.
Personally I can't see this being a problem what so ever, to be honest I would always use the parsefloat() for one reason, and that is safety. You can never be to sure what may happen, so always predict the worse :D
I have the following JSON:
[{"hashcode": 4830991188237466859},{...}]
I have the following Angular/JS code:
var res = $resource('<something>');
...
res.query({}, function(json) {hashcode = json[0].hashcode;};
...
Surprisingly (to me, I'm no JS expert), I find that something (?) is rounding the value to the precision of 1000 (rounding the last 3 digits). This is a problem, since this is a hash code of something.
If, on the other hand I write the value as a String to the JSON, e.g -
[{"hashcode": "4830991188237466859"},{...}]
this does not happen. But this causes a different problem for me (with JMeter/JSON Path, which extracts the value ["4830991188237466859"] by running my query $.hashcode - which I can't use as a HTTP request parameter (I need to add ?hashcode=... to the query, but I end up with ?hashcode=["..."]
So I appreciate help with:
Understanding who and why -- is rounding my hash, and how to avoid it
Help with JMeter/JSON Path
Thanks!
Each system architecture has a maximum number it can represent. See Number.MAX_VALUE or paste your number into the console. You'll see it happens at the JavaScript level, nothing to do with angular. Since the hash doesn't represent the amount of something, it's perfectly natural for it to be a string. Which leads me to
Nothing wrong with site.com/page?hashcode=4830991188237466859 - it's treated as a string there and you should keep treating it as such.
The javascript Number type is floating point based, and can only represent all integers in the range between -253 and 253. Some integers outside this range are therefore subject to "rounding" as you experience.
In regards to JMeter JSON Path Extractor plugin, the correct JSON Path query for your hashcode will look like
$..hashcode[0]
See Parsing JSON chapter of the guide for XPath to JSON Path mappings and more details.
I've searched these forums and have found nothing. What I'm trying to find is a function in PHP that will convert a binary representation into a regular integer. parseInt seems to do the trick in JavaScript, but I need a serverside equivalent for the specific program I am creating. Anyone have thoughts?
i.e. parseInt(110100101); in JavaScript returns 421. I need a function that returns the same number with that binary.
bindec will do what you are looking for. You just need to make sure that you are passing it as a string, so if you have as an int, just cast it to a string first
$newInt = bindec( (string) $binaryInt );
Otherwise if its already a string you dont need to cast it to one and can just pass it in:
$newInt = bindec( $binaryString );
In my case, i am converting a string value of '9999999999999999' to integer using parseFloat(). But it converts to next number of it i.e. 10000000000000000. But i need to convert it to before of that number i.e. 999999999999999998. I have searched for a while in google. But could not get clear idea to implement this.
Try this
document.getElementById("demo").innerHTML=Math.round(9999999999999999-2);
OUTPUT
9999999999999998
This number is too big to represented precisely in JavaScript Number value. So no amount of conversion will give you values reliably/precisly as you want around such range.
I.e. (9999999999999999-1)===(9999999999999999) returns true, but (9999999999999998)===(9999999999999999) returns false.
If you need such high precision in JavaScript (similar to many other languages) you need to use specialized data types (unfortunately there is no "BigInteger" type built in in JavaScript).
You will need to use some external javascript library to work with big numbers like that, cause max number you cant represent without losing presicion in javascript integers is 9007199254740992 (Explanation : What is JavaScript's highest integer value that a Number can go to without losing precision?)
Here you have some link where people discuss about some libraries to use for javascript big numbers.
How to deal with big numbers in javascript
I need to parse a json that contains a long number (that was produces in a java servlet). The problem is the long number gets rounded.
When this code is executed:
var s = '{"x":6855337641038665531}';
var obj = JSON.parse(s);
alert (obj.x);
the output is:
6855337641038666000
see an example here: http://jsfiddle.net/huqUh/
why is that, and how can I solve it?
As others have stated, this is because the number is too big. However, you can work around this limitation by sending the number as a string like so:
var s = '{"x":"6855337641038665531"}';
Then instead of using JSON.parse(), you can use a library such as javascript-bignum to work with the number.
It's too big of a number. JavaScript uses double-precision floats for numbers, and they have about 15 digits of precision (in base 10). The highest integer that JavaScript can reliably save is something like 251.
The solution is to use reasonable numbers. There is no real way to handle such large numbers.
The largest number JavaScript can handle without loss of precision is 9007199254740992.
I faced this issue some time ago, I was able to solve using this lib: https://github.com/josdejong/lossless-json
You can check this example:
let text = '{"normal":2.3,"long":123456789012345678901,"big":2.3e+500}';
// JSON.parse will lose some digits and a whole number:
console.log(JSON.stringify(JSON.parse(text)));
// '{"normal":2.3,"long":123456789012345680000,"big":null}' WHOOPS!!!
// LosslessJSON.parse will preserve big numbers:
console.log(LosslessJSON.stringify(LosslessJSON.parse(text)));
// '{"normal":2.3,"long":123456789012345678901,"big":2.3e+500}'