Conversation
|
It'd be good to accompany this proposal with a change in the README to explain the motivation, including the use cases. I don't understand where Decimal.Amount would be important to use, where the use case isn't subsumed by the Measure proposal. If we do include decimals with precision, should we adopt the IEEE 754-2008 data model, where the equivalent of precision can go positive as well as negative? |
The thinking is that the notions of precision here would be either number of significant digits or number of fractional digits. The 754 notion of positive precision wouldn't be supported, even if, under the hood, an implementation of Decimal.Amount might actually store a Decimal128 value with a positive quantum. |
Thinking about this more: it's somewhat cleaner to have this type separate from Measure, so that we don't have this null unit case. This is similar to how we have types like Temporal.PlainYearMonth rather than referring to the first of the month -- you want to know what data you're actually working with. So, I support this proposal, it seems like a good, minimal addition. |
|
Could we please fix the formatting first? reviewing this is not fun Prettier e.g. has a great markdown formatter |
Thanks for taking a look! I do have prettier and it doesn't have anything to say about the Markdown. Do you mean that the lines are too long? |
|
My grip is that the formatting should be added first as a separate PR, that way we can review the actual changes here Yes prettier can format md files: |
* Define `Decimal128.Amount` * Say "Decimal" rather than "Decimal128" and name section IDs consistently with `sec-decimal-*` * Use prettier * Add discussion of `Decimal.Amount` to the README
4 participants
This PR reflects current thinking about how to handle the i18n aspects of decimals.
We also clean up the README using prettier.