On Fri, Apr 2, 2010 at 2:38 AM, Mark Dickinson wrote:
> On Mon, Mar 22, 2010 at 7:52 PM, Guido van Rossum wrote:
>> On Mon, Mar 22, 2010 at 11:36 AM, Raymond Hettinger
>> wrote:
>>> One other thought.
>>>
>>> The Decimal constructor should now accept floats as a possible input type.
>>> Formerly
On Mon, Mar 22, 2010 at 7:52 PM, Guido van Rossum wrote:
> On Mon, Mar 22, 2010 at 11:36 AM, Raymond Hettinger
> wrote:
>> One other thought.
>>
>> The Decimal constructor should now accept floats as a possible input type.
>> Formerly, we separated that out to Decimal.from_float() because
>> deci
On Thu, Mar 25, 2010 at 1:15 AM, Jeffrey Yasskin wrote:
> On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson wrote:
>> Slight change of topic. I've been implementing the extra comparisons
>> required for the Decimal type and found an anomaly while testing.
>> Currently in py3k, order comparisons (b
Steven D'Aprano wrote:
I'd like to turn the question around ... what algorithms are there that
rely on NaN == NaN being True?
That seems to be a straw question, since AFAIK nobody
has suggested that there are any such algorithms.
On the other hand, it has been claimed that some
algorithms exi
On Thu, Mar 25, 2010 at 04:18, Steven D'Aprano wrote:
> def myfunc(x, y):
> if x == y:
> return 1.0
> else:
> return something_complicated**(x-y)
>
>
> Optimising floating point code is fraught with dangers (the above fails
> for x=y=INF as well as NAN) but anything that make N
Steven D'Aprano pearwood.info> writes:
>
> Personally, I'm less concerned about sets of floats ending up with
> strange combinations of NANs than I am about the possibility of
> disastrous maths errors caused by allowing NANs to test as equal.
> Here's a simplistic example:
You just said "if
On Thu, 25 Mar 2010 10:25:35 pm Nick Coghlan wrote:
> Steven D'Aprano wrote:
> > I'd like to turn the question around ... what algorithms are there
> > that rely on NaN == NaN being True?
>
> Absolutely anything that expects "x is y" to imply that "x == y". The
> builtin containers enforce this by
Steven D'Aprano wrote:
> I'd like to turn the question around ... what algorithms are there that
> rely on NaN == NaN being True?
Absolutely anything that expects "x is y" to imply that "x == y". The
builtin containers enforce this by checking identity before they check
equality, but there are pl
Steven D'Aprano wrote:
> On Thu, 25 Mar 2010 03:22:29 am Mark Dickinson wrote:
>> The obvious way to do this nan interning for floats would be to put
>> the interning code into PyFloat_FromDouble. I'm not sure whether
>> this would be worth the cost in terms of added code (and possibly
>> reduced
On Thu, 25 Mar 2010 05:26:12 am Alexander Belopolsky wrote:
> Mark, I wonder if you could describe an algorithm off the top of your
> head that relies on NaN == NaN being false.
I don't know whether "relies on" is appropriate, but consider:
def myfunc(x, y):
if x == y:
return 1.0
On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson wrote:
> Slight change of topic. I've been implementing the extra comparisons
> required for the Decimal type and found an anomaly while testing.
> Currently in py3k, order comparisons (but not ==, !=) between a
> complex number and another complex,
Raymond Hettinger wrote:
Conceptually, it's a bug. The numeric tower treats non-complex
numbers as special cases of complex where the imaginary
component is zero (that's why the non-complex types all support
real/imag), and since complex numbers are not allowed to compare
to themselves, they sh
On Wed, Mar 24, 2010 at 2:29 PM, Raymond Hettinger
wrote:
>
> On Mar 24, 2010, at 2:09 PM, Mark Dickinson wrote:
>
>> Slight change of topic. I've been implementing the extra comparisons
>> required for the Decimal type and found an anomaly while testing.
>> Currently in py3k, order comparisons (
On 3/24/2010 1:56 PM, Raymond Hettinger wrote:
FWIW, my viewpoint on this is softening over time
and I no longer feel a need to push for a new context flag.
To make Decimal useful for people that want to control its numerical
quality, there must be a way to exclude accidental operations,
On Mar 24, 2010, at 2:09 PM, Mark Dickinson wrote:
> Slight change of topic. I've been implementing the extra comparisons
> required for the Decimal type and found an anomaly while testing.
> Currently in py3k, order comparisons (but not ==, !=) between a
> complex number and another complex, fl
On Wed, Mar 24, 2010 at 8:56 PM, Raymond Hettinger
wrote:
> FWIW, my viewpoint on this is softening over time
> and I no longer feel a need to push for a new context flag.
>
> It is probably simplest for users if implicit coercions didn't come
> with control knobs. We already have Fraction+float-
W00t!
On Wed, Mar 24, 2010 at 1:56 PM, Raymond Hettinger
wrote:
> FWIW, my viewpoint on this is softening over time
> and I no longer feel a need to push for a new context flag.
>
> It is probably simplest for users if implicit coercions didn't come
> with control knobs. We already have Fraction
Slight change of topic. I've been implementing the extra comparisons
required for the Decimal type and found an anomaly while testing.
Currently in py3k, order comparisons (but not ==, !=) between a
complex number and another complex, float or int raise TypeError:
>>> z = complex(0, 0)
>>> z < in
FWIW, my viewpoint on this is softening over time
and I no longer feel a need to push for a new context flag.
It is probably simplest for users if implicit coercions didn't come
with control knobs. We already have Fraction+float-->float
occurring without any exceptions or warnings, and nothing
ba
Thanks. Same link reported concurrently by Mark in the "Why is nan !=
nan?" thread.
On Wed, Mar 24, 2010 at 4:26 PM, Raymond Hettinger
wrote:
>
> On Mar 24, 2010, at 12:51 PM, Alexander Belopolsky wrote:
>
> - "Reflexivity, and other pillars of civilization" by Bertrand Meyer
> http://bertrandme
On Mar 24, 2010, at 12:51 PM, Alexander Belopolsky wrote:
>
> - "Reflexivity, and other pillars of civilization" by Bertrand Meyer
> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
Excellent link.
Thanks for the research.
Raymond
___
On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson wrote:
> On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky
> wrote:
>> Mark, I wonder if you could describe an algorithm off the top of your
>> head that relies on NaN == NaN being false.
>>
>
> No, I certainly couldn't! And I often wonder if t
On Wed, Mar 24, 2010 at 11:55 AM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 2:36 PM, Guido van Rossum wrote:
> ..
>> Probably because we were blindly following the IEEE standard without
>> understanding it in every detail.
>
> Are you talking about "accidental" support for NaNs in old
Nick Coghlan wrote:
> Raymond Hettinger wrote:
> > The decimal module is already drowning in complexity,
> > so it would be best to keep it simple: one boolean flag
> > that if set would warn about any implicit decimal/float
> > interaction.
>
> Agreed - those that want exceptions instead can us
On Thu, 25 Mar 2010 03:22:29 am Mark Dickinson wrote:
> The obvious way to do this nan interning for floats would be to put
> the interning code into PyFloat_FromDouble. I'm not sure whether
> this would be worth the cost in terms of added code (and possibly
> reduced performance, since the nan ch
On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson wrote:
..
> If Python were to do something different then a naively translated
> algorithm from another language would fail. It's the behaviour that
> numerically-aware people expect, and I'd expect to get complaints from
> those people if it chang
On Wed, Mar 24, 2010 at 2:36 PM, Guido van Rossum wrote:
..
> Probably because we were blindly following the IEEE standard without
> understanding it in every detail.
Are you talking about "accidental" support for NaNs in older versions
of Python or about recent efforts to support them properly i
On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky
wrote:
> Mark, I wonder if you could describe an algorithm off the top of your
> head that relies on NaN == NaN being false.
>
No, I certainly couldn't! And I often wonder if the original IEEE 754
committee, given 20/20 foresight, would have
On Wed, Mar 24, 2010 at 11:26 AM, Alexander Belopolsky
wrote:
> I wonder why Python did not follow Java model where Float NaN objects
> unlike raw float NaNs compare equal to themselves. One reason may
> be that Python does not have raw floats, but if someone needs IEEE 754
> NaNs, one can use
On Wed, Mar 24, 2010 at 1:39 PM, Raymond Hettinger
wrote:
..
> IMO, their least useful feature is the property of being not equal
> to themselves -- that causes more problems than it solves
> because it impairs a programmer's ability to reason about
> their programs.
I agree. An often cited rat
On Mar 24, 2010, at 9:22 AM, Mark Dickinson wrote:
>
> The obvious way to do this nan interning for floats would be to put
> the interning code into PyFloat_FromDouble. I'm not sure whether this
> would be worth the cost in terms of added code (and possibly reduced
> performance, since the nan c
On Wed, Mar 24, 2010 at 11:47 AM, Nick Coghlan
> Interning NaN certainly seems like it should be sufficient to eliminate
> the set/dict membership weirdness.
>
> That is, make it so that the first two lines of the following return
> True, while the latter two lines continue to return False:
>
On Wed, 24 Mar 2010 10:47:26 pm Nick Coghlan wrote:
> Steven D'Aprano wrote:
> > On Wed, 24 Mar 2010 08:51:36 pm Mark Dickinson wrote:
> >>> I don't see how it can be so. Aren't all of those entries
> >>> garbage? To compute a histogram of results for computations on a
> >>> series of cases would
Raymond Hettinger wrote:
> The decimal module is already drowning in complexity,
> so it would be best to keep it simple: one boolean flag
> that if set would warn about any implicit decimal/float
> interaction.
Agreed - those that want exceptions instead can use the usual warnings
module mechani
Steven D'Aprano wrote:
> On Wed, 24 Mar 2010 08:51:36 pm Mark Dickinson wrote:
>>> I don't see how it can be so. Aren't all of those entries garbage?
>>> To compute a histogram of results for computations on a series of
>>> cases would you not have to test each result for NaN-hood, then
>>> hash o
Mark Dickinson writes:
> On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull
> wrote:
> > Steven D'Aprano writes:
> > > I suspect that's a feature, not a bug.
>
> Right: distinct nans (i.e., those with different id()) are treated as
> distinct set elements or dict keys.
>
> > I do
On Wed, 24 Mar 2010 08:51:36 pm Mark Dickinson wrote:
> On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull
wrote:
> > Steven D'Aprano writes:
> >
> > > As usual though, NANs are unintuitive:
> > >
> > > >>> d = {float('nan'): 1}
> > > >>> d[float('nan')] = 2
> > > >>> d
> > > {nan: 1, nan
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > As usual though, NANs are unintuitive:
> >
> > >>> d = {float('nan'): 1}
> > >>> d[float('nan')] = 2
> > >>> d
> > {nan: 1, nan: 2}
> >
> >
> > I suspect that's a feature, not a bug.
Right: disti
Steven D'Aprano writes:
> As usual though, NANs are unintuitive:
>
> >>> d = {float('nan'): 1}
> >>> d[float('nan')] = 2
> >>> d
> {nan: 1, nan: 2}
>
>
> I suspect that's a feature, not a bug.
I don't see how it can be so. Aren't all of those entries garbage?
To compute a histogram o
On Wed, 24 Mar 2010 05:04:37 am Mark Dickinson wrote:
> On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen wrote:
> > a = Decimal('nan')
> > a != a
> >
> > They don't follow the behaviour required for being hashable.
>
> What's this required behaviour? The only rule I'm aware of is that
> if a == b then
On Tue, Mar 23, 2010 at 10:55 AM, Mark Dickinson wrote:
> On Tue, Mar 23, 2010 at 6:07 PM, Adam Olsen wrote:
>> On Tue, Mar 23, 2010 at 12:04, Mark Dickinson wrote:
>>> Note that containment tests check identity before equality, so there's
>>> no problem with putting (float) nans in sets or dict
On Tue, Mar 23, 2010 at 6:07 PM, Adam Olsen wrote:
> On Tue, Mar 23, 2010 at 12:04, Mark Dickinson wrote:
>> Note that containment tests check identity before equality, so there's
>> no problem with putting (float) nans in sets or dicts:
>>
> x = float('nan')
> s = {x}
> x in s
>> Tru
On Tue, Mar 23, 2010 at 12:04, Mark Dickinson wrote:
> On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen wrote:
>> a = Decimal('nan')
>> a != a
>>
>> They don't follow the behaviour required for being hashable.
>
> What's this required behaviour? The only rule I'm aware of is that if
> a == b then has
On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen wrote:
> a = Decimal('nan')
> a != a
>
> They don't follow the behaviour required for being hashable.
What's this required behaviour? The only rule I'm aware of is that if
a == b then hash(a) == hash(b). That's not violated here.
Note that containmen
On Tue, Mar 23, 2010 at 11:31, Mark Dickinson wrote:
> Agreed, notwithstanding the above comments. Though to avoid the
> problems described above, I think the only way to make this acceptable
> would be to prevent hashing of signaling nans. (Which the decimal
> module current does; it also preve
On Tue, Mar 23, 2010 at 3:09 PM, Stefan Krah wrote:
> Mark Dickinson wrote:
>> [Stefan]
>> >
>> > strictness 2: current py3k behaviour + pure equality comparisons
>>
>> Can you explain what you mean by "+ pure equality comparisons" here?
>> If I'm understanding correctly, this is a mode that's *
On Mar 23, 2010, at 5:09 AM, Stefan Krah wrote:
>
> I like the simplicity of having a single signal (e.g. CoercionError), but
> a strictness context flag could offer greater control for people who only
> want pure decimal/integer operations.
>
>
> For example:
>
> strictness 0: completely pro
Mark Dickinson wrote:
> > I like the simplicity of having a single signal (e.g. CoercionError), but
> > a strictness context flag could offer greater control for people who only
> > want pure decimal/integer operations.
>
> Sounds worth considering.
>
> > For example:
> >
> > strictness 0: comp
Greg Ewing wrote:
> Mark Dickinson wrote:
>
>> But the Fraction type is going to mess this up: for Decimal +
>> Fraction -> Decimal, I don't see any other sensible option than to
>> convert the Fraction using the current context, since lossless
>> conversion isn't generally possible.
>
> You co
On Tue, Mar 23, 2010 at 12:09 PM, Stefan Krah wrote:
> Facundo Batista wrote:
>> On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum wrote:
>>
>> > As a downside, there is the worry that inadvertent mixing of Decimal
>> > and float can compromise the correctness of programs in a way that is
>> > h
Facundo Batista wrote:
> On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum wrote:
>
> > As a downside, there is the worry that inadvertent mixing of Decimal
> > and float can compromise the correctness of programs in a way that is
> > hard to detect. But the anomalies above indicate that not fix
On Tue, Mar 23, 2010 at 12:33 AM, Greg Ewing
wrote:
> Mark Dickinson wrote:
>>
>> It might make sense for
>> Decimal + complex mixed-type operations to be disallowed, for example.
>
> As long as you're allowing Decimal-float comparisons,
> Decimal-complex comparison for equality has an obvious
> i
Mark Dickinson wrote:
It might make sense for
Decimal + complex mixed-type operations to be disallowed, for example.
As long as you're allowing Decimal-float comparisons,
Decimal-complex comparison for equality has an obvious
interpretation.
--
Greg
Nick Coghlan wrote:
http://docs.python.org/library/decimal.html#decimal.Inexact
(Part of the thread context rather than the individual decimal values,
but if you use it properly it tells you whenever an inexact operation
has occurred in the current thread)
My problem was that the statement "A
Mark Dickinson wrote:
But the Fraction type is going to mess this up: for Decimal +
Fraction -> Decimal, I don't see any other sensible option than to
convert the Fraction using the current context, since lossless
conversion isn't generally possible.
You could convert the Decimal to a Fracti
Raymond Hettinger wrote:
> * The coercion logic for comparisons won't match the
> coercion logic for arithmetic operations. The former
> strives to be exact and to be consistent with hashing
> while the latter goes in the opposite direction.
Although Guido pointed out that float/long comparisons
For the record, I thought I would take a stab at making a single post
that recaps the trade-offs and reasoning behind the decision
to have Fraction + decimal/float --> decimal/float.
Pros:
* While we know that both decimal and binary floats have a
fixed internal precision and can be converted los
On Mon, Mar 22, 2010 at 8:44 PM, Guido van Rossum wrote:
> On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger
> wrote:
>> While we're on the topic, I think you should consider allowing the Fraction()
>> constructor to accept a decimal input.
>>
>> This corresponds to common schoolbook problems a
On Mon, Mar 22, 2010 at 12:45 PM, Mark Dickinson wrote:
> On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger
> wrote:
>> While we're on the topic, I think you should consider allowing the Fraction()
>> constructor to accept a decimal input.
>>
>> This corresponds to common schoolbook problems and
On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger
wrote:
> While we're on the topic, I think you should consider allowing the Fraction()
> constructor to accept a decimal input.
>
> This corresponds to common schoolbook problems and simple client requests:
> "Express 3.5 as a fraction".
>
>
On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger
wrote:
> While we're on the topic, I think you should consider allowing the Fraction()
> constructor to accept a decimal input.
>
> This corresponds to common schoolbook problems and simple client requests:
> "Express 3.5 as a fraction".
>
>
On 22 March 2010 19:32, Mark Dickinson wrote:
> I think getting this to work would involve a lot of extra code and
> significant 'cleverness'. I'd prefer the simple-to-implement and
> simple-to-explain option of rounding the Fraction before performing
> the operation, even if this means that the
While we're on the topic, I think you should consider allowing the Fraction()
constructor to accept a decimal input.
This corresponds to common schoolbook problems and simple client requests:
"Express 3.5 as a fraction".
>>> Fraction(Decimal('3.5'))
Fraction(7, 2)
Unlike typical binary
Pierre B. hotmail.com> writes:
>
> 4. Since the repeating pattern is present at least twice at the end,
> one can augment the precision of the conversion by detecting the
> repetition and adding more. This detection is trivial.
Wrong of me. This point is acutally invalid, since it is i
On Mon, Mar 22, 2010 at 8:02 PM, Pierre B. wrote:
> Sorry to intervene out of the blue, but I find the suggested rule for
> fractional to decimal conversion not as clean as I'd expect.
>
> If fractions are converted to decimals when doing arithmetics, would it be
> worthwhile to at least provide a
Sorry to intervene out of the blue, but I find the suggested rule for
fractional to decimal conversion not as clean as I'd expect.
If fractions are converted to decimals when doing arithmetics, would it be
worthwhile to at least provide a minimum of fractional conversion integrity?
What I have i
On Mon, Mar 22, 2010 at 11:36 AM, Raymond Hettinger
wrote:
> One other thought.
>
> The Decimal constructor should now accept floats as a possible input type.
> Formerly, we separated that out to Decimal.from_float() because
> decimals weren't interoperable with floats.
Not sure this follows; Fra
Raymond Hettinger wrote:
>
> On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
> >
> > Just for the record, I'd also prefer Decimal + Fraction -> Decimal.
>
>
> Guido was persuasive on why float + Fraction --> float,
> so this makes sense for the same reasons.
>
> For the implementation, is
One other thought.
The Decimal constructor should now accept floats as a possible input type.
Formerly, we separated that out to Decimal.from_float() because
decimals weren't interoperable with floats.
This will put decimal and float back on equal footing so that we have both:
float(some_deci
On Mon, Mar 22, 2010 at 7:00 PM, Raymond Hettinger
wrote:
>
> On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
>>
>> Just for the record, I'd also prefer Decimal + Fraction -> Decimal.
>
>
> Guido was persuasive on why float + Fraction --> float,
> so this makes sense for the same reasons.
>
>
Guido van Rossum wrote:
> > Decimal + float --> Decimal
>
> If everybody associated with the Decimal implementation wants this I
> won't stop you; as I repeatedly said my intuition about this one (as
> opposed to the other two above) is very weak.
I've been following the discussion only passiv
On Mar 22, 2010, at 11:54 AM, Guido van Rossum wrote:
>
> So now we have a second-order decision to make -- whether
> Decimal+float should convert the float to Decimal using the current
> context's precision, or do it exactly. I think we should just follow
> Decimal.from_float() here, which AFAIK
On Mon, Mar 22, 2010 at 11:00 AM, Raymond Hettinger
wrote:
>
> On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
>>
>> Just for the record, I'd also prefer Decimal + Fraction -> Decimal.
>
>
> Guido was persuasive on why float + Fraction --> float,
> so this makes sense for the same reasons.
>
>
On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
>
> Just for the record, I'd also prefer Decimal + Fraction -> Decimal.
Guido was persuasive on why float + Fraction --> float,
so this makes sense for the same reasons.
For the implementation, is there a way to avoid the double rounding
in
On Mon, Mar 22, 2010 at 10:26 AM, Mark Dickinson wrote:
> On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
> wrote:
>>
>> On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>>
>> Decimal + float --> Decimal
>>
>> If everybody associated with the Decimal implementation wants this I
>> won't
On Mon, Mar 22, 2010 at 12:26, Mark Dickinson wrote:
> I don't want to let the abstractions of the numeric tower get in the
> way of the practicalities: we should modify the abstractions if
> necessary! In particular, it's not clear to me that all numeric types
> have to be comparable with each
On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
> On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
> wrote:
>>
>> On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>>
>> Decimal + float --> Decimal
>>
>> If everybody associated with the Decimal implementation wants this I
>> won't
On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
wrote:
>
> On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>
> Decimal + float --> Decimal
>
> If everybody associated with the Decimal implementation wants this I
> won't stop you; as I repeatedly said my intuition about this one (as
> op
On Mon, Mar 22, 2010 at 10:22 AM, Alexander Belopolsky
wrote:
> On Mon, Mar 22, 2010 at 1:56 PM, Raymond Hettinger
> wrote:
>>
>> On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>>
>> Decimal + float --> Decimal
>>
>> If everybody associated with the Decimal implementation wants this I
>>
On Mon, Mar 22, 2010 at 1:56 PM, Raymond Hettinger
wrote:
>
> On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>
> Decimal + float --> Decimal
>
> If everybody associated with the Decimal implementation wants this I
> won't stop you; as I repeatedly said my intuition about this one (as
> op
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>
>> Decimal + float --> Decimal
>
> If everybody associated with the Decimal implementation wants this I
> won't stop you; as I repeatedly said my intuition about this one (as
> opposed to the other two above) is very weak.
That's my vote
On Mon, Mar 22, 2010 at 8:39 AM, Raymond Hettinger
wrote:
> My instinct says that we're asking for trouble if comparisons have
> different coercion rules than arithmetic operations.
Sorry, no, this is a station we passed long ago when float-long
comparison was fixed to do the comparison exactly (
On Mar 22, 2010, at 2:23 AM, Mark Dickinson wrote:
> Note that comparisons are a separate issue: those always need to be
> done exactly (at least for equality, and once you're doing it for
> equality it makes sense to make the other comaprisons exact as well),
> else the rule that x == y implies
Raymond Hettinger wrote:
> On Mar 21, 2010, at 3:35 PM, Guido van Rossum wrote:
>>> It seems to me that Decimals and floats should be considered at
>>> the same level (i.e. both implement Real).
>> Agreed, but doesn't help. (Except against the idea that Decimal goes
>> on the "integer" side of Frac
Greg Ewing wrote:
> Raymond Hettinger wrote:
>>
>> Remember, the notion of inexactness is a taint,
>> not an intrinsic property of a type. Even the Scheme numeric
>> tower recognizes this. LIkewise, the decimal specification also
>> spells-out this notion as basic to its design.
>
> I'm not sure
Mark Dickinson wrote:
> But the Fraction type is going to mess this up: for Decimal +
> Fraction -> Decimal, I don't see any other sensible option than to
> convert the Fraction using the current context, since lossless
> conversion isn't generally possible.
Be able to duck this question was pre
On Sun, Mar 21, 2010 at 10:50 PM, Greg Ewing
wrote:
> Raymond Hettinger wrote:
>
>> Since decimal also allows arbitrary sizes, all long ints can be
>> exactly represented (this was even one of the design goals
>> for the decimal module).
>
> There may be something we need to clarify here. I've bee
On Sun, Mar 21, 2010 at 16:59, Steven D'Aprano wrote:
> If naive users are going to use the interpreter as a calculator, they're
> going to start off using floats and ints simply because they require
> less typing. My idea is to allow a gentle learning curve with Decimal
> (and Fraction) without s
On Mar 21, 2010, at 6:24 PM, Guido van Rossum wrote:
> On Sun, Mar 21, 2010 at 4:16 PM, Raymond Hettinger
> wrote:
>>
>> On Mar 21, 2010, at 3:59 PM, Steven D'Aprano wrote:
>>
>>> On Mon, 22 Mar 2010 06:31:57 am Raymond Hettinger wrote:
I really like Guido's idea of a context flag to cont
On Sun, Mar 21, 2010 at 4:16 PM, Raymond Hettinger
wrote:
>
> On Mar 21, 2010, at 3:59 PM, Steven D'Aprano wrote:
>
>> On Mon, 22 Mar 2010 06:31:57 am Raymond Hettinger wrote:
>>> I really like Guido's idea of a context flag to control whether
>>> mixing of decimal and binary floats will issue a w
On Mar 21, 2010, at 3:59 PM, Steven D'Aprano wrote:
> On Mon, 22 Mar 2010 06:31:57 am Raymond Hettinger wrote:
>> I really like Guido's idea of a context flag to control whether
>> mixing of decimal and binary floats will issue a warning.
>> The default should be to issue the warning (because unl
On Mar 21, 2010, at 3:50 PM, Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> Since decimal also allows arbitrary sizes, all long ints can be
>> exactly represented (this was even one of the design goals
>> for the decimal module).
>
> There may be something we need to clarify here. I've been
On Mon, 22 Mar 2010 06:31:57 am Raymond Hettinger wrote:
> I really like Guido's idea of a context flag to control whether
> mixing of decimal and binary floats will issue a warning.
> The default should be to issue the warning (because unless
> you know what you're doing, it is most likely an erro
On Mar 21, 2010, at 3:35 PM, Guido van Rossum wrote:
>
>> It seems to me that Decimals and floats should be considered at
>> the same level (i.e. both implement Real).
>
> Agreed, but doesn't help. (Except against the idea that Decimal goes
> on the "integer" side of Fraction, which is just wron
Raymond Hettinger wrote:
The question of
where to stack decimals in the hierarchy was erroneously
being steered by the concept that both decimal and binary floats
are intrinsically inexact. But that would be incorrect, inexactness
is a taint, the numbers themselves are always exact.
I don't
Raymond Hettinger wrote:
The question of
where to stack decimals in the hierarchy was erroneously
being steered by the concept that both decimal and binary floats
are intrinsically inexact. But that would be incorrect, inexactness
is a taint, the numbers themselves are always exact.
I don't
Raymond Hettinger wrote:
Since decimal also allows arbitrary sizes, all long ints can be
exactly represented (this was even one of the design goals
for the decimal module).
There may be something we need to clarify here. I've been
imagining that the implicit conversions to Decimal that
we're t
On Sun, Mar 21, 2010 at 11:25 AM, Raymond Hettinger
wrote:
> Right. We should be guided by:
> fractions are a superset of decimals which are a superset of binary
> floats.
But mixed Fraction-float operations return floats, not Fractions.
> And by:
> binary floats and decimal floats bot
Raymond Hettinger wrote:
Remember, the notion of inexactness is a taint,
not an intrinsic property of a type. Even the Scheme numeric
tower recognizes this. LIkewise, the decimal specification also
spells-out this notion as basic to its design.
I'm not sure it really does, otherwise every de
On Mar 21, 2010, at 11:50 AM, R. David Murray wrote:
> On Sun, 21 Mar 2010 11:25:34 -0700, Raymond Hettinger
> wrote:
>> It seems to me that Decimals and floats should be considered at
>> the same level (i.e. both implement Real).
>>
>> Mixed Decimal and float should coerce to Decimal because
1 - 100 of 126 matches
Mail list logo
