Re: [Python-Dev] New operations in Decimal
Doesn't matter. My intention for the module is to be fully compliant with the spec and all of its tests. Code written in other languages which support the spec should expect to be transferrable to Python and run exactly as they did in the original language. The module itself makes that promise: "this module should be kept in sync with the latest updates of the IBM specification as it evolves. Those updates will be treated as bug fixes (deviation from the spec is considered a compatibility, usability bug)" If I still have any say in the matter, please consider this a pronouncement. Tim, if you're listening, please chime in. Raymond
[Raymond Hettinger]
That was one of the major goals in agreeing to adopt an external standard for decimal: tedious arguments are left to the standard creators instead of clogging python-dev. Glad to see that's working exactly as planned ;-) I'm with Raymond on this one, especially given the triviality of implementing the revised spec's new logical operations. I personally wish they would have added more transcendental functions to the spec instead. That's bread-and-butter stuff for FP applications, while I don't see much use for the new "bit" operations. But if I felt strongly enough about that, I'd direct my concerns to the folks creating this standard. As slippery slopes go, this less than a handful of trivial new operations isn't steep enough to measure, let alone cause a landslide.
Tim Peters wrote:
I'm with Raymond on this one, especially given the triviality of implementing the revised spec's new logical operations.
After thinking about it some more, I'm also supporting maintaining full compliance (and withdrawing my suggestion of using a separate subclass for the logical operands). Be maintaining full compliance, it should be possible for a developer to prototype an algorithm using Python's decimal module and then use that exact same algorithm on any GDS compliant arithmetic logic unit. While *Python* has the luxury of other means of doing logical operations, an embedded algorithm with only a decimal ALU available may not be so fortunate. Regards, Nick. P.S. Spending an hour at work yesterday discussing some of the ways the bus architecture of a digital signal processor can affect algorithm performance may have had more than a little to do with my change of heart ;) -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Tim Peters wrote:
I'm with Raymond on this one, especially given the triviality of implementing the revised spec's new logical operations.
Exactly. I already implemented part of it, and took less than read this thread, ;). The cost of having it is lines of code in decimal.py. The benefit is that you can claim you comply to the standard. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
[Raymond Hettinger]
That was one of the major goals in agreeing to adopt an external standard for decimal: tedious arguments are left to the standard creators instead of clogging python-dev. Glad to see that's working exactly as planned ;-) I'm with Raymond on this one, especially given the triviality of implementing the revised spec's new logical operations. I personally wish they would have added more transcendental functions to the spec instead. That's bread-and-butter stuff for FP applications, while I don't see much use for the new "bit" operations. But if I felt strongly enough about that, I'd direct my concerns to the folks creating this standard. As slippery slopes go, this less than a handful of trivial new operations isn't steep enough to measure, let alone cause a landslide.
Tim Peters wrote:
I'm with Raymond on this one, especially given the triviality of implementing the revised spec's new logical operations.
After thinking about it some more, I'm also supporting maintaining full compliance (and withdrawing my suggestion of using a separate subclass for the logical operands). Be maintaining full compliance, it should be possible for a developer to prototype an algorithm using Python's decimal module and then use that exact same algorithm on any GDS compliant arithmetic logic unit. While *Python* has the luxury of other means of doing logical operations, an embedded algorithm with only a decimal ALU available may not be so fortunate. Regards, Nick. P.S. Spending an hour at work yesterday discussing some of the ways the bus architecture of a digital signal processor can affect algorithm performance may have had more than a little to do with my change of heart ;) -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Tim Peters wrote:
I'm with Raymond on this one, especially given the triviality of implementing the revised spec's new logical operations.
Exactly. I already implemented part of it, and took less than read this thread, ;). The cost of having it is lines of code in decimal.py. The benefit is that you can claim you comply to the standard. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
participants (4)
-
Facundo Batista -
Nick Coghlan -
Raymond Hettinger -
Tim Peters