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
Steven D'Aprano wrote:
Then they're in for a terrible, terrible disappointment. Rounding issues
don't go away because you're using Decimal instead of float,
No, but what I mean is that they prefer to be surprised in
unsurprising ways, so to speak.
Everyone knows that floating point numbers ha
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
On Mon, 22 Mar 2010 08:47:53 am Greg Ewing wrote:
> Nick Coghlan wrote:
> > That's fine - binary floats *are* surprising. That's why Decimal
> > exists in the first place.
>
> This argument could equally well be used the other way --
> someone using Decimal is doing so precisely because they
> *don
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 3/21/2010 1:12 PM, Benjamin Peterson wrote:
On behalf of the Python development team, I'm joyful to announce the second
bugfix release of the Python 3.1 series, Python 3.1.2.
Thanks for the work.
This bug fix release fixes numerous issues found in 3.1.1, and is considered a
production rele
Nick Coghlan wrote:
That's fine - binary floats *are* surprising. That's why Decimal exists
in the first place.
This argument could equally well be used the other way --
someone using Decimal is doing so precisely because they
*don't* want to be surprised, in which case they would
probably pre
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
On Sun, Mar 21, 2010 at 00:58, Nick Coghlan 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 completely different
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 it can be
> done losslessly.
>
> There is no need to embed a n
On Mar 21, 2010, at 10:02 AM, Guido van Rossum wrote:
> On Sun, Mar 21, 2010 at 9:53 AM, Guido van Rossum 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 eff
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 resul
>>
>> 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 appe
On behalf of the Python development team, I'm joyful to announce the second
bugfix release of the Python 3.1 series, Python 3.1.2.
This bug fix release fixes numerous issues found in 3.1.1, and is considered a
production release.
The Python 3.1 version series focuses on the stabilization and opti
On Sat, Mar 20, 2010 at 11:59 PM, Nick Coghlan wrote:
> Greg Ewing wrote:
>> Nick Coghlan wrote:
>>
>>> Note that Antoine's point was that float("0.1") and
>>> Decimal.from_float(0.1) should compare equal.
>>
>> That would mean that Decimal("0.1") != float("0.1"), which might be
>> surprising to s
On Sun, Mar 21, 2010 at 9:53 AM, Guido van Rossum 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 function?)
N
On Sat, Mar 20, 2010 at 6:54 PM, Nick Coghlan 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 enough to actual
Hey all,
This seems to happen whenever we do a new release (we've had a couple of
emails to webmas...@python.org about it since 2.6.5 was released). The
main download page for Python has a broken link for the Mac installer
(because it hasn't been built yet I assume):
http://python.org/do
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Note that Antoine's point was that float("0.1") and
>> Decimal.from_float(0.1) should compare equal.
>
> That would mean that Decimal("0.1") != float("0.1"), which might be
> surprising to someone who didn't realise they were mixing floats
> and decima
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 nu
29 matches
Mail list logo
