Re: [Python-Dev] New operations in Decimal
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/ ___ 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
Re: [Python-Dev] New operations in Decimal
Tim Peters wrote: [Raymond Hettinger] ... 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. 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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] New operations in Decimal
Terry Reedy wrote: Raymond Hettinger [EMAIL PROTECTED] wrote in message | While I question the sanity of the spec writers in this case, I do trust that | overall, they have provided an extremely well thought-out spec, have gone | through extensive discussion/feedback cycles, and have provided a thorough | test-suite. It is as good as it gets. I had the same opinion until I saw the logic stuff. The only rationale I can think of for such a thing is that maybe they're trying to accommodate the possibility of a machine built entirely around a hardware implementation of the spec, that doesn't have any other way of doing bitwise logical operations. If that's the case, then Python clearly has no need for it. -- Greg ___ 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
Re: [Python-Dev] New operations in Decimal
The only rationale I can think of for such a thing is that maybe they're trying to accommodate the possibility of a machine built entirely around a hardware implementation of the spec, that doesn't have any other way of doing bitwise logical operations. If that's the case, then Python clearly has no need for it. 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 ___ 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
Re: [Python-Dev] New operations in Decimal
Greg Ewing wrote: Terry Reedy wrote: I had the same opinion until I saw the logic stuff. The only rationale I can think of for such a thing is that maybe they're trying to accommodate the possibility of a machine built entirely around a hardware implementation of the spec, that doesn't have any other way of doing bitwise logical operations. If that's the case, then Python clearly has no need for it. That is my interpretation of the spec as well. I'd prefer to see a decimal.BitSequence subtype added to the module rather than lumping the functionality into the main decimal.Decimal type. The specification itself makes it clear that these operations are not supported for the full range of decimal numbers: The logical operations (and, invert, or, and xor) take logical operands, which are finite numbers with a sign of 0, an exponent of 0, and a coefficient whose digits must all be either 0 or 1. The footnote attached to the quoted sentence also makes it clear that this is about still being able to do binary logic operations with a purely decimal ALU: This digit-wise representation of bits in a decimal representation has been used since the 1950s; see, for example, Binary and truth-function operations on a decimal computer with an extract command, William H. Kautz, Communications of the ACM, Vol. 1 #5, pp12-13, ACM Press, May 1958. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] New operations in Decimal
Greg Ewing [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | The only rationale I can think of for such a thing is | that maybe they're trying to accommodate the possibility | of a machine built entirely around a hardware implementation | of the spec, that doesn't have any other way of doing | bitwise logical operations. That is what I meant by 'commercial strategy' in my previous post. The IBM site pages mentioned the possibility of a decimal-based processor back when I read it, which was back when the decimal module was being developed. It would fit both their decades of product history and their name (*business machines*). Nothing nefarious, exactly, .. | If that's the case, then Python clearly has no need for it. but think it should at least be discussed whether to add useless functions while somewhat useful functions are being deleted and other useful functions are being denied entry. Terry Jan Reedy ___ 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
Re: [Python-Dev] New operations in Decimal
The only rationale I can think of for such a thing is that maybe they're trying to accommodate the possibility of a machine built entirely around a hardware implementation of the spec, that doesn't have any other way of doing bitwise logical operations. Nonsense. The logical operations are there for environments where decimal is the only available numeric type. IIRC, this is how Rexx works with decimal implemented around strings where what you type is what you get. Raymond ___ 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
Re: [Python-Dev] New operations in Decimal
[Raymond Hettinger] ... 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. 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. ___ 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
Re: [Python-Dev] New operations in Decimal
Facundo Batista [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Nick Maclaren wrote: | | Am I losing my marbles, or is this a proposal to add the logical | operations to FLOATING-POINT? | | Sort of. This is a proposal to keep compliant with the General Decimal | Arithmetic Specification, as we promised. | | http://www2.hursley.ibm.com/decimal/ I oppose adding this illogical nonsense to Python. Who would ever use it? An intention and promise to keep compliant with a *decimal arithmetic* standard cannot sanely be a blind, open-ended promise to add whatever *non-decimal* functions that IBM puts where they do not belong as part of its commercial strategem. To me, the same would go for any other standard similarly twisted. Supposed IBM defined a mapping between pairs of decimal digits and an ascii subset (printables and the few control chars actually used by most people). Suppose IBM further defined string functions for decimal nuumbers intrerpreted as strings. An example might be 'capitalize', such that capitalize(010203) == 010203 capitalize(121110) == 424140 # 10='a', 40 = 'A', etc And suppose that IBM shoved this into the decimal standard the same way it did with the decimal-interpreded-as-binary-string' functions. Would you really add them to be 'compliant' with IBM? If you really do put them in, turn 'invert' into 'prefix_not'. For the prefix, please not 'logical' but something like 'lu' (for 'lunatic') or, less provocatively, 'ibm'. Terry Jan Reedy ___ 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
Re: [Python-Dev] New operations in Decimal
| Am I losing my marbles, or is this a proposal to add the logical | operations to FLOATING-POINT? | | Sort of. This is a proposal to keep compliant with the General Decimal | Arithmetic Specification, as we promised. | | http://www2.hursley.ibm.com/decimal/ I oppose adding this illogical nonsense to Python. Who would ever use it? Doesn't matter. What is more important is that we provide a module that is fully compliant with the specification and passes all of its tests. The value is in the compliance, not in the relative value of individual parts of the spec. This is somewhat akin to modules supporting RFC specs or internet protocols. It is more important to be standard than it is to pick and choose the parts you like. The same is true of writing ANSI spec compilers -- you write to the spec, not to the language you wish had been adopted. While I question the sanity of the spec writers in this case, I do trust that overall, they have provided an extremely well thought-out spec, have gone through extensive discussion/feedback cycles, and have provided a thorough test-suite. It is as good as it gets. Raymond Hettinger ___ 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
Re: [Python-Dev] New operations in Decimal
Raymond Hettinger [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | I oppose adding this illogical nonsense to Python. Who would ever use it? | | Doesn't matter. What is more important is that we provide a module that is | fully compliant with the specification and passes all of its tests. The value | is in the compliance, not in the relative value of individual parts of the spec. To repeat my further question: if IBM adds string functions or anything else to the 'decimal arithmetic' spec, should we unthinkingly add them also? Is there there no limit to the size of the camel that comes in with the nose? Suppose the next edition of the spec contains decimal versions of the functions in numpy (BLAS, LINPACK, FTTPACK, and so on). Should they be included in the standard lib even while numpy is excluded. We supposedly have a standard for additions to the standard lib. I cannot think of any other module being admitted with what amounts to an unlimited blank check for further additions. | This is somewhat akin to modules supporting RFC specs or internet | protocols. It is more important to be standard than it is to pick and choose | the parts you like. My impresssion from reading this list is that some of the modules supporting such specs/protocols are not complete and that there has been some picking and choosing. Wasn't there recently discussion about DOM level compliance? In any case, once RFCs are finalized, they does not, as far as I know, grow with additions, sane or crazy. Nex stuff goes in a new RFC which can be evaluated separately against our normal criteria for stdlib additions. | While I question the sanity of the spec writers in this case, I do trust that | overall, they have provided an extremely well thought-out spec, have gone | through extensive discussion/feedback cycles, and have provided a thorough | test-suite. It is as good as it gets. I had the same opinion until I saw the logic stuff. But I have known IBM and its products, good and bad, for over 40 years, so it does not surprise me when they act somewhat imperialistically for commercial advantage. This strikes me as likely such a case. But I may give M.C. a chance to better educate me. In the meanwhile here is my suggestion. Segregate the binary digit functions, and anything else of their ilk, in a separate module, say decimal_extras, and make it available on PyPI. In decimal, add try: from decimal_extras import * except ImportError: pass Then the tests could pass without junking up the stdlib with stuff that would never even be proposed, let alone accepted. And should I be proved wrong, and these functions find favor with the community and usage in production code, then they can be seamlessly moved into the stdlib and the decimal module after having met the test of other additions. Terry Jan Reedy ___ 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
Re: [Python-Dev] New operations in Decimal
We supposedly have a standard for additions to the standard lib. I cannot think of any other module being admitted with what amounts to an unlimited blank check for further additions. xml.dom.minidom, xml.sax, posix, htmlentitydefs, Tkinter. Regards, Martin ___ 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
Re: [Python-Dev] New operations in Decimal
On 27 Apr, 2007, at 20:39, Facundo Batista wrote: - and (and), or (or), xor (xor) [CD]: Takes two logical operands, the result is the logical operation applied between each digit. and and or are keywords, you can't have methods with those names: def and(l, r): pass File stdin, line 1 def and(l, r): pass ^ SyntaxError: invalid syntax Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: [Python-Dev] New operations in Decimal
Ronald Oussoren [EMAIL PROTECTED] wrote: On 27 Apr, 2007, at 20:39, Facundo Batista wrote: - and (and), or (or), xor (xor) [CD]: Takes two logical operands, the result is the logical operation applied between each digit. and and or are keywords, you can't have methods with those names: Am I losing my marbles, or is this a proposal to add the logical operations to FLOATING-POINT? I may have missed a previous posting, in which case I apologise, but this is truly mind-boggling. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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
Re: [Python-Dev] New operations in Decimal
Ronald Oussoren wrote: - and (and), or (or), xor (xor) [CD]: Takes two logical operands, the result is the logical operation applied between each digit. and and or are keywords, you can't have methods with those names: You're right. I'll name them logical_and, logical_or, and logical_xor. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
Re: [Python-Dev] New operations in Decimal
Nick Maclaren wrote: Am I losing my marbles, or is this a proposal to add the logical operations to FLOATING-POINT? Sort of. This is a proposal to keep compliant with the General Decimal Arithmetic Specification, as we promised. http://www2.hursley.ibm.com/decimal/ Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
Re: [Python-Dev] New operations in Decimal
Facundo Batista [EMAIL PROTECTED] wrote: Am I losing my marbles, or is this a proposal to add the logical operations to FLOATING-POINT? Sort of. This is a proposal to keep compliant with the General Decimal Arithmetic Specification, as we promised. http://www2.hursley.ibm.com/decimal/ Or, more precisely: http://www2.hursley.ibm.com/decimal/damisc.html All right. Neither you nor I have lost our marbles, but the authors of that assuredly did. It's totally insane. And implementing it for a software emulation of that specification built on top of a twos complement binary integer model is insanity squared. But promises are promises and mere insanity is not in itself an obstacle to political success I shall attempt to forget that I ever asked the question :-) Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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
[Python-Dev] New operations in Decimal
The following are the new operations in the decimal module that we'll be available according to the last published specification. I wrote here the proposed name by me, the original name between parenthesis, where it will be located between square brackets (C for context and D for the decimal object itself), and a small description of the operation (I specially trimmed the verbose special cases from the description, if you want an exact explanation of what does each, read the spec). Note that always it says how many operands it takes. The number implies you're calling it through the context. If called through Decimal, you have to substract one from it (as the first operand will be the number itself in this case). Enjoy it, and any feedback is very appreciated, :) - compare_signal (compare–signal) [CD]: Takes two operands and compares their values numerically (pretty much like compare(), but all NaNs signal, with signaling NaNs taking precedence over quiet NaNs. - fma (fused-multiply-add) [C]: Takes three operands; the first two are multiplied together, using multiply, the third operand is then added to the result of that multiplication, using add, all with only one final rounding. - ln (ln) [CD]: Takes one operand, and the result is the natural (base e) logarithm of the operand. - log10 (log10) [CD]: Takes one operand, and the result is the base 10 logarithm of the operand. - max_mag (max–magnitude), and min_mag (min-magnitude) [CD]: Takes two operands and compares their values numerically with their sign ignored. - next_minus (next–minus) [CD]: Takes one operand and the result is the largest representable number that is smaller than the operand. - next_plus (next–plus) [CD]: Takes one operand and the result is the smallest representable number that is larger than the operand. - next_toward (next–toward) [CD]: Takes two operands and the result is the representable number closest to the first operand (but not the first operand) that is in the direction towards the second operand, unless the operands have the same value. - to_integral_exact (round-to-integral-exact) [C]: Takes one operand. It is similar to the round–to–integral–value (the old to_integral), with the difference the now Inexact and Rounded flags are allowed in the result. The following operations appear in a new section of the specification called Miscelaneous Operations. Between these are logical operations that take logical operands, which are finite positive non-exponent numbers with a coefficient whose digits must all be either 0 or 1. - and (and), or (or), xor (xor) [CD]: Takes two logical operands, the result is the logical operation applied between each digit. - canonical (canonical) [CD]: Canonical takes one operand, returns the same Decimal object, as we do not have different encodings for the same number. - number_class (class) [CD]: Takes one operando, returns an indication of the class of the operand, where the class is one of the following: sNaN, NaN, –Infinity, –Normal, –Subnormal, –Zero, +Zero, +Subnormal, +Normal or +Infinity. - compare_total (compare–total) [CD]: Takes two operands and compares them using their abstract representation rather than their numerical value (a total ordering is defined for all possible abstract representations). - compare_total_mag (compare–total–magnitude) [CD]: Takes two operands and compares them using their abstract representation rather than their numerical value, with their sign ignored and assumed to be 0. - copy_abs (copy-abs) [CD]: Takes one operand, returns a copy of it with the sign set to 0. - copy_negate (copy-negate) [CD]: Takes one operand, returns a copy of it with the sign inverted. - copy_sign (copy–sign) [CD]: Takes two operands, returns a copy of the first operand with the sign equal to the sign of the second operand. - invert (invert) [CD]: Takes one logical operand, the result is the digit-wise inversion of the operand. - is-canonical (is–canonical) [CD]: Takes one operand, returns 1 if the operand is canonical; otherwise returns 0. - is_finite (is–finite) [CD]: Takes one operand, returns 1 if the operand is neither infinite nor a NaN, otherwise returns 0. - is_infinite (is–infinite) [CD]: Takes one operand, returns 1 if the operand is an Infinite, otherwise returns 0. - is_nan (is–NaN) [CD]: Takes one operand, returns 1 if the operand is a quiet or signaling NaN, otherwise returns 0. - is_normal (is–normal) [CD]: Takes one operand, returns 1 if the operand is a positive or negative normal number, otherwise returns 0. - is_qnan (is–qNaN) [CD]: Takes one operand, returns 1 if the operand is a quiet NaN, otherwise returns 0. - is_signed (is–signed) [CD]: Takes one operand, returns 1 if the sign of the operand is 1, otherwise returns 0. - is_snan (is–sNaN) [CD]: Takes one operand, returns 1 if the operand is a signaling NaN, otherwise returns 0. -
