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 ;)
Related
The other day I was researching about sound synthesis in c, and learnt how much it affects to change the code to use fixed point math instead of floats, as many processors (micro-controllers in particular) are faster at calculating integers than floats. I was wondering if the same concept applies to JS. I wish it would, but I intuitively expect that JS takes the numbers always as floats underneath.
However, asking simply whether we can harness the speed of integer calculation in JS maybe is not a complete question, because there are many ways a number can be calculated.
do operations in JS get optimized in numbers stored in an arbitrary var or let, if they are integers?
how about dataViews and arrayBuffers, for example is it faster to bit-shift left a number in an arrayBuffer (or as an arbitrary var too for that matter) than multiplying it by two?
does it vary depending on whether we are in node-js or a browser?
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 3 years ago.
Using the parseFloat method converted the string value from the DB to float and multiplied by 100. But the output looks odd. Following the piece of code which I've used.
parseFloat(upliftPer) * 100 //upliftPer value read from DB and its value is 0.0099
So when it multiplied with 100 getting 0.9900000000000001 I suppose to get 0.99 but some junk values getting appended. Also I went ahead and did the same in the console log of chrome browser still the same result. I have attached screenshots for reference. Solution I needed is 0.0099 * 100 should result 0.99. I cant apply round / toFixed since I need more precision.
This is because of JavaScript internal casting to double type. There's always a certain degree of noise due to floating point inaccuracy. Here's some information on that.
You can just round it up using toFixed(x) with as much decimal spaces of precision as you want (or as much as JavaScript would allow you).
It is not related to JavaScript nor to any programming language.
It’s because of the conversion from decimal floating-point to binary representation: the process ends up in an infinite process that has to be truncated because of the limited number of bits available for storing the numbers (and thus, of the limited amount of memory in computers)
Check out the process of conversion and take a look at this converter that tells you how much error there is during conversion
As #sebasaenz pointed out in his answer, you can use toFixed(x) to round up your number and get rid of junk
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.
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).
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.