Earlier quoted context omitted.
The best of both worlds, at least in my opinion, would be to write a float as a polynomial in two parts (where either part alone is still a float): an integer part with an optional scientific-notation exponent; and a fractional part, where the fraction's denominator is always a power of two. So 5e3 is a float; 3/8 is a float; and 5e3+3/8 is a float. Each cleanly and exactly representing particular IEEE754 values, whi…
That's not particularly user-friendly though: at least for CG/VFX software (where USD came from and is designed for), non-technical (at least in terms of understanding IEEE floats) people like artists often want to look at the values to verify stuff for 'debugging' (i.e. is the software tool I'm using actually exporting the correct values I selected in the UI params panel). Having to do any form of interpretation (ev…
Most OOP languages have a "debug print" or "shell inspect" method that the programmer can override, where by default the method will print something that's valid language syntax, but where the overrides aren't required or expected to be such, and instead should concisely describe the object at the expense of being reloadable. These same languages usually also have support for custom serializers for text-based serialization formats like JSON. The serializer implementation for JSON, and the serializer implementation for "shell inspect", are rarely identical.
I think what a CG/VFX artist would want here, isn't that the canonical textual file-format "for import" gives them decimal-serialized floats; but rather that they have the option to "inspect" the project, resulting in a view that looks like e.g. https://www.tonymacx86.com/media/ioregistryexplorer.187440/f... — an hierarchically-expandable "shell inspect" of the project. It makes perfect sense for the floats in such a read-only debugging-oriented view to be rendered in decimal (esp. if a raw canonical binary-data representation is given in parentheses beside the rendered value.)