Decimal data type issues

[Batista, Facundo]

People:

Tim Peters reviewed the PEP 327, and asked some questions.  Trying to
answer those questions, I found that some items needs to be addressed with
a comunity consensus.

So, the next items are to be included in the PEP when the discussion
finishes:


Exponent Maximum
----------------

The Decimal number composes of three elements: A sign that can be 0 or 1, a
tuple of digits where each can be 0..9, and an exponent. 

The exponent is an integer, and in the actual implementation exists a
maximum
value::

DEFAULT_MAX_EXPONENT = 999999999
DEFAULT_MIN_EXPONENT = -999999999
ABSOLUTE_MAX_EXP = 999999999
ABSOLUTE_MIN_EXP = -999999999

The issue is that this limit is artificial: As long it's a long, you should
be able to make it as big as your memory let you.

In the General Decimal Arithmetic Specification says:

  In the abstract, there is no upper limit on the absolute value of the
  exponent.  In practice there may be some upper limit, E_limit , on the
  absolute value of the exponent.
  
So, should we impose an artificial limit to the exponent?

This is important, as there're several cases where this maximums are checked
and exceptions raised and/or the numbers get changed.


New operations
--------------

Tim Peters found I missed three operations required by the standard.  Those
are:

a. ``to-scientific-string``: This operation converts a number to a string,
   using scientific notation if an exponent is needed. The operation is not
   affected by the context.

b. ``to-engineering-string``: This operation converts a number to a string,
   using engineering notation if an exponent is needed.

c. ``to-number``: This operation converts a string to a number, as defined
   by its abstract representation.

First we should agree the names of the methods, I propose:

a. to_sci_string
b. to_eng_string
c. from_string

The (a) and (b) methods are different from str, as this method just doesn't
adjust the exponent at all.

Regarding the method (c), the only difference with creating the decimal with
Decimal(string) is that method (c) honors the context (if the literal
contains more digits that the current precision the numbers get rounded, and
gets rounded according to the round method specified in context, etc). For
example, with a precision of 9 and with the name I proposed::

>>> Decimal('112233445566')
Decimal( (0, (1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6), 0) )
>>> Decimal.from_string('112233445566')
Decimal( (0, (1, 1, 2, 2, 3, 3, 4, 4, 6), 3L) )


Hash behaviour
--------------

This item actually wasn't raised by Tim, but I found it when implementing
the module.

In the PEP I wrote that Decimal must be hashable. But what hash should it
give?

Should the following be true?::

  hash(Decimal(25) == hash(25)
  hash(Decimal.from_float(25.35) == hash(25.35)
  hash(Decimal('-33.8')) == hash(-33.8)

I don't think so. I think that hash(Decimal(...)) just should return a
different value in each case, but no the same value that other data types.


Thank you all for your feedback.

.	Facundo





. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
ADVERTENCIA  

La información contenida en este mensaje y cualquier archivo anexo al mismo,
son para uso exclusivo del destinatario y pueden contener información
confidencial o propietaria, cuya divulgación es sancionada por la ley. 

Si Ud. No es uno de los destinatarios consignados o la persona responsable
de hacer llegar este mensaje a los destinatarios consignados, no está
autorizado a divulgar, copiar, distribuir o retener información (o parte de
ella) contenida en este mensaje. Por favor notifíquenos respondiendo al
remitente, borre el mensaje original y borre las copias (impresas o grabadas
en cualquier medio magnético) que pueda haber realizado del mismo. 

Todas las opiniones contenidas en este mail son propias del autor del
mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones
Personales S.A. o alguna empresa asociada. 

Los mensajes electrónicos pueden ser alterados, motivo por el cual
Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación
cualquiera sea el resultante de este mensaje. 

Muchas Gracias.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20040413/39b0ddb9/attachment.html>