On Sat, Mar 20, 2010 at 6:54 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > Guido van Rossum wrote: >> I think we should seriously reconsider allowing mixed arithmetic >> involving Decimal, not just mixed comparisons. > > I'm glad I'm not the only one that started wondering that. I > wasn't quite game enough to actually suggest it though :) > >> There is one choice which I'm not sure about. Should a mixed >> float/Decimal operation return a float or a Decimal? I note that >> Fraction (which *is* properly embedded in the numeric tower) supports >> this and returns a float result in this case. While I earlier >> proposed to return the most "complicated" type of the two, i.e. >> Decimal, I now think it may also make sense to return a float, being >> the most "fuzzy" type in the numeric tower. This would also make >> checking for accidental floats easier, since floats now propagate >> throughout the computation (like NaN) and a simple assertion that the >> result is a Decimal instance suffices to check that no floats were >> implicitly mixed into the computation. > > To blend a couple of different ideas from the thread reboot together: > > I suggest a 'linearised' numeric tower that looks like: > > int -> Decimal -> Fraction -> float -> complex > > As Adam stated, this is a pragmatic tower stating which implicit > coercions are defined by the code, not a formal mathematical relationship. > > Note that this would involve adding mixed Fraction/Decimal arithmetic as > well as Decimal/float arithmetic.
Yes, that was my intention too. > I placed Decimal to the left of > Fraction to keep Decimal's dependencies clear and because Decimal -> > Fraction conversions appear straightforward (using power of 10 > denominators) without introducing the precision issues that would arise > in Decimal -> Fraction conversions. This is just wrong. Decimal is much more like float than like int or Fraction, due to its rounding behavior. (You cannot produce exact results for 1/3 using either Decimal or float.) Clearly the difficult decision is whether Decimal is between Fraction and float, or between float and complex (I prefer not to say "to the left/right of" since PEP 3141 orders the types in the opposite way as people have been doing here). Both are floating point types that sometimes produce rounded results (e.g. 1/3); the difference is that they use different bases and that Decimal has configurable precision when rounding. I would make float the last station before complex, whereas Mark would prefer Decimal to go there. I defer to Mark, who has thought a lot more about Decimal than I have. > I also like the idea of adding the decimal context signal that Facundo > suggests (e.g. under the name ImplicitCoercionToBinaryFloat). Yes, this is what I was trying to say (but didn't find the right words for). > So "quick and dirty don't need a perfect answer" operations end up with > ordinary binary floats, while more precise code can enable the signal > trap to ensure the calculation fails noisily if binary floats are > introduced. But does this break a tie for the relative ordering of Decimal and float in the tower? > Allowing implicit operations would also finally allow Decimal to be > registered with numbers.Real. Right, that's one aspect of what I meant by "embedded in the numeric tower". > Whatever we decide to do will need to be codified in a PEP though. > "Cleaning Up Python's Numeric Tower" or something along those lines. The cleanup is really just specific to Decimal -- int, Fraction and float are already properly embedded in the tower (PEP 3141 doesn't advertise Fraction enough, since it predates it). That we may have to change the __hash__ implementation for the other types is merely a compromise towards efficiency. >> The implementation of __hash__ will be complicated, and it may make >> sense to tweak the hash function of float, Fraction and Decimal to >> make it easier to ensure that for values that can be represented in >> either type the hash matches the equality. But this sounds a >> worthwhile price to pay for proper embedding in the numeric tower. > > And Mark appears to already have a good answer to that problem. Which I still have to review. (Mark, if you're there, could you make a brief post here on the mathematical definition of the new hash you're proposing, and why it is both efficient to compute and good (enough) as a hash function?) -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
