Thanks, @taylor13 and @AndersMS, I, too, would favour A (_Using the scheme proposed above, requiring the data creator to set the computational_precision accordingly._).
I'm starting to think that the we need to be clear about `"decimal64"` (or 32, 128, etc.). I'm fairly sure that we only want to specify a precision, rather than also insisting/implying that the user should use [decimal64 floating-point](https://urldefense.us/v3/__https://en.wikipedia.org/wiki/Decimal64_floating-point_format__;!!G2kpM7uM-TzIFchu!lcE7w0fiRC1zhKFwOZuysOVeBDKIFjtHeow7J8Mk4RP8ARM0PsRnnarG_VyA20h1IKdMC3GQYJE$ ) format numbers in their calculations. The same issue would arise with `"binary64"`, although I suspect that most code would use [double precision floating-point](https://urldefense.us/v3/__https://en.wikipedia.org/wiki/Double-precision_floating-point_format__;!!G2kpM7uM-TzIFchu!lcE7w0fiRC1zhKFwOZuysOVeBDKIFjtHeow7J8Mk4RP8ARM0PsRnnarG_VyA20h1IKdMB4D0jVg$ ) by default. Could the answer to be to define our own vocabulary of `"16"`, `"32",` `"64",` and `"128"`? Or am I over complicating things? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/327*issuecomment-841186599__;Iw!!G2kpM7uM-TzIFchu!lcE7w0fiRC1zhKFwOZuysOVeBDKIFjtHeow7J8Mk4RP8ARM0PsRnnarG_VyA20h1IKdMy57_c-4$ This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
