[Python-ideas] Python Float Update

[Andrew Barnert]

On Jun 2, 2015, at 07:05, Oscar Benjamin <oscar.j.benjamin at gmail.com> wrote:
> 
> On 2 June 2015 at 14:05, Andrew Barnert via Python-ideas
> <python-ideas at python.org> wrote:
>> On Jun 2, 2015, at 05:34, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> 
>>> This is one of the other
>>> main reasons why decimal64 or decimal128 are better candidates for a
>>> builtin decimal type than decimal.Decimal as it exists today (as well
>>> as being potentially more amenable to hardware acceleration on some
>>> platforms).
>> 
>> OK, so what are the stumbling blocks to adding decimal32/64/128 (or just one of the three), either in builtins/stdtypes or in decimal, and then adding literals for them?
>> 
>> I can imagine a few: someone has to work out exactly what features to support (the same things as float, or everything in the standard?),
> 
> I would argue that it should be as simple as float. If someone wants
> the rest of it they've got the Decimal module which is more than
> enough for their needs.

But decimal64 and Decimal are not the same types. So, if you want to, e.g., get the next decimal64 value after the current value, how would you do that? (Unless you're suggesting there should be a builtin decimal64 and a separate decimal.decimal64 or something, but I don't think you are.)

Also, with float, we can get away with saying we're supporting the 1985 standard and common practice among C90 implementations; with decimal64, the justification for arbitrarily implementing part of the 2008 standard but not the rest is not as clear-cut.

>> how it interacts with Decimal and float (which is defined by the standard, but translating that to Python isn't quite trivial),
> 
> Interaction between decimalN and Decimal coerces to Decimal.

Even when the current decimal context is too small to hold a decimalN? Does that raise any flags?

> Interaction with floats is a TypeError.
> 
>> how it fits into the numeric tower ABCs,
> 
> Does anyone really use these for anything? I haven't really found them
> to be very useful since no third-party numeric types

The NumPy native types do. (Of course they also subclass int and float even relevant.)

> use them and they
> don't really define the kind of information that you might really want
> in any carefully written numerical algorithm. I don't see any gain in
> adding any decimal types to e.g Real as the ABCs seem irrelevant to
> me.

Even if they are completely irrelevant, unless they're deprecated they pretty much have to be supported by any new types. There might be a good argument that decimal64 doesn't fit into the numeric tower, but you'd have to make that argument.

>> and what syntax to use for the literals, and if/how it fits into things like array/struct/ctypes
> 
> It's not essential to incorporate them here. If they become commonly
> used in C then it would be good to have these for binary
> compatibility.

For ctypes, sure (although even there, ctypes is a relatively simple way to share values between pure-Python child processes with multiprocessing.shared_ctypes). But for array, that's generally not about compatibility with existing C code, it's about efficiently packing zillions of homogenous simple values into as little memory as possible.

>> and into math, and whether we need decimal complex values,
> 
> It's not common to use the math-style functions with the decimal
> module

Well, math is mostly about double functions from the C90 stdlib, so it's not common to use them with decimal. But that doesn't mean you wouldn't want decimal64 implementations of some of the functions in math. 

> unless you're using it as a multi-precision library and then
> you'd really want the full Decimal type.

But again, the full Decimal type isn't just an expansion on decimal64, it's a completely different type, with context-sensitive precision.

> There's no advantage in using
> decimal for e.g. sin, cos etc.
> so there's not much really lost in
> converting to binary and back.

There's still rounding error. Sure, usually that won't make a difference--but when it does, it will be surprising and frustrating if you didn't explicitly ask for it.

> It's in the simple arithmetic where it
> makes a difference so I'd say that decimal should stick to that.
> 
> As for complex decimals this would only really be worth it if the
> ultimate plan was to have decimals become the default floating point
> type.

Why?

> Laura suggested that earlier and I probably agree that it would
> have been a good idea at some earlier time but it's a bit late for
> that.
> 
>> and what the C API looks like (it would be nice if PyDecimal64_AsDecimal64 worked as expected on C11 platforms, but you could still use decimal64 on C90 platforms and just not get such functions...);
> 
> Presumably CPython would have to write it's own implementation e.g.:
> 
>    PyDecimal64_FromIntExponentAndLongSignificand
> 
> ... or something like that.

Sure, if you want a C API for C90 platforms at all. But you may not even need that. When would you need to write C code that deals with decimal64 values as exponent and significant? Dealing with them as abstract numbers, general Python objects, native decimal64, and maybe even opaque values that I can pass around in C without being able to interpret them, I can see, but what C code needs the exponent and significand?

>> then write a PEP; then write an implementation; and after all that work, the result may be seen as too much extra complexity (either in the language or in the implementation) for the benefits. But is that it, or is there even more that I'm missing?
> 
> I don't think anyone has proposed to add all of the things that you
> suggested.

I think in many (but maybe not all) of these cases the simplest answer is the best, but a PEP would have to actually make that case for each thing.

> Of course if there are decimal literals and a fixed-width
> decimal type then over time people will suggest some of the other
> things. That doesn't mean that they'd need to be incorporated though.
> 
> A year ago I said I'd write a PEP for decimal literals but then I got
> clobbered at work and a number of other things happened so that I
> didn't even have time to read threads like this. Maybe it's worth
> revisiting...

Maybe we need a PEP for the decimalN type(s) first, then if someone has time and inclination they can write a PEP for literals for those types, either as a companion or as a followup. That would probably cut out 30-50% of the work, and maybe even more of the room for argument and bikeshedding.