prePEP: Decimal data type

[John Roth]

"Batista, Facundo" <FBatista at uniFON.com.ar> wrote in message
news:mailman.425.1067967319.702.python-list at python.org...
John Roth wrote:

#- Why is ANSI 274 significant? The reason I ask this is that this is
#- a ***floating point*** standard, and I don't think that we
#- particularly
#- care for decimal floating point.
#-
#- Floating point presumes limited precision. In other words,
#- if the actual
#- number (exclusive of the location of the decimal point) gets
#- too large,
#- the least significant part is ... thrown away. I don't want that.

If what you're saying is that, with a precision of 5...

45     --> 00045E+0
45321  --> 45321E+0
453211 --> 45321E+1

...you're right.

You may not like it, but that what it is: I'm following the General Decimal
Arithmetic Specification, see Mike Cowlishaw's work at
http://www2.hursley.ibm.com/decimal/.

[John Roth]
If I understand his work, that's not actually true. I may not
be understanding what he's saying, though.


#- The "other type" should be handled in the same way the decimal()
#- constructor would handle it.

[Facundo Batista]
¿Are you saying that if Decimal('45') is valid, Decimal('45') + '25' should
also be valid? Mmm... ugly, ugly.

[John Roth]
I can see how what I said could be interpreted that way, but I certainly
didn't mean it for strings.


#- > 1. The syntax should be ``Decimal(value)``.
#-
#- Lower case: "decimal(value, [scale factor])"


[Facundo Batista]
I thought that first letter in uppercase was good style for class names.

[John Roth]
It is. I was thinking in terms of a type, not a class. All the builtin
types start with lower class names.

[pre-pep]
#- > 4. The Context must be omnipresent, meaning that changes
#- to it affects all
#- >    the current and future Decimal instances.
#-

[John Roth]
#- No. The context should be selectable for the particular
#- usage. That is,
#- it should be possible to have several different contexts in
#- play at one
#- time in an application.


[Facundo Batista]
The concept of context is a "configuration place" surrounding the instances.


What you propose?

- the configuration (precision, flags, etc) is on by-instance basis
- you have different contexts, and a group of instances with each
context.

[John Roth]
More likely the second. My concern here is the usual one with
singletons and globals. Processing gets very messy when you
have to operate in several different modes or areas. See the
difficulties people get into with internationalization when they
have an application that has to operate in several different
jurisdictions at once, etc.

[Facundo Batista]
#- > 9. To have different kinds of rounding; you can choose the
#- algorithm
#- through
#- >    context:
#- > ...

[John Roth]
#- I think this is simply too much. I'd rather have a round()
#- method that
#- takes a *small* number of standard options, and otherwise takes a
#- function to do the rounding.


[Facundo Batista]
Again, this is the General Decimal Arithmetic Specification.

[John Roth]
I didn't understand that at the time I made the remark.

However, I think I'll emphasize my viewpoint one last
time, with the understanding that I'm not going to defend
it, comment on it, or even reply to comments on it unless
they show some interesting (to me, at least) understanding
of the issue I'm bringing up.

I think that many parts of this are attempting to shoot
mosquitoes with an elephant gun. A lot of the general
specification can be understood as things that make
*hardware* implementation of decimal floating point
simpler.

Much of this is from the binary floating point standards,
and historically Python has not implemented most of
it. It's depended on whatever the C compiler and library
gave it for floating point, leading to massive inconsistencies
in the treatment of infinities and NaNs, for example.

Unless Intel is already planning on putting this in
a near future version of their commercial chips,
it's going to be years before a hardware
implementation is of any concern.

As far as standardization is concerned, what I
get from Collishaw's site is that there are at least
three threads: a decimal floating point package that
he describes as "the core arithmetic" which seems
to have been used quite successfully for over two
decades; IEEE 854-1987, which is a generalization of
IEEE 754 (floating point) and the ongoing
revision of IEEE 754 with will merge the two. There
is also an ANSI standard, ANSI X3.274-1996.
Eric Price's module (referenced from Collishaw's site)
seems to be based on the latter, which will be
superceeded by the IEEE 754 revision, whenever it
comes out.

So we're planning
on doing a software implementation of a *draft* standard,
including very complicated facilities that I most
respectfully think are going to be of marginal
utility.

So be it.

John Roth


. Facundo