Export AtomicFloat32 to allow casting numbers with possible integer value

[eliot-akira]

I have a situation where certain message arguments need to be always sent as float32. However, when the values hit round numbers (0, 1.0, 2.0..) they get sent as int32.

This PR exports OSC.AtomicFloat32 to allow force-casting values to float32. Also added support for this in functions where the value need to be passed through.

Example use case:

new Message('/route', new AtomicFloat32(i / 2))

[adzialocha]

Thank you again for this PR @eliot-akira 😸

It occurs to me that the problem might lie in how the isFloat utility method is implemented, maybe it can be improved in the sense that it actually considers values like 2.0 to be a float number instead of an integer (for example by converting it to a string and checking if a dot is included)? Would this also help your use-case?

I also like the ability to "force" types via your solution but right now it sounds like a new feature. The issue I see here is rather a "bug" in the isFloat method and we could easily fix it without moving too much code and API in other places. What do you think?

Also we should add a test case for it 👍

[eliot-akira]

I explored different ways of inferring float values, but since JavaScript only has Number, float 1.0 is indistinguishable from integer 1. The API user would need to check every value, convert to string and add .0 - to be converted back to a number again. (On the library side, I suspect it's not possible - the value will be caught by isInt first.)

..Or, as I figured, they can explicitly cast the value using Atomic types. I think it's more efficient that way too: instead of an if statement every call and possible conversion back, the value is already in an Atomic instance that's needed internally.

I agree about test cases, will add some soon!

[eliot-akira]

OK, I added tests to demonstrate cases where an ability to explicitly encode float32 values is useful - specifically, the test with values [0.0, 0.5, 1.0, 1.5, 2.0] where one array without using AtomicFloat32 has type ififi and another array with type fffff as expected.

[arnoson]

Is there any news on this?
I guess another solution might be allowing an optional OSC data type like osc.js does (although it doesn't seem optional there, which I really like about your library because most of the time the data type is obvious).

Something like this?

new OSC.Message('/test', [12.0, 'f'], 'hello')
// and
message.add(12.0, 'f')

[adzialocha]

There is a fork of osc-js with this feature where this is possible @arnoson and @eliot-akira. It supports more extended types, I've created a PR here: #48

[adzialocha]

Extended type just got merged into osc-js via #48 👍