Although I have to state that this ufloat thing is overall weird-ish. But overall, I think the way you implemented it is the best.
Julian Am 10.12.19, 21:55 schrieb "Christofer Dutz" <[email protected]>: Hi Lukas, Yeah ... the more I thought about it, the more I liked it and since today that version is implemented ... in the feature/knxnet-ip branch __ Chris Am 10.12.19, 18:09 schrieb "Lukas Ott" <[email protected]>: +1 for ufloat Option as Mspec already supports uint so in my humble opinion it would just be consistent to support ufloat as well.. Christofer Dutz <[email protected]> schrieb am Mo., 9. Dez. 2019, 13:59: > Hi all, > > while implementing the mspec for KNXnet/IP I stumbled into the first pit > regarding floating point numbers. > In the spec they claim to be normal IEEE 754 half precision floating point > numbers and therefore I thought a “float 16” would be ok. > However it turned out that they don’t use the formal half precision types. > The exponent is one bit less and the mantissa is one bit more. > So I think it would be great to change the float datatype to something like > > float +4.11 > > If there’s a “+” it’s a signed floating point (Alternatively we could add > a “ufloat” type) … the main thing is that then comes the number of exponent > bits and after the dot the mantissa. > > Right now I “solved” the problem like this: > > ['9' KnxDatapointF16 > [reserved uint 8 '0x0'] > [simple bit 'sign'] > [simple int 4 'exponent'] > [simple uint 11 'mantissa'] > [virtual float 16 'val' '(sign ? -1 : 1) * (0.01 * mantissa) * (2 ^ > exponent)'] > ] > > Which is not that ideal … > > What do you think? > > The more I think of it, I think a: “float” and a “ufloat” is the better > idea as this continues the int / uint concept for integers. > > Chris > > > >
