You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@jschall once proposed to add those to the set of native DSDL types:
Can we use a floating point standard that matches IEEE 754 for 16, 32, 64 and 128-bit floats, but also provides for arbitrary bit lengths of floating point fields? I've got a spot where I'd like to use a 24-bit float, but there isn't really any support for it.
Actually what I really want to use here is fixed point Q16.8 - because I want uniform precision for this field. This keeps coming up, again and again and again, and I'd really like built-in support for it.
I can't make it a 32-bit float without spilling into another CAN frame
To which I said:
while I do like the idea in general, it seems like too much work right now, and besides there are questions on how to represent fixed-point numbers in generated DSDL classes. In Python there is support for fixed-point arithmetics in the standard library; but what about libuavcan. We'll have to either cast fixed-point numbers to floats, which pretty much defeats the purpose, or we'll need to code up custom fixed-point arithmetic classes (I know that many modern MCU support fixed-point in hardware, but the solution has to be generic). Overall I'm not sure if this feature is worth the extra complexity, at least right now.
This issue is to attract relevant discussion and feedback.
In this thread over there there was also a related discussion on how to represent the elements of rotation quaternions in the most efficient and usable way; fixed-point types could be applied there greatly: OpenCyphal/public_regulated_data_types#34
The text was updated successfully, but these errors were encountered:
It would also be possible (and quite low effort) to do some experimentation with this without protocol support if we created DSDL definitions similar to the following
# Q16_8
uint16 integer_bits
uint8 fractional_bits
If it was found out that having these as native types would improve things a lot we could then upgrade them to first class citizens of dsdl and deprecate the experimentation types. This would leave the problem of using the fixed point types up to do application writer until native support was implemented.
@jschall once proposed to add those to the set of native DSDL types:
To which I said:
This issue is to attract relevant discussion and feedback.
In this thread over there there was also a related discussion on how to represent the elements of rotation quaternions in the most efficient and usable way; fixed-point types could be applied there greatly: OpenCyphal/public_regulated_data_types#34
The text was updated successfully, but these errors were encountered: