since I want to receive a lot of data multiple times per second with an $ajax (or jQuery.getJSON) method, I wonder if it could make sense to round long float values (1.23242342344 ... ) to a short version.
As far as I know it doesn't make a difference in most programming languages if its 2.2 or 2.202312323, since both reserve the space of a float, but I'm not sure how JSON handles this, maybe it's more like a string, and the string would get shorter with rounded values?
So, can I speed up JSON calls with rounded values?
Rounding values will make a difference, proportional to the amount of data you transfer.
All HTTP communication is done with Strings and JSON is a string format to transfer data.
Therefore 12.3456789 will take 10 bytes where as 12 will only need 2 (one byte per character).
Related
I have numbers generated from Javascript code and I want to store them in PostgreSQL table. I have legacy table where the whole JSON object is stored as JSONB type and in the new table I'd like to flatten the JSON to separate columns.
Ideally I want to avoid loss of precision as much as possible. Especially I'd like to avoid turning JS integer numbers into float numbers and vice versa. In other words inserting integer and getting back float is something I'd like to mitigate (if possible).
So far I've experimented with DOUBLE PRECISION and NUMERIC types. I think NUMERIC is better fit because documentation states that within the implementation limits there is no loss in precision. On the other hand DOUBLE PRECISION will be probably faster for numeric operations. I plan to do a lot of statistical operations.
I am not sure which one to choose. What is the optimal or recommended PostgreSQL data type with regards to maximum compatibility JavaScript Number type?
I am not JavaScript expert, but what I found on net, then JavaScript uses 64bit floats. It is same like DOUBLE PRECISION type - 8bytes like 8bytes.
I have a WCF service operation that returns an object with long and List<string> properties. When I test the operation in a WCF application, everything works fine and the values are correct. However, I need to be able to call the service using jQuery and JSON format. The value of the long property apparently changes when I read it back in the OnSucceed function.
After searching I've found that JSON.stringify changes big values. So in code like this:
alert(JSON.stringify(25001509088465005));
...it will show the value as 25001509088465004.
What is happening?
Demo here: http://jsfiddle.net/naveen/tPKw7/
JavaScript represents numbers using IEEE-754 double-precision (64 bit) format. As I understand it this gives you 53 bits precision, or fifteen to sixteen decimal digits. Your number has more digits than JavaScript can cope with, so you end up with an approximation.
Do you need to do maths operations on this big number? Because if its just some kind of ID you can return it as a string and avoid the problem.
I want to write out to, and read in ieee format float/double values from a binary byte stream in a javascript module. Anyone know of how one would go about doing this? an equivalent to the doubleToRawLongBits and longBitsToDouble functionality in java.
You'll want to use a typed array for such things. Store your doubles into a Float64Array, then access the raw bytes from the underlying ArrayBuffer (and use bit shifts on those if you need single bits). If you're doing something more complicated, want to mix multiple types, or even control the endianness, overlay it with a DataView.
Is there an accepted way to represent high resolution timestamps in JSON and/or JavaScript?
Ideally, I would like it to support at least 100 ns resolution, since that would make the server code a bit simpler (since the .NET DateTime resolution is 100 ns as well).
I found a lot of questions dealing with manipulating high-resolution timers and such (which is not possible, apparently), but I simply need to represent it somehow, in an application API.
This is for an API built in REST style using JSON, so actually measuring time in this resolution is not required. However, I would like to transfer and use (potentially in JavaScript) the timestamp in its full resolution (100 ns, since this is .NET).
In light of your clarification, isn't your timestamp just a really big integer? The current timestamp is 1329826212. If you want nanosecond precision, we are just talking about like 9 more digits: 1329826212000000000. That is a number that JavaScript can easily handle. Just send it over as:
myobject = {
"time": 1329826212000000000
}
It should be perfectly fine. I just tried doing some arithmetic operations on it, division by a large number and multiplication by the same. There is no loss of value.
JavaScript supports a huge range of floating point numbers, but guarantees integral accuracy from -2^53 to 2^53. So I think you are good to go.
UPDATE
I'm sorry, I just re-read your question. You wish to represent it? Well, one thing I can think of is to extract the last 9 digits (additional precision beyond second granularity) and show them to be the decimal part of the number. You may even wish to extract the last 6 digis (additional precision beyond the millisecond granularity).
The JavaScript Date object only has millisecond precision.
However, if you are just looking for a standard format to encode nanosecond precision times, an ISO 8601 format string will allow you to define nanoseconds as fractions of seconds:
Decimal fractions may also be added to any of the three time elements. A decimal point, either a comma or a dot (without any preference as stated most recently in resolution 10 of the 22nd General Conference CGPM in 2003), is used as a separator between the time element and its fraction. A fraction may only be added to the lowest order time element in the representation. To denote "14 hours, 30 and one half minutes", do not include a seconds figure. Represent it as "14:30,5", "1430,5", "14:30.5", or "1430.5". There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties.
There is a trick used by jsperf.com and benchmarkjs.com that uses a small Java applet that exposes Java's nanosecond timer.
See Stack Overflow question Is there any way to get current time in nanoseconds using JavaScript?.
Javascript represents all numbers as double-precision floating-point. This means it loses precision when dealing with numbers at the very highest end of the 64 bit Java Long datatype -- anything after 17 digits. For example, the number:
714341252076979033
... becomes:
714341252076979100
My database uses long IDs and some happen to be in the danger zone. I could change the offending values in the database, but that'd be difficult in my application. Instead, right now I rather laboriously ensure the server encodes Long IDs as Strings in all ajax responses.
However, I'd prefer to deal with this in the Javascript. My question: is there a best practice for coercing JSON parsing to treat a number as a string?
You do have to send your values as strings (i.e. enclosed in quotes) to ensure that Javascript will treat them as strings instead of numbers.
There's no way I know of to get around that.
JavaScript represents all numbers as 64b IEEE 754 floats.
If your integer can't fit in 52 bits then it will be truncated which is what happened here.
If you do need to change your database, change it to send 52 bit integers. Or 53 bit signed integers.
Otherwise, send them as strings.