[Python-Dev] Re: Decimal data type issues

[Paul Moore]

Kevin Jacobs <jacobs at theopalgroup.com> writes:

> This isn't something I am willing to go to war on, but at the same
> time, I'm willing to expend some effort to lobby for inclusion.
> Either way, I will have the necessary infrastructure to accomplish
> my aims, though my goal is for everyone to have it without
> re-inventing the wheel. Silence on this topic benefits nobody.

I thought I'd try to comment, based on this. After all, I do have an
interest in the issue (I'm an Oracle user), and so if there is an
issue, it could well affect me, so I should at least be sure I
understand the point.

... and I discovered that I understand Decimal far less than I thought
I did. But after some experimentation, and reading of the spec, I
think that I've hit on a key point:

    The internal representation of a Decimal instance, and
    specifically the number of digits of precision stored internally,
    has no impact on anything, *except when the instance is converted
    to a string*

The reason for this is that every possible operation on a Decimal
instance uses context, with the sole exception of the "convert to
string" operations (sections 4 and 5 of the spec).

As a result of this, I'm not sure that it's valid to care about the
internal representation of a Decimal instance.

> It seems that Jim and I want to be able to easily create Decimal
> instances that conform to a pre-specified (maximum) scale and
> (maximum) precision.

But here we have that same point - Decimal instances do not "conform
to" a scale/precision.

> The motivation for this is clearly explained in that section of the
> PostgeSQL manual that I sent the other day. i.e., numeric and
> decimal values in SQL are specified in terms of scale and precision
> parameters. Thus, I would like to create decimal instances that
> conform to those schema -- i.e., they would be rounded appropriately
> and overflow errors generated if they exceeded either the maximum
> precision or scale.

OK, so what you are talking about is rounding during construction. Or
is it? Hang on, and let's look at your examples.

> e.g.:

>   Decimal('20000.001', precision=4, scale=0) === Decimal('20000')

This works fine with the current Decimal:

>>> Decimal("20000.001").round(prec=4) == Decimal("20000")
True

Do you dislike the need to construct an exact Decimal, and then round
it? On what grounds? I got the impression that you thought it would be
"hard", but I don't think the round() method is too hard to use...
(Although I would say that the documentation in the PEP is currently
very lacking in its coverage of how to use the type - I found the
round() method after a lot of experimentation. Before the Decimal
module is ready for prime time, it needs some serious documentation
effort).

>   Decimal('20000.001', precision=4, scale=0) raises an overflow
>   exception

Hang on - this example is the same as the previous one, but you want a
different result! In any case, the General Decimal Arithmetic spec
doesn't have a concept of overflow when a precision is exceeded (only
when the implementation-defined maximum exponent is exceeded), so I'm
not sure what you want to happen here in the context of the spec.

>   Decimal('20000.001', precision=5, scale=3) raises an overflow
>   exception

A similar comment abut overflow applies here. I can imagine that you
want to know if information has been lost, but that's no problem -
check like this:

>>> Decimal("20000.001").round(prec=5) == Decimal("20000.001")
False

>   Decimal('200.001', precision=6, scale=3) === Decimal('200.001')

Again, not an issue:

>>> Decimal("200.001").round(prec=6) == Decimal("200.001")
True

>   Decimal('200.000', precision=6, scale=3) === Decimal('200') or
>   Decimal('200.000')
>      (depending on if precision and scale are interpreted as absolutes or
>       maximums)

This doesn't make sense, given that Decimal("200") ==
Decimal("200.000"). Unless your use of === is meant to imply "has the
same internal representation as", in which case I don't believe that
you have a right to care what the internal representation is.

I've avoided considering scale too much here - Decimal has no concept
of scale, only precision. But that's effectively just a matter of
multiplying by the appropriate power of 10, so shouldn't be a major
issue.

Apologies if I've completely misunderstood or misrepresented your
problem here. If it's any consolation, I've learned a lot in the
process of attempting to comment.

Paul.
-- 
This signature intentionally left blank