[Python-Dev] Revised decimal type PEP

[Michael McLay]

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)

> 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?  

>
> >     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.

> >     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.

> >     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.