The section on rational numbers for expressions in the V1 DSDL specification gives me pause. I’m concerned that platform differences in floating point representations could lead to the sort of subtle and hard to find bugs that result in a spacecraft impacting planetary bodies at speed (http://exploration.esa.int/mars/59176-exomars-2016-schiaparelli-anomaly-inquiry/). In the current draft we are saying that only IEEE 754 numbers can be used but IEEE allows for several different levels of precision and many dynamic languages (like Python) provide no guarantee for the bit depth used on a given platform.
One may simply say “smart developers should understand precision loss in floating point calculations” which is true. My concern, raised by this response, is these calculations are performed quietly by several different DSDL processors which most developers will take for granted. However, my larger concern is that we are performing independent calculations on both sides of a wire to generate constants. The concept of a constant implies that it abstractly exists as a immutable, singular value (i.e. the implication is stronger than equality suggesting that two representations of a given constant physically represent the same object). Because we do not transmit the constant itself, because we declare a given DSDL type of the same version to be bit compatible, and because c is c (with apologies to Leibniz) most developers will simply assume
REMOTE_CONSTANT_A == LOCAL_CONSTANT_A without expecting two to be different based on resolution loss.
Because of this, and because UAVCAN is targeting systems where this sort of thing may be more than academic (i.e. Mars is very far away and spacecraft go very fast) I propose we require that constants are always calculated by a given DSDL processor in a way that provides a deterministic binary result that will always be == between any two processors.
The easy way to do this is to disallow floating point numbers in expressions. The more complex way is to to force a given bit-depth for the IEEE floating point values used internally. This latter approach may make building compliant python processors difficult.
From Section 3.3.1 in the v1 draft:
The associated loss of information inherent to IEEE 754 representations is assumed to be acceptable.