Greg Ewing wrote: > Mark Dickinson wrote: > >> But the Fraction type is going to mess this up: for Decimal + >> Fraction -> Decimal, I don't see any other sensible option than to >> convert the Fraction using the current context, since lossless >> conversion isn't generally possible. > > You could convert the Decimal to a Fraction, do the arithmetic > as Fractions, and convert the result back to Decimal using the > current precision. It gets rather messy implementation-wise if you do it that way. As Stefan pointed out, given the Decimal module's existing execution model of invoking "convert_other" to create a Decimal instance and then proceeding from there, it seems most straightforward to adopt the same approach for floats and Fractions (i.e. keep the changes to handle the new types inside the existing argument conversion algorithm). Such a change should make Decimal/float and Decimal/Fraction arithmetic work in a comprehensible way, albeit with double-rounding in the case of the latter. Comparisons would still need to be handled separately to avoid the lossy conversions. Regards, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4