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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4