PEP 242 Released

[Terry Reedy]

"Paul F. Dubois" <paul at pfdubois.com> wrote in message
news:mailman.985133006.5845.python-list at python.org...
> PEP: 242
> Title: Numeric Kinds
...
> Rationale
>
>     Currently it is impossible in every language except Fortran 90 to
>     write a program in a portable way that uses floating point and
>     gets roughly the same answer regardless of platform -- or refuses
>     to compile if that is not possible

I have the impression that there are issues other than precision required
to meet this goal (conversion, truncation, rounding, and standard math
function implementation).


> Kind Objects
>
>     Three new standard functions are defined in a module named
>     "kinds".  They return callable objects called kind objects.

While you here present the historical Fortran-precedent reason for the
name, it is, standing alone, uninformative as to its purpose.  I suggest
something like 'numbers', 'number_kinds', or 'numkinds', which would
tell/remind people than the module has something to do with numerical
computation.

This module, whatever the name, obviously has to be a builtin written in C
(or Java) rather than Python..  As such, it should still be as optional as
any other importable module.   And as such, you and whoever are free to
write a 'kinds' module for whatever platforms you like without anyone's
approval.  You mainly need agreement among yourselves on the function and
interface.  Taking this part of your proposal at face value, the PEP
approval process is not necessary.


> The Meaning of Literal Values
>
> ... Literal decimal values are of the greatest available binary
floating-point kind.

I strongly object to this.

First, this semantic change hijacks current syntax for the, to me, fairly
trivial purpose of avoiding writing a function call that 'kinds' should
provide (max_real(1.333) or whatever).  I do not see that it adds to the
functionality of the proposed computation machinery, and it would benefit
very few users, at potential cost to others.

Second, this change would make floating point computations more rather than
less variable.  Two versions of the interpreter compiled with the same
compiler for the same platform might no longer do floating point the same
way.   This contradicts part of the declared purpose of this PEP.

Third, despite the claim that this proposal "is backward compatible with
existing code", this part of it would break any existing code that depends
on floats being, for instance, 8 bytes (for memory allocation, for
instance).  It would also break code which depends on floats being the same
as a C double on the same machine (for interface with C routines, for
instance).

Fourth, the core interpreter would have to be aware, during compile time,
of the existence and contents of a 'kinds' module that *might* be imported
during runtime and which could well exist in a separate shared library.  To
make this semantic change to the core language, I believe that the
x_kinds() functions (and the machinery behind them) would have to be
obligatory built-in functions [like len()] rather than being segregated in
an optional import module.  This would be an entirely different proposal to
which I would, again, object.


> Concerning Infinite Floating Precision
>
>     This PEP does not propose the creation of an infinite precision
>     floating point type, just leaves room for it.  Just as int_kind(0)
>     returns the long kind object, if in the future an infinitely
>     precise decimal kind is available,

There already is such a module (real.py?).  If currently only writen in
Python, it could be converted to C for more speed.


> Coercion
>
>     In an expression, coercion between different kinds is to the
>     greater kind

If the kinds were written as extension classes rather than as extension
types, this would be taken care of with __coerce__() functions.  Again, no
changes to the core and no permissions needed.


> Open Issues
>
>     The assertion that a decimal literal means a binary floating-point
>     value of the largest available kind is in conflict with other
>     proposals about Python's numeric model.  This PEP asserts that
>     these other proposals are wrong and that part of them should not
>     be implemented.

Maybe both are wrong.


Summary of Response:

This PEP combines two somewhat disjoint proposals.

First is a proposed interface for a compiled extension class module that
would extend and parallel existing modules (such as real.py and the
Numerical Python work).  This can be implemented without changes to the
core and without anyone's approval.  This approach also leaves control of
the implementation in the hands of the proposer and collaborators.  So if
there is enough interest, go ahead and do it.

Second is a proposed semantic change in the core language which I believe
would require new builtin functions even though that was not directly
proposed.  Its purpose is to add syntactic sugar for the benefit of the
first proposal.  This change would complexify the language and probably
confuse beginners even more than they are now.  It would expand and slow
down the interpreter.  It could also break existing code.  Since it would
benefit only a small fraction of users (<1%?) and since the desired
functionality can be attained through current extension mechanisms, I see
no justification for imposing the costs on everyone else.

Terry J. Reedy