classification
Title: Add support for IEEE 754 contexts to decimal module.
Type: enhancement Stage: needs patch
Components: Library (Lib) Versions: Python 3.4
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: christian.heimes, ezio.melotti, facundobatista, maker, mark.dickinson, rhettinger, skrah, terry.reedy
Priority: normal Keywords: patch

Created on 2010-05-22 10:28 by mark.dickinson, last changed 2013-08-30 16:08 by skrah.

Files
File name Uploaded Description Edit
issue8786.patch maker, 2012-09-18 07:53 review
Messages (8)
msg106294 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-05-22 10:28
Discussion migrated from issue 8540 into its own issue.

For ease of communication with other libraries, it would be good to be able to easily create contexts corresponding to the IEEE 754 (2008) decimal interchange formats.
msg106296 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-05-22 11:24
Some context from issue 8540:

[Stefan Krah]
> I'm busy implementing the IEEE754 contexts for cdecimal. To keep things
> in sync, it would be nice to agree how they should be created.
>
>
> Suggestions:
>
> 1) c = Decimal64Context
>
> 2) c = Context(Decimal64)


[Mark Dickinson]
> Rather that complicating the Context constructor, I'd prefer a separate factory
> function.  I was thinking of something like:
>
> def IEEEContext(n):
>     """Return the decimal<n> IEEE 754 context.  n should be a multiple
>        of 32."""
>     ...
>
> Again, it's clear with this that you get a new context object (I agree that 
> there are problems with (1) and the mutability of Contexts).

I like that, too. Where do you find the "multiple of 32" in the standard?
In a draft of IEEE 754, I only see:

Table 2—Interchange format parameters defining floating-point numbers:

  storage format: decimal32

  basic format: decimal64 and decimal128


This is what Java and decNumber offer.
msg106297 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-05-22 11:29
It's Table 3.6 ("Decimal interchange format parameters") in the final version of IEEE 754;  I'm not sure what that corresponds to in the various drafts.  It has column headings: "decimal32", "decimal64", "decimal128" and "decimal{k} (k >= 32)".

Parameters for decimal{k}:  k must be a multiple of 32.  precision is   9*k/32-2.  emax is 3*2**(k/16+3).  I think these formulas all work for the specific cases k in {32, 64, 128} too, so it should be easy to check that they make sense.

They give an example below the table, too:

"For example, decimal256 would have p = 70 and emax = 1572864."
msg106303 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-05-22 12:07
Mark Dickinson <report@bugs.python.org> wrote:
> It's Table 3.6 ("Decimal interchange format parameters") in the final version of IEEE 754;

Thanks! I think this is not in the draft I have.

+1 for IEEEContext(n). Could we have module constants Decimal32, Decimal64 and
Decimal128 so that people coming from Java or DecNumber can write:

c = IEEEContext(Decimal64)

It is somewhat redundant, but 99% of people will use only those.
msg106325 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-05-22 22:21
Thinking ahead a bit:  at some point we might well also want functions to pack and unpack these IEEE formats into byte sequences, using the bit representations described in the standard.

A natural place for those functions would be as methods on a Context object;  perhaps IEEEContext should be a subclass of Context?  (OTOH, the struct module is another possible place for such functionality.)

I'll think about this.
msg170637 - (view) Author: Michele Orrù (maker) * Date: 2012-09-18 07:53
Something like this? That's a pretty trivial draft for the patch.

About "byte sequences", those features should be available using builtins bin(), oct() and hex(), hacking on __index__, or with internal methods?

I am lacking imagination, what else there should be to test?
msg172903 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-10-14 18:51
I do not think IEEEContext should not be made a class rather than a function until it really *is* a subclass with altered or added behavior. This means at least its own __str__ method and in this case, a __setattr__ that enforces the invariants. Here that means refusing to modify the context, or at least not prec and Emax (assuming that changes to any other context attributes (are there any?) are harmless. Something like

  def __setattr__(self, key, value):
    if key in ('prec', 'Emax'):
      raise AttributeError("cannot change {} of IEEEContext".format(key))
    else:
      super(IEEEContext, self).__setattr__(key, name)
msg196559 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2013-08-30 16:08
BTW, in _decimal the feature can already be enabled with:

./configure CFLAGS=-DEXTRA_FUNCTIONALITY


>>> IEEEContext(DECIMAL128)
Context(prec=34, rounding=ROUND_HALF_EVEN, Emin=-6143, Emax=6144, capitals=1, clamp=1, flags=[], traps=[])
>>> IEEEContext(DECIMAL64)
Context(prec=16, rounding=ROUND_HALF_EVEN, Emin=-383, Emax=384, capitals=1, clamp=1, flags=[], traps=[])
>>> IEEEContext(DECIMAL32)
Context(prec=7, rounding=ROUND_HALF_EVEN, Emin=-95, Emax=96, capitals=1, clamp=1, flags=[], traps=[])
>>>


>>> IEEEContext(512)
Context(prec=142, rounding=ROUND_HALF_EVEN, Emin=-103079215103, Emax=103079215104, capitals=1, clamp=1, flags=[], traps=[])
>>> IEEEContext(1024)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: argument must be a multiple of 32, with a maximum of 512
>>>

Of course this isn't the official API yet, but I think it's
reasonable.
History
Date User Action Args
2013-08-30 16:08:54skrahsetmessages: + msg196559
2013-07-07 14:51:26christian.heimessetnosy: + christian.heimes
2012-10-14 18:51:46terry.reedysetnosy: + terry.reedy
messages: + msg172903
2012-10-14 18:16:06terry.reedysetversions: + Python 3.4, - Python 3.2
2012-09-18 07:53:43makersetfiles: + issue8786.patch

nosy: + ezio.melotti, maker
messages: + msg170637

keywords: + patch
2010-05-22 22:21:39mark.dickinsonsetmessages: + msg106325
2010-05-22 12:09:12mark.dickinsonsetnosy: rhettinger, facundobatista, mark.dickinson, skrah
type: enhancement
components: + Library (Lib)
stage: needs patch
2010-05-22 12:07:53skrahsetmessages: + msg106303
2010-05-22 11:29:40mark.dickinsonsetmessages: + msg106297
2010-05-22 11:24:03skrahsetmessages: + msg106296
2010-05-22 10:28:31mark.dickinsoncreate