[Tim]
>> I suggested following the standards' rules (the constructor works the
>> same way as everything else - it rounds) for Python's module too, but
>> Mike Cowlishaw (the decimal spec's primary driver) overruled me on
>> that.
[Greg Ewing ]
> Did he offer a rationale for that?
Possibly, but I
On Thu, 15 Oct 2020 at 04:22, Guido van Rossum wrote:
>
> This all seems a pretty artificial argument.
>
> In plain English, "1/3" is not exactly representable in decimal form, but
> something like 0. * 0.22
> *is* (assuming the inputs are what
On 15/10/20 1:59 pm, Tim Peters wrote:
I suggested following the standards' rules (the constructor works the
same way as everything else - it rounds) for Python's module too, but
Mike Cowlishaw (the decimal spec's primary driver) overruled me on
that.
Did he offer a rationale for that?
--
Greg
This all seems a pretty artificial argument.
In plain English, "1/3" is not exactly representable in decimal form, but
something like 0. *
0.22 *is* (assuming the inputs are what they
appear).
Since the spec clearly means to say "exactly represe
On Thu, Oct 15, 2020 at 11:28:36AM +1100, Chris Angelico wrote:
> Neither 1/3 nor sqrt(2) can be *exactly represented* as a decimal
> fraction.
Indeed, I am very aware of that, and in fact they were precisely the
examples I gave to question Random's assertion that inexact rounding is
something
[Steven D'Aprano ]
> ...
> (To be honest, I was surprised to learn that the context precision is
> ignored when creating a Decimal from a string. I still find it a bit odd
> that if I set the precision to 3, I can still create a Decimal with
> twelve digits.)
You're not alone ;-) In the original
On Thu, Oct 15, 2020 at 11:18 AM Steven D'Aprano wrote:
>
> On Wed, Oct 14, 2020 at 03:33:22PM -0400, Random832 wrote:
>
> > That is nonsense. "exactly representable" is a plain english phrase
> > and has a clear meaning that only involves the actual data format, not
> > the context.
>
> Perhaps y
On Wed, Oct 14, 2020 at 03:33:22PM -0400, Random832 wrote:
> That is nonsense. "exactly representable" is a plain english phrase
> and has a clear meaning that only involves the actual data format, not
> the context.
Perhaps your understanding of plain English is radically different from
mine,
[Random832 ]
[various bits of pushback, which all basically boil down to this one:}
> ...
> That is nonsense. "exactly representable" is a plain english phrase and
> has a clear meaning that only involves the actual data format, not the
> context.
The `decimal` module implements a very exacting s
On Fri, Oct 9, 2020, at 17:38, Tim Peters wrote:
> [Random832 ]
> > My suggestion was for a way to make it so that if an exact result is
> > exactly representable at any precision you get that result, with
> > rounding only applied for results that cannot be represented exactly
> > regardless of pr
On Sun, 11 Oct 2020 at 19:53, Wes Turner wrote:
> Arbitrary-precision multiple-precision floats in Python: mpmath, gmpy, sympy
> .evalf() / N()
mpmath has always a global precision:
http://mpmath.org/doc/current/basics.html#setting-the-precision
About SymPy, I worked a little with it within Sag
Arbitrary-precision multiple-precision floats in Python: mpmath, gmpy,
sympy .evalf() / N()
https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
- https://github.com/fredrik-johansson/mpmath
> Python library for arbitrary-precision floating-point arithmetic
- docs: http://mpmath.org/d
[Tim]
>> Try to spell out what you mean - precisely! - by "this". I can't do
>> that for you. For any plausible way of fleshing it out I've thought
>> of, the answer is "no".
[Marco Sulla ]
> Well, please, don't be so harsh. I'm trying to discuss to someone that
> co-created Python itself, it's no
On Sat, 10 Oct 2020 at 19:28, Tim Peters wrote:
> Try to spell out what you mean - precisely! - by "this". I can't do
> that for you. For any plausible way of fleshing it out I've thought
> of, the answer is "no".
Well, please, don't be so harsh. I'm trying to discuss to someone that
co-created P
[Tim]
>> But the decimal spec takes a different approach, which Python's docs
>> don't explain at all: the otherwise-mysterious ROUND_05UP rounding
>> mode. Quoting from the spec:
>>
>> http://speleotrove.com/decimal/damodel.html
>> ...
>> The rounding mode round-05up permits arithmet
On Fri, 9 Oct 2020 at 23:41, Tim Peters wrote:
> But the decimal spec takes a different approach, which Python's docs
> don't explain at all: the otherwise-mysterious ROUND_05UP rounding
> mode. Quoting from the spec:
>
> http://speleotrove.com/decimal/damodel.html
> ...
> The roundi
On Thu, 8 Oct 2020 at 16:59, Random832 wrote:
>
> I was making a "convert Fraction to Decimal, exactly if possible" function
> and ran into a wall: it's not possible to do some of the necessary operations
> with exact precision in decimal:
>
> - multiplication
> - division where the result can b
[Random832 ]
> My suggestion was for a way to make it so that if an exact result is
> exactly representable at any precision you get that result, with
> rounding only applied for results that cannot be represented exactly
> regardless of precision.
That may have been the suggestion in your head ;-
On Thu, Oct 8, 2020, at 16:07, Tim Peters wrote:
> See above. It's very much a feature of the IEEE 754/854 standards (of
> which family Python's decimal model is a part) that if an exact
> result is exactly representable, then that's the result you get.
My suggestion was for a way to make it so
On Thu, 8 Oct 2020 at 22:10, Tim Peters wrote:
> Again, the concept of a _fixed_ (albeit user-settable) working
> precision is deep in the module's bones.
That is, for what I know, how also BigDecimal in Java works... and
float in any architecture.
___
[Random832]
> I don't understand what's unclear -
Obviously ;-) But without carefully constructed concrete use cases,
what you say continues to remain unclear to me.
> I was suggesting there should be an easy way to have the exact
> result for all operations on Decimal operands that have exact r
On Thu, Oct 8, 2020, at 13:12, Steven D'Aprano wrote:
> I trimmed it because I didn't understand the relevance. If the
> denominator is an exact multiple of only 2 and 5, then I think the
> conversion will be exact if the precision is sufficient.
I wanted the conversion to be exact irrespective
On Thu, Oct 8, 2020, at 13:17, Tim Peters wrote:
> [Random832 ]
> > I was making a "convert Fraction to Decimal, exactly if possible" function
> > and
> > ran into a wall: it's not possible to do some of the necessary operations
> > with
> > exact precision in decimal:
> >
> > - multiplication
>
[Random832 ]
> I was making a "convert Fraction to Decimal, exactly if possible" function and
> ran into a wall: it's not possible to do some of the necessary operations with
> exact precision in decimal:
>
> - multiplication
> - division where the result can be represented exactly [the divisor is
On Fri, Oct 09, 2020 at 03:53:24AM +1100, Chris Angelico wrote:
> On Fri, Oct 9, 2020 at 3:43 AM Steven D'Aprano wrote:
> >
> > On Thu, Oct 08, 2020 at 11:58:04AM -0400, Random832 wrote:
> >
> > > I was making a "convert Fraction to Decimal, exactly if possible"
> > > function and ran into a wall:
On Fri, Oct 9, 2020 at 3:43 AM Steven D'Aprano wrote:
>
> On Thu, Oct 08, 2020 at 11:58:04AM -0400, Random832 wrote:
>
> > I was making a "convert Fraction to Decimal, exactly if possible"
> > function and ran into a wall: it's not possible to do some of the
> > necessary operations with exact pre
On Thu, Oct 08, 2020 at 11:58:04AM -0400, Random832 wrote:
> I was making a "convert Fraction to Decimal, exactly if possible"
> function and ran into a wall: it's not possible to do some of the
> necessary operations with exact precision in decimal:
Of course you can't do them with *exact* pre
27 matches
Mail list logo
