[Python-Dev] Revised decimal type PEP

[M.-A. Lemburg]

Michael McLay wrote:
> 
> On Tuesday 31 July 2001 12:36 pm, M.-A. Lemburg wrote:
> 
> > I'd suggest to follow the rules for the SQL definitions
> > of DECIMAL(,).
> 
> > 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.
> 
> Ok, I know about the IBM paper.  is there online document on the SQL
> semantics that can be referenced in the PEP?

The spec is not available online since it is an ISO paper (you pay
per page), but I did find a review draft dated July 1992 for SQL-92:

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

which has all the relevant information in text format (section 4.4.).
 
> > I see, the small 'b' still looks funny to me though. Wouldn't
> > 1.23f and 25i be more intuitive ?
> 
> I originally used 'f' for both the integer and float.    The use of 'b' was
> suggested by Guido. There were two reasons not to use 'i' for integers.  The
> first has to do with how the tokenizer works.  It doesn't distringuish
> between float and int when the token string is passed to parsenumber().  Both
> float and int are processed by the same function.  I could have got around
> this problem by having the switch statement in parsenumber recognize both 'i'
> and 'f', but there is another problem with using 'i'.  The 25i would be
> confusing for someone if they was trying to use an imaginary numbers If they
> accidentally typed 25i instead of 25j they would get an integer instead of an
> imaginary number.  The error might not be detected since 3.0 + 4i would
> evaluate properly.

Well, if we manage to have a registry of some sort for these
number literal modifiers, I think that the issues in which code
to choose are secondary.
 
> > > > 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.
> 
> I would be concerned about the float + decimal automatically generating a
> float.  Would it generate an error message if the pedantic flag was set?
> Would it generate a warning in safe mode?
> 
> Also, why do you consider a float to be a "larger" value type than decimal?
> Do you mean that a float is less precise?

See Guido's post on this. 

"Larger" usually means two things:
- more precise
- larger range

This does not necessarily make the decision any easier, though,
since the two terms don't discriminate numeric values too well,
e.g. how do complex and longs fit into the picture ? As a result,
this becomes a language design question.

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