Add the float64 type (used in smart contracts)

[jcalfee]

[jcalfee]

@arhag

the ABI serializer currently does support a float64 but on a quick glance just now it seems to be doing it in the wrong way (treating it as a native double rather than a Berkeley softfloat and handling all the conversion stuff we have discussed before). So none of that stuff seems to be ready as far as I can tell.

https://github.com/EOSIO/eos/blob/master/libraries/chain/contracts/abi_serializer.cpp#L91 built_in_types.emplace("float64", pack_unpack<double>());

So the code is not ready, @arhag Do you know where I can find out how a Berkeley softfloat will serialize? Is that included in the library too? http://www.jhauser.us/arithmetic/SoftFloat.html

[arhag]

@jcalfee:

@larryk85 would probably know better than me since he has been leading the integration of softfloat into WASM. But reading the Berkley SoftFloat documentation, it seems that it is conforming to the IEEE standard.

So if you are dealing with the raw data representation of the floating point numbers (which you would have to if you wanted to serialize the transaction and then sign the appropriate digest all in a client-side only JavaScript library) then you need a way to take numbers (however you represent them to the user) and convert them into the raw data that represents (according to the IEEE floating point standard) the closest approximation to that number (and vice versa for displaying transaction data in a human readable way all with only client side tools). I'm not sure how you would actually do this in JavaScript though.

The from_variant and to_variant stuff I mentioned in the snapshot in the OP is regarding providing and accepting convenient human readable JSON between the client and node, but that doesn't help you if you want to be able to do the transaction signing all in the client side without having to trust a node.

[larryk85]

As for serialization, that should be fine. The float64 type is just a struct wrapping a uint64_t, so in terms of size this is correct. The softfloat library types are compliant with webassembly's floating point, which is a stricter subset of IEEE 754-2008, as in we do not allow decimal floating point, only binary floating point. So in saying this, arhag is correct in his statement. As for the JavaScript side, they should be able to use some IEEE 754 library to do any operations.

[jcalfee]

@larryk85 would the softfloat library have an issue with float values over 53 bits? I found a library, this author provided some example C code. Can you please check this out:

https://github.com/andrasq/node-ieee-float/issues/1#issuecomment-378005330

Is this incompatible with softfloat?

[jcalfee]

eosjs@7.1.3 released