[Python-ideas] Python Numbers as Human Concept Decimal System
Mark H. Harris
harrismh777 at gmail.com
Thu Mar 6 23:23:44 CET 2014
On Thursday, March 6, 2014 11:48:53 AM UTC-6, Guido van Rossum wrote:
{snip}
hi Guido, thanks for your responses, your candor, and your kindness; I
think
dialogue will work, and I promise to keep the rhetoric to a bare minimum,
if at all. :)
There really are only two questions I am going to try to answer here, and
some of
the answer goes back to Stefan's (and others) questions as well, so I hope
its helpful.
> So, by context you really seem to be referring to some specific state of
> the program. Perhaps you are even talking about extending the existing
> notion of numeric context used by Python's Decimal type. But it's not very
> clear because "you change the context" is also a common term for changing
> the topic of a discussion.
>
This is what I mean by "context," for this entire discussion, mostly
having to do with
Decimal and the "context manager" and these two lines:
getcontext()
with localcontext(ctx=None) as context_manager
Allow me to back up a bit... the pdeclib module was not difficult
for me because of the
mathematics (no brag) I can code transcendental functions in my sleep. The
hard part of
that project last week was coming to grips with the context manger, and the
parameterization
of context attributes in the Decimal class. Back in the day when I did this
work for Rexx at IBM
I used NUMERIC DIGITS and NUMERIC FUZZ to emulate (in a crude way) what
Decimal is
doing correctly with its context, with the context manager. I credit Oscar
Benjamin for helping
me get up to speed with this concept (and I am so glad he did too, because
its key for this
entire discussion.
Before we go on, allow me to explain my italics of *Number *and
*PythonNumber.* These are
each an abstract base class. They are a class that is never instantiated,
but from which all
other "numbers" are derived as objects. (more below)
> I'm sorry, but I am *still* unsure about what you mean by "context".
> Python does not need a context object to switch between complex and real
> number processing -- it's all done through operator overloading.
>
(more on this below, but I am thinking beyond overloading/
actually, virtual functions and templates)
> Actually, modern Python is considered object-oriented.
>
Thank you. This has everything to do with this discussion, but
allow me to take a humorous
break and relate an anecdote... I have had numerous discussions with T.R.
and C.A and S.D. and
others where in the end python was object based. Ha! Nope, you have seen
it right here, the
BDfL says its "object oriented," and that's the end of the argument! (ok,
tiny rhetoric)
>
> Unifying the
>> number system on a computer does not have to be grounded in paradigms
>> that serviced the
>> industry (and academy) for the past 40 years;
>>
> {snip}
>
> Now you've got a specific proposal and we can discuss pros and cons. This
> is a topic that comes up occasionally and it is indeed a pretty interesting
> trade-off. I suspect the large (and fast-growing) SciPy community would
> prefer to keep binary floating point, because that's what their libraries
> written in Fortran or C++ want, and extra binary/decimal conversions at the
> boundaries would just slow things down. But I'm really speculating here --
> maybe they don't need high-performance conversion between binary and
> decimal, since (perhaps) they may do their bulk I/O in C++ anyway. Or maybe
> it varies per application.
>
Here is the main response for this discussion, and I will endeavor
to keep the
rhetoric down, I promise.
This may even be easier to accomplish in 3.x without breaking
anyone, or any third party software either; depends
In my view numbers are objects (like circles, squares and triangles;
in polymorphism discussions).
Numbers are nothing more than objects which have "contexts" just like
circles and squares and triangles
are nothing more than objects that have "contexts". In the following
discussion think in terms of object
oriented (as in Grady Booch) rather than any specific language--- and
certainly not python syntax. um,
think C++ for now, if you must think of any. A *Number *is an abstract
base class with "context" attributes
and pure virtual functions--- it will never be instantiated---and *PythonNumber
*will derive from that; also
an abstract base class. Here is the Class hierarchy I am proposing:
*Number*
*PythonNumber*
Decimal
Real <======= this is the default
BinaryIEEE85
Real_b
&c (...) omitted for clarity
Complex
Quaternion
Rational
Fraction
&c--------------------------------------------------
Well, there it is. The idea is that any function or method that
takes a *Number* reference
or a *PythonNumber *reference does not have to interrogate what type of
*Number* it is... it just
works (why?) glad you asked, because of polymorphism and a three pointer
hop down a virtual
function table!
If a function or method gets a *Number *parm in as in method(num)
then to get the pretty
print representation of the number is simply num.pretty_print(), or
to get an evaluation
of the number is num.eval(), or to get the string rep of the number is
num.str()... and on and on.
The point is that other parts of the system no longer need to know what
"type" of number object
it is, the right code gets called because of virtual functions, operator
overloading, and the beautiful
virtual function table (all under the covers, not MAGIC, but polymorphism).
Python at present is disjointed when it comes to number as a
concept. In my view numbers
need to be objects, and the Class hierarchy (see my simplified version
above) needs to unify numbers
across the python boards (so to speak) so that "types" are only important
to the implementors, and
so that adding new "types" is easy, concise, and coherent.
I realize that this suggestion is over the top in terms of size and
weight (Stefan's concern above).
But not really, when you think of conceptualizing the unification of
numbers under *Number *and
*PythonNumber *. There may be other kinds of numbers too, besides these...
like maybe *GmpyNumber*
of *BC_Number*, or others.
The bottom line is that we have an object oriented language in front
of us that has the
software engineering advantages which would allow this kind of hierarchy
and conceptualization
of a unified number system. Let's leverage our technology for mutual
advantage across python
communities?
Thanks for your consideration,
Sincerely,
Kind regards,
marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140306/3bbe3c10/attachment-0001.html>
More information about the Python-ideas
mailing list