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

[Mark H. Harris]

On Thursday, March 6, 2014 8:53:35 PM UTC-6, Andrew Barnert wrote:
>
>
> The only solution without changing Python is to train end-users to write 
> something correct, like Decimal('.1'). 
>

       hi Andrew,  yes, that is the problem.  And, to be fair, that example 
is not really the worst
because it might be expected that the user should know how to construct 
Decimals, and 
could be educated to construct them properly--> Decimal('0.1');  I concur.
       It is worse in these two scenarios (and others too):
            sqrt(.1)
            sin(.1)
       No one would expect that the user should know to quote the 
number---when is that ever done?
       QED   this is broken.  Again, we know perfectly well why its 
happening (I am not ignorant) but its not right. 

>
> The obvious solution for changing Python is to make it easier to create 
> Decimal numbers correctly and/or harder to create them incorrectly. For 
> example, a decimal suffix, as already proposed before this thread, would 
> completely solve the problem: 
>
>     >>> a = 1d 
>     >>> b = .1d 
>     >>> a+b 
>     1.1d 
>
  
       Yes, and at a bare minimum, that is the immediate change I have been 
asking for, for now; nothing more.

       I answered Guido's questions in hopes that he might be willing to 
dialogue --- not dismiss.
 

> You proposed that Python should handle numbers in an OO way, with numbers 
> being real objects, instances of classes, with a hierarchy including 
> abstract base classes; all of this is already there in Python. 
>

       Yes, it is... but its not designed to use decimal floating point by 
default... in order to do that the entire OO 
setup will have to be changed (what Guido called a sweeping reform).  Its 
like if we want to use floating point
decimals in the 21st century, using python, we have to duck tape modules on 
and then educate users in the
correct input of numbers.  Seems convoluted to me.  

>
> You went off on a long digression about how you could implement this using 
> the details of C++-style inheritance, when Python has a completely (and 
> more powerful) different solution to inheritance that has already been used 
> to solve this problem. 
>
  
        No, I did not.  I answered Guido's questions regarding context as 
clearly as I could. If python has a more powerful
way to handle this situation, gladly do it!  I will be happy as a clam to 
beta test or help with the coding.
 

>
> You proposed some complicated AI-based solution to solve the problem of 
> using separate number classes in a single expression, even though Python 
> (almost exactly like C++, in this case) has already solved that problem 
> with operator overloading. 
>

        No, I did not.  I suggested that unifying numbers in an (AI) way 
could solve this problem (conceptually) by 
regarding all numbers as *PythonNumbers. *Decimals should not only be 
default, they should be integrated, not
tacked on with duck tape. 

>
> (And note that Python is flexible enough that third-party libraries can 
> easily insert new types like quaternions, matrices, symbolic expressions, 
> etc. into the hierarchy in a way that's transparent to end users. I can 
> multiply a NumPy matrix of float64 values by the builtin in 2 just by 
> writing "m * 2", and it works exactly the way you'd want it to. It's hard 
> to imagine that would be even feasible with an AI-based solution, but with 
> the current design, that's the easiest part of NumPy.) 
>

       That's nice for you.  Because  sqrt(.23709)  does not behave as I 
expect, sadly, I have to train my users to enter  sqrt('0.23709'). 

>
> There are some ideas in your posts that are worth responding to, 
>

        Thank you.  If a user goes to the time and trouble to present an 
idea clearly, I would expect the responders 
to respect the effort and respond to the points that make sense.


      Andrew, I respect you for taking the time to dialogue, I appreciate 
it.  Thanks.

marcus 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140306/3c21e039/attachment-0001.html>