[Python-Dev] Revised decimal type PEP

[M.-A. Lemburg]

Michael McLay wrote:
> 
> On Tuesday 31 July 2001 04:30 am, M.-A. Lemburg wrote:
> > How will you be able to define the precision of decimals ? Implicit
> > by providing a decimal string with enough 0s to let the parser
> > deduce the precision ? Explicit like so: decimal(12, 5) ?
> 
> Would the following work?  For literal type definitions the precision would
> be implicit.  For values set using the decimal() function the definition
> would be implicit unless an explicit precision definition is set.  The
> following would all define the same value and precision.
> 
>    3.40d
>    decimal("3.40")
>    decimal(3.4, 2)
> 
> Those were easy.  How would the following be interpreted?
> 
>    decimal 3.404, 2)
>    decimal 3.405, 2)
>    decimal(3.39999, 2)

I'd suggest to follow the rules for the SQL definitions
of DECIMAL(,).
 
> > Also, what happens to the precision of the decimal object resulting
> > from numeric operations ?
> 
> Good question.  I'm not the right person to answer this, but here's is a
> first stab at what I would expect.
> 
> For addition, subtraction, and multiplication the results would be exact with
> no rounding of the results.  Calculations that include division the number of
> digits in a non-terminating result will have to be explicitly set.  Would it
> make sense for this to be definedby the numbers used in the calculation?
> Could this be set in the module or could it be global for the application?
> 
> What do you suggestion?

Well, there are several options. I support that the IBM paper
on decimal types has good hints as to what the type should do.
Again, SQL is probably a good source for inspiration too, since
it deals with decimals a lot.
 
> >
> > >     A decimal number can be used to represent integers and floating point
> > >     numbers and decimal numbers can also be displayed using scientific
> > >     notation. Examples of decimal numbers include:
> > >
> > >     ...
> > >
> > >     This proposal will also add an optional  'b' suffix to the
> > >     representation of binary float type literals and binary int type
> > >     literals.
> >
> > Hmm, I don't quite grasp the need for the 'b'... numbers without
> > any modifier will work the same way as they do now, right ?
> 
> I made a change to the parsenumber() function in compile.c so that the type
> of the number is determined by the suffix attached to the number.  To retain
> backward compatibility the tokenizer automatically attaches the 'b' suffix to
> float and int types if they do not have a suffix in the literal definition.
> 
> My original PEP included the definition of a .dp and a dpython mode for the
> interpreter in which the default number type is decimal instead of binary.
> When the mode is switch the language becomes easier to use for developing
> applications that use decimal numbers.

I see, the small 'b' still looks funny to me though. Wouldn't
1.23f and 25i be more intuitive ?

> > >     Expressions that mix binary floats with decimals introduce the
> > >     possibility of unexpected results because the two number types use
> > >     different internal representations for the same numerical value.
> >
> > I'd rather have this explicit in the sense that you define which
> > assumptions will be made and what issues arise (rounding, truncation,
> > loss of precision, etc.).
> 
> Can you give an example of how this might be implemented.

You would typically first coerce the types to the "larger"
type, e.g. float + decimal -> float + float -> float, so
you'd only have to document how the conversion is done and
which accuracy to expect.
 
> > >     To accommodate the three possible usage models the python interpreter
> > >     command line options will be used to set the level for warning and
> > >     error messages. The three levels are:
> > >
> > >     promiscuous mode,   -f or  --promiscuous
> > >     safe mode           -s or --save
> > >     pedantic mode       -p or --pedantic
> >
> > How about a generic option:
> >
> >       --numerics:[loose|safe|pedantic] or -n:[l|s|p]
> 
> Thanks for the suggestion. I"ll change it.

Great.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/