On Mon, Mar 22, 2010 at 7:52 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Mar 22, 2010 at 11:36 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
One other thought.
The Decimal constructor should now accept floats as a possible input type.
Formerly, we separated that out to
On Thu, Mar 25, 2010 at 1:15 AM, Jeffrey Yasskin jyass...@gmail.com wrote:
On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson dicki...@gmail.com wrote:
Slight change of topic. I've been implementing the extra comparisons
required for the Decimal type and found an anomaly while testing.
Currently
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
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
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 plenty
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 checking
Steven D'Aprano steve at 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
On Thu, Mar 25, 2010 at 04:18, Steven D'Aprano st...@pearwood.info 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
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
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull step...@xemacs.org 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: distinct nans
On Wed, 24 Mar 2010 08:51:36 pm Mark Dickinson wrote:
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull
step...@xemacs.org wrote:
Steven D'Aprano writes:
As usual though, NANs are unintuitive:
d = {float('nan'): 1}
d[float('nan')] = 2
d
{nan: 1, nan: 2}
Mark Dickinson writes:
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull step...@xemacs.org
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.
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 on a proxy
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 mechanisms
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 you not have
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 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 check
On Wed, Mar 24, 2010 at 1:39 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Wed, Mar 24, 2010 at 11:26 AM, Alexander Belopolsky
alexander.belopol...@gmail.com 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
On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky
alexander.belopol...@gmail.com 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
On Wed, Mar 24, 2010 at 2:36 PM, Guido van Rossum gu...@python.org 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
On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson dicki...@gmail.com 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
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 check
Nick Coghlan ncogh...@gmail.com 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
On Wed, Mar 24, 2010 at 11:55 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 2:36 PM, Guido van Rossum gu...@python.org wrote:
..
Probably because we were blindly following the IEEE standard without
understanding it in every detail.
Are you talking
On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson dicki...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky
alexander.belopol...@gmail.com 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
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
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 int()
W00t!
On Wed, Mar 24, 2010 at 1:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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.
On Wed, Mar 24, 2010 at 8:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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, float
On Wed, Mar 24, 2010 at 2:29 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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,
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
On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson dicki...@gmail.com 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
On Tue, Mar 23, 2010 at 12:33 AM, Greg Ewing
greg.ew...@canterbury.ac.nz 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
Facundo Batista facundobati...@gmail.com wrote:
On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum gu...@python.org 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
On Tue, Mar 23, 2010 at 12:09 PM, Stefan Krah ste...@bytereef.org wrote:
Facundo Batista facundobati...@gmail.com wrote:
On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum gu...@python.org wrote:
As a downside, there is the worry that inadvertent mixing of Decimal
and float can compromise
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 could convert
Mark Dickinson dicki...@gmail.com 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:
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 promiscuous
On Tue, Mar 23, 2010 at 3:09 PM, Stefan Krah ste...@bytereef.org wrote:
Mark Dickinson dicki...@gmail.com 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,
On Tue, Mar 23, 2010 at 11:31, Mark Dickinson dicki...@gmail.com 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
On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen rha...@gmail.com 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
On Tue, Mar 23, 2010 at 12:04, Mark Dickinson dicki...@gmail.com wrote:
On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen rha...@gmail.com 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
On Tue, Mar 23, 2010 at 6:07 PM, Adam Olsen rha...@gmail.com wrote:
On Tue, Mar 23, 2010 at 12:04, Mark Dickinson dicki...@gmail.com 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}
On Tue, Mar 23, 2010 at 10:55 AM, Mark Dickinson dicki...@gmail.com wrote:
On Tue, Mar 23, 2010 at 6:07 PM, Adam Olsen rha...@gmail.com wrote:
On Tue, Mar 23, 2010 at 12:04, Mark Dickinson dicki...@gmail.com wrote:
Note that containment tests check identity before equality, so there's
no
On Wed, 24 Mar 2010 05:04:37 am Mark Dickinson wrote:
On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen rha...@gmail.com 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
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 of results for
On Sun, Mar 21, 2010 at 10:50 PM, Greg Ewing
greg.ew...@canterbury.ac.nz 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
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
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 it really
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 Fraction, which
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
On Mon, Mar 22, 2010 at 8:39 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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.
I
On Mon, Mar 22, 2010 at 1:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Mon, Mar 22, 2010 at 10:22 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Mon, Mar 22, 2010 at 1:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
Decimal + float -- Decimal
If everybody associated with
On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
Decimal + float -- Decimal
If everybody associated with the Decimal implementation wants
On Mon, Mar 22, 2010 at 10:26 AM, Mark Dickinson dicki...@gmail.com wrote:
On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
Decimal + float -- Decimal
If everybody associated with the Decimal
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
Guido van Rossum gu...@python.org 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
On Mon, Mar 22, 2010 at 7:00 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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:
Raymond Hettinger raymond.hettin...@gmail.com 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
On Mon, Mar 22, 2010 at 11:36 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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
On Mon, Mar 22, 2010 at 8:02 PM, Pierre B. pierre...@hotmail.com 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
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
On 22 March 2010 19:32, Mark Dickinson dicki...@gmail.com 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
On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Mon, Mar 22, 2010 at 12:45 PM, Mark Dickinson dicki...@gmail.com wrote:
On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
While we're on the topic, I think you should consider allowing the Fraction()
constructor to accept a decimal input.
This
On Mon, Mar 22, 2010 at 8:44 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
While we're on the topic, I think you should consider allowing the Fraction()
constructor to accept a decimal input.
This
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
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
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
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
Raymond Hettinger wrote:
On Mar 20, 2010, at 6:54 PM, Nick Coghlan wrote:
I suggest a 'linearised' numeric tower that looks like:
int - Decimal - Fraction - float - complex
Is that a typo? Shouldn't Decimal and float go between Fraction and
complex?
The abstract numeric tower is:
On Sat, Mar 20, 2010 at 6:54 PM, Nick Coghlan ncogh...@gmail.com wrote:
Guido van Rossum wrote:
I think we should seriously reconsider allowing mixed arithmetic
involving Decimal, not just mixed comparisons.
I'm glad I'm not the only one that started wondering that. I
wasn't quite game
On Sun, Mar 21, 2010 at 9:53 AM, Guido van Rossum gu...@python.org wrote:
Which I still have to review. (Mark, if you're there, could you make a
brief post here on the mathematical definition of the new hash you're
proposing, and why it is both efficient to compute and good (enough)
as a hash
Note that this would involve adding mixed Fraction/Decimal arithmetic as
well as Decimal/float arithmetic.
Yes, that was my intention too.
+1
I placed Decimal to the left of
Fraction to keep Decimal's dependencies clear and because Decimal -
Fraction conversions appear
On Mar 20, 2010, at 9:40 PM, Greg Ewing wrote:
Mark Dickinson wrote:
Except that float is fixed-width (typically 53 bits of precision),
while Decimal allows a user-specified, arbitrarily large, precision;
Yes, but it still has *some* fixed limit at any given
moment, so the result of an
On Mar 21, 2010, at 10:02 AM, Guido van Rossum wrote:
On Sun, Mar 21, 2010 at 9:53 AM, Guido van Rossum gu...@python.org wrote:
Which I still have to review. (Mark, if you're there, could you make a
brief post here on the mathematical definition of the new hash you're
proposing, and why it
On Sun, 21 Mar 2010 11:25:34 -0700, Raymond Hettinger
raymond.hettin...@gmail.com 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 it can be
done losslessly.
There is
On Sun, Mar 21, 2010 at 00:58, Nick Coghlan ncogh...@gmail.com wrote:
I don't actually mind either way - the pragmatic tower is about coding
convenience rather than numeric purity (and mixing Fractions and
Decimals in the same algorithm is somewhat nonsensical - they're
designed for two
On Mar 21, 2010, at 11:50 AM, R. David Murray wrote:
On Sun, 21 Mar 2010 11:25:34 -0700, Raymond Hettinger
raymond.hettin...@gmail.com 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
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
On Sun, Mar 21, 2010 at 11:25 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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
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
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 wrong.)
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 error).
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 Sun, Mar 21, 2010 at 4:16 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Mar 21, 2010, at 6:24 PM, Guido van Rossum wrote:
On Sun, Mar 21, 2010 at 4:16 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Sun, Mar 21, 2010 at 16:59, Steven D'Aprano st...@pearwood.info 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
Mark Dickinson dickinsm at gmail.com writes:
On Fri, Mar 19, 2010 at 9:50 PM, Guido van Rossum guido at python.org
wrote:
There is one choice which I'm not sure about. Should a mixed
float/Decimal operation return a float or a Decimal?
I'll just say that it's much easier to return a
On Sat, Mar 20, 2010 at 09:11, Antoine Pitrou solip...@pitrou.net wrote:
Mark Dickinson dickinsm at gmail.com writes:
On Fri, Mar 19, 2010 at 9:50 PM, Guido van Rossum guido at python.org
wrote:
There is one choice which I'm not sure about. Should a mixed
float/Decimal operation return a
1 - 100 of 115 matches
Mail list logo
