[Python-ideas] Python Numbers as Human Concept Decimal System

[Guido van Rossum]

On Thu, Mar 6, 2014 at 12:14 AM, Mark H. Harris <harrismh777 at gmail.com>wrote:

> On Wednesday, March 5, 2014 11:56:02 PM UTC-6, Guido van Rossum wrote:
>>
>> Do you actually have a degree in math, or do you just remember your high
>> school algebra?
>>
>
>   hi Guido,  ouch.   Its a story, glad you asked.  My first trip to
> college 1974-1977 [...]
>

I must have hit a nerve -- I wasn't requesting a transcript! :-) A simple
"I dropped out of math in college to pursue a career in programming" would
have been sufficient (my own story is pretty similar :-).


> We might agree to stick with the discussion, if you're are willing, and
> stay away from *ad hominem*
> attacks, nor credential bashing. A person either knows what they are
> doing, or they don't. And if
> they are willing to contribute, why knock it, or them?
>

I was asking because I am having a hard time getting your point, and it
feels like you keep repeating it without clarifying it.


> The numbers in math usually are quite strictly typed: whole theories only
>> apply to integers or even positive integers, other things to all reals but
>> not to complex numbers.
>>
>
> Everyone keeps making the points noted above!  Yes, I know... concur~
>     Guido, all data types in most computer high level languages
> are all very strictly statically bound also.
>

I'm not sure that that description applies to Python; it sure doesn't match
how I *think* about numbers in Python.


> So what?  You know this better
> than anyone, because you have taken so much abuse from trolls about it
> over the
> years.
>

Actually, I haven't -- I can smell a troll a mile away and just mute the
conversation.


> We all know that the best way to handle name binding is dynamically.
>

That's your opinion. There are pros and cons and both static and dynamic
binding have their place.


> And that was a paradigm shift, was it not?
>

I've never claimed such a hyperbole.


> Go take a look at Rexx. It has NO types. None.
> Not at the surface, anyway. Everything to the user of the language is a
> string. This is
> even true for most of "object" Rexx too. *Numbers *are just strings of
> characters that
> are parsed and interpreted by Rexx as valid *Rexx Numbers*.
>

Why do you italicize this?


> It works. There is no
> real point in arguing that its a bad idea, because it served the Rexx
> community for
> many years... even now, Rexx is not dead. Yes, under the covers (not
> magic) a complex
> number is going to be handled differently than a real number.  Yeah, what
> is your point?
> They are handled differently in my TI 89 too... so what,  I change the
> context on the 89
> and now I'm doing complex number math (not often, I might add).
>

By "context", here, do you mean some specific state in the computer, or are
you referring to a different way of thinking about it (i.e. in your head)?


> If I set the context for
> reals, then now I'm doing real math... it really is not that difficult.
>

So I suppose depending on how you set the context, the square root of -1
either returns a complex number, or raises an error? And comparisons are
right out once your context is set for complex numbers? Or are they still
allowed when the imaginary part is exactly zero? (What if it is nearly
zero?)


> Think about this for just
> a minute. I have used complex math exactly three times in my life.  I used
> it in high school
> to study the concept in math analysis. I used it in my EE classes...
> electrical engineers
> get a lot out of complex numbers.  And I used it when I was interested in
> the Mendlebrot
> set many years ago when it was cool to plot the famous fractal on early
> cga screens.
> When was the last time you used complex numbers?  When was the last time a
> bank, or
> a hospital, or Montgomery Wards used complex numbers?  If someone needs
> complex
> numbers, Python could change the context "dynamically" and move through
> the problem set.
> Why should the user need to "manually" change the context if  (AI)  could
> change it for them
> on-the-fly?  Just try to get a feel for the question, and stop with trying
> to beat me up on
> my credentials.
>

I still don't understand the question. Can you be more precise instead of
using more rhetoric? Is your point just that you don't want to have to deal
with complex numbers? That's fine, and it's already (mostly) how Python
works -- you must use a complex literal or the cmath module before any
complex numbers appear (the exception is that x**y returns a complex number
when x is negative and y is not a whole number -- but arguably that's the
best answer).


> (And what about quaternions? Or various infinities? :-)
>>
>
> What about quaternions?  If you extend the complex number system you
> change the context. That's not hard...
>

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.

You would not expect the context for "reals" processing to be the same for
> the context of
> processing three dimensional space with pairs of complex numbers, would
> you?
>

Actually I'm not sure I *need* a context for this. In Python things like
this are usually just solved through a combination of operator overloading
and dynamic binding, so that e.g. x*y can be a number when x and y are
numbers, but it can mean a vector product of some sort if x and/or y are
vectors.


> Python
> does complex number processing now. But that is a very specialized
> category of use
> case that requires special context and (under the covers) typing relevant
> to complex number
> pairs. The context can change "dynamically" to suit the problem set,
> that's all I'm saying.
>

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.


> I am not saying in all of my dreaming here that typing is not important
> (down under). Python is
> called an object based language, yes?  Not object oriented, right?
>

Actually, modern Python is considered object-oriented. I called it
object-based in a *very* early stage, when there was no class statement in
the language. But IIRC it was added before the first public release (or
soon after), although another round of improvements in this area happened
in the early 2000s (eradicating most of the differences between classes
defined by C and Python code).


> But we all know that down
> under the covers (not magic) python uses Classes and instances of
> classes--objects. We
> don't pretend that what makes object based languages work is magic? do we?
>

"We"?


> 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; mostly because memory was
> expensive and
> processing was slow.  I suggest that if memory had been cheap, back in the
> day, and processing
> had been very fast (as it is today) IEEE 754 1985 floats and doubles would
> never have been
> used. We would have used Decimal floating points right from the get-go.
> Initially, that really is
> all I'm asking for on the outset--- lets move to default decimal floating
> point arithmetic for real
> numbers processing.
>

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.


> In the future I am thinking about systems of languages that interact with
> human speech; understanding
> *spoken number* just like they will understand *symbol number.* There is
> really no reason (other
> than paradigm) that this would not be possible either.
>

This is the kind of talk that I wish we could keep out of the python-ideas
list. (Except for the symbolic algebra, for which various third-party
Python libraries already exist.)


> Otherwise, Guido, we might all of us just continue to use C and code up
> our statically bound types by
> hand using nothing but int, long, float, and double.
>
> Its time to innovate.
>

Rhetoric again.


> Kind regards, BDfL,
>
> marcus
>

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140306/5f15a08a/attachment-0001.html>