What is optimal way of storing Javascript Number in PostgreSQL - javascript

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.

Related

Read float number from Postgres without rounding

this might seem a very naive question but I am having a hard time to figure this out. I have a float value 37.50378 in my PostgreSQL database. When I am trying to fetch this value in my Nodejs application it gives me 37.5038. I want to fetch the exact number without rounding off the decimal digits. How do I do that?
The data type of the column in Postgres is Real.
EDIT
I am using Knex schema builder and using float(column, precision, scale) to create a column(to store above-said value). I have tried different numbers for precision and scale just in case that's causing the above-said behavior. But every time I tried to fetch the value 37.50378, all I get back is 37.5038.
Thanks.
You may want to use double(column) in knex, which is translated to double precision in postgres.
This is because of the real 4-byte precision. See PostgreSQL Numeric Types.
It's got nothing to do with Node.js or its PostgreSQL driver.

How would you store a number larger than the max 64 bit int in mongoDb?

The number is larger than 9223372036854775807 - too big for NumberLong, which is mongo's native 64-bit long type. What's the best way to do this/the best field type?
Is it possible to preserve any of the querying functionality of a smaller integer (such as {$lt})?
The big numbers are being generated by bignumber.js, and I'm using mongoose to interact with mongoDb.
I'm afraid that the only viable/safe option would be to store such big numbers as a string and serialize it back and forth between the application and MongoDB when read/written. However, you will loose the ability to use MongoDB built-in functions that work with numbers (you can still cast the values to numbers, but it won't be safe anymore).

JavaScript - display number as non standard index?

In my JS, I've got a generated number (fairly enormous, it's normally about 95^[5-10]).
How do I stop this number from being displayed as standard notation?
You can't. JavaScript cannot handle such large numbers natively, and the scientific notation helps emphasize that fact.
That said, you might be able to do some string manipulation on it, to strip out the . and process the exponent to find out how many zeroes to add to the end. Obviously it won't be accurate but that's because of the inability to handle such large numbers I mentioned.

Convert Float32Array to 16 bit float Array Buffer JavaScript

I'm getting PCM audio samples in Float32Arrays. But my application can only support data with a 16 bit length so I need to convert.
I'm not sure how to do this since there is no typed array for a Float16Array and I've never worked with data on the bit level. Could someone explain or show how this could be done?
Firstoff, JavaScript is dynamically typed and has no concept of type length / size.
It is a matter of the runtime what type sizes may be used internally on the native platform, but that does not necessarily limit the possible values i.e the emulated type length if you will, inside the JavaScript runtime environment.
Also, probably you need 16 bit int to pass it to an audio device. Would make more sense.
So, I would narrow down your question to: how to convert float to int in JavaScript and the answer is here: How do I convert a float number to a whole number in JavaScript?
BUT if you really want to convert the precision of your values: What you could do is multiply by X, and round that ("convert to int", see link above), and then divide again by X. However this is not like converting a float of one size to another size because you dont take into account the mantisse/exponent representation of a float inside the actual memory. My solution only chops off some precision (quantization if you will).
Anyway, JavaScript is not a platform where you handle memory representation of types; it is already messy enough to handle the difference between float and int ;)

Best way to deal with very large Long numbers in Ajax?

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.

Categories