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

[Mark H. Harris]

On Friday, March 7, 2014 4:12:35 AM UTC-6, Steven D'Aprano wrote:

It's statements like this [ AI language ] that strongly suggest that you 
> don't really 
> understand how numbers work in computer programming. Or the practical 
> limitations of what is *possible*. And as soon as you start talking 
> about using an AI to decide what value the user intended, you've entered 
> crackpot territory. 


hi Steven,   fair enough.  When I refer to AI all I'm really stating is 
that some form of
computational intelligence needs to be employed beyond simple copying, &c. 
An 
intelligent decision needs to be used; that's all.  I'll stop using it (AI) 
, its not helpful.

Also, thank you for continuing to discuss this, it helps me grow, and it 
may lead to
an understanding or change. That's a good thing.

Here is the main post for today, from me, having slept on this and putting 
some things
back into historical timeframe.  Sometime before Py2.7.x it was not 
possible to promote
a binary float to a decimal float;  the system threw an exception (convert 
to string).

First,  that was the correct way to handle this issue from the inception of 
 decimal.Decimal. Throw
an exception and let everyone know that there is a problem; then let the 
user figure out how to
solve it.

It is not possible to correctly promote a binary float to a decimal float. 
The decision (in Py2.7?)
was to NOT throw an exception and to copy the binary float "exactly" into 
the decimal float.

Second, that was a bad decision--really--IMHO.  It was the wrong decision 
for two reasons 1) it denies what
is inherently poor about binary floating point representation in the first 
place, and 2) further 
compounds the problem by denying what is the benefit of using Decimal 
floating point in the
first place.  Not to mention, it gives the wrong answer;   from a decimal 
floating point perspective
it gives a VERY wrong answer.  (I realize most science and engineering 
solutions only require 
3-4 digits of accuracy---heck, I used to do that work on a slide rule). 

The point here is that binary floats should not be promoted to decimal 
floats by using "exact" copy
from binary float representation to decimal float representation.  This 
reminds me of the guys at
three mile island who turned off the alarms because they were annoying.

Steven,  I am going to try to go a little further without AI speak...   
What needs to happen is that 
binary floats need to be "correctly" promoted to decimal floats as 
appropriate.  This must not happen
by simple copying (that does not work).  There needs to be some policy in 
place that will correctly
"set" the decimal float value based on intelligence, not just simple 
copying. ( It may not be possible, or
it may require some funky   copy b float-->reduce context round-->set 
decimal .  I'm still thinking about it.

To make decimal the default, and to handle all numbers correctly giving the 
SciPy community the
ability to use binary floats easily too (without breaking codes) will 
require a complete rewrite of
numbers.Number  and maybe some other things.  Unifying the numbers concept 
in python is desirable 
but not practical at this point... I understand that; I get it. I am not 
asking anyone for this kind of "sweeping"
reform at this point... just think forward to the possibility.  Please.

Stefan's suggestion to set a trap is an excellent one, and I will play 
around with that a bit.  Although I was
initially asking for a method to more easily enter a literal decimal, and 
that is still important, I think really
what is called for here considering the history is to rescind the decision 
to promote binary floats to decimal
floats through an "exact" copy without flagging an error, or even giving a 
warning.

I am remembering my Zen of python... special cases aren't special enough to 
break the rules, although practicality
beats purity, errors should never pass silently.

Anyway, I know you wonderful guys will be thinking hard about this 
(evidenced by the discussion so far) and
I leave it in your competent hands.  I too will be thinking about it, 
perhaps adding some coding in the near future
that will be helpful. Again, I wish to thank Stefan Krah for his fine work 
on decimal.Decimal, without which none
of this discussion would be worth having in the first place.

Kind regards,
marcus



 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140307/d5fac344/attachment-0001.html>