> Raymond Hettinger wrote:
> > IMO, user input (or
> > the full numeric strings in a text data file) is sacred and presumably
> > done for a reason -- the explicitly requested digits should not be
> > throw-away without good reason.
>
> I still don't understand what's so special about the
> input
On Mon, May 23, 2005, Greg Ewing wrote:
>
> But I also found it interesting that, while the spec requires the
> existence of a context for each operation, it apparently *doesn't*
> mandate that it must be kept in a global variable, which is the part
> that makes me uncomfortable.
>
> Was there any
I'd like to respond to a few people, I'll start with Greg Ewing:
Greg writes:
> I don't see how it
> helps significantly to have just the very first
> step -- turning the input into numbers -- be
> exempt from this behaviour. If anything, people
> are going to be even more confused. "But it
> can
Raymond Hettinger wrote:
>>Py> decimal.Decimal("a", context)
>>Decimal("NaN")
>>
>>I'm tempted to suggest deprecating the feature, and say if you want
>>invalid
>>strings to produce NaN, use the create_decimal() method of Context
>>objects.
>
>
> The standard does require a NaN to be produced.
I
Raymond Hettinger wrote:
> Did you see Mike Cowlishaw's posting where he described why he took our
> current position (wysiwig input) in the spec, in Java's BigDecimal, and
> in Rexx's numeric model?
Yes, it appears that you have channeled him correctly
on that point, and Tim hasn't. :-)
But I al
Raymond Hettinger wrote:
> IMO, user input (or
> the full numeric strings in a text data file) is sacred and presumably
> done for a reason -- the explicitly requested digits should not be
> throw-away without good reason.
I still don't understand what's so special about the
input phase that it s
Several people have pointed me at this interesting thread, and
both Tim and Raymond have sent me summaries of their arguments.
Thank you all! I see various things I have written have caused
some confusion, for which I apologise.
The 'right' answer might, in fact, depend somewhat on the
programmin
On 5/21/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> A root difference is that I believe we have both a compliant
> implementation (using Context.create_decimal) and a practical context
> free extension in the form of the regular Decimal constructor.
Please forgive an intrusion by someone wh
Raymond Hettinger wrote:
>>From the mists of Argentina, a Palidan set things right. The literal
> 1.1 became representable and throughout the land the monster was
> believed to have been slain.
I don't understand. Isn't the monster going to pop
right back up again as soon as anyone does any
arit
On Fri, May 20, 2005, Raymond Hettinger wrote:
>
> k.) The biggest client of all these methods is the Decimal module
> itself. Throughout the implementation, the code calls the Decimal
> constructor to create intermediate values. Every one of those calls
> would need to be changed to specify a co
[Tim]
> I'm sorry, but if you mentally reduced everything I've written about
> this to "the sole argument", rational discussion has become impossible
> here.
Forgive me one melodramatic email.
I've laid out my reasoning and understand yours.
Crossing light sabers with one such as yourself is of
> It looks like if you pass in a context, the Decimal constructor still
> ignores that context:
>
> >>> import decimal as d
> >>> d.getcontext().prec = 4
> >>>
d.Decimal("1.234567890123456789012345678901234567890123456789",
> d.getcontext())
> Decimal("1.234567890123456789012345678901234567890
[Guido]
> > You know that, but Raymond seems confused. From one of his posts
(point
> (k)):
[Raymond]
> > "Throughout the implementation, the code calls the Decimal
> > constructor to create intermediate values. Every one of those calls
> > would need to be changed to specify a context."
[Facun
Michael Chermside wrote:
> Frankly, I have no idea WHAT purpose is served by passing a context
> to the decimal constructor... I didn't even realize it was allowed!
As Tim pointed out, it's solely to control whether or not ConversionSyntax
errors are exceptions or not:
Py> decimal.Decimal("a")
T
[Michael Chermside]
> Frankly, I have no idea WHAT purpose is served by passing a context
> to the decimal constructor... I didn't even realize it was allowed!
Quoth the docs for the Decimal constructor:
"""
The context precision does not affect how many digits are stored. That
is determined excl
On 5/20/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Python's Decimal constructor accepts a context argument, but the only
> > use made of it is to possibly signal a ConversionSyntax condition.
>
> You know that, but Raymond seems confused. From one of his posts (point (k)):
>
> "Through
> [Guido]
> > It looks like if you pass in a context, the Decimal constructor
> > still ignores that context:
> >
> > >>> import decimal as d
> > >>> d.getcontext().prec = 4
> > >>> d.Decimal("1.234567890123456789012345678901234567890123456789",
> > d.getcontext())
> > Decimal("1.23456789012345
Guido writes:
> It looks like if you pass in a context, the Decimal constructor still
> ignores that context
No, you just need to use the right syntax. The correct syntax for
converting a string to a Decimal using a context object is to use
the create_decimal() method of the context object:
>>> i
[Guido]
> It looks like if you pass in a context, the Decimal constructor
> still ignores that context:
>
> >>> import decimal as d
> >>> d.getcontext().prec = 4
> >>> d.Decimal("1.234567890123456789012345678901234567890123456789",
> d.getcontext())
> Decimal("1.2345678901234567890123456789012
It looks like if you pass in a context, the Decimal constructor still
ignores that context:
>>> import decimal as d
>>> d.getcontext().prec = 4
>>> d.Decimal("1.234567890123456789012345678901234567890123456789",
d.getcontext())
Decimal("1.234567890123456789012345678901234567890123456789")
[Raymond Hettinger]
> The word deviate inaccurately suggests that we do not have
> a compliant method which, of course, we do. There are two
> methods, one context aware and the other context free. The
> proposal is to change the behavior of the context free version,
> treat it as a bug, and alte
On 5/20/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> In other words, Java's behavior is much closer to the current behavior
> of Python, at least in terms of features that are user-visible. The
> default behavior in Java is to have infinite precision unless a context
> is supplied that says
> Does it really need to be argued interminably that deviating from a
> standard is a Big Deal?
The word deviate inaccurately suggests that we do not have a compliant
method which, of course, we do. There are two methods, one context
aware and the other context free. The proposal is to change t
On 5/20/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> That's not my interest here. My interest is in a consistent,
Point. Every time I explain Decimal, I have to say "always the context
is applied EXCEPT at construction time".
> > If someone wants to craft another module to wrap around and
> >
Tim Peters writes:
> Other important
> implementations of the standard didn't make this mistake; for example,
> Java's BigDecimal|(java.lang.String) constructor follows the rules
> here:
[...]
> Hmm -- or maybe it doesn't! The text says:
[...]
Here is the actual behavior:
Maybe they just meant it as an explanation of "standard form",
clarifying that -0 is turned into +0? (That's what adding 0 does,
right?)
On 5/20/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim Peters]
> > ...
> > Other important implementations of the standard didn't
> > make this mistake; for ex
[Tim Peters]
> ...
> Other important implementations of the standard didn't
> make this mistake; for example, Java's BigDecimal
> (java.lang.String) constructor follows the rules here:
>
>http://www2.hursley.ibm.com/decimalj/deccons.html
Hmm -- or maybe it doesn't! The text says:
The Big
[Michael Chermside]
> Tim, I find Raymond's arguments to be much more persuasive.
> (And that's even BEFORE I read his 11-point missive.) I
> understood the concept that *operations* are context-
> dependent, but decimal *objects* are not, and thus it made
> sense to me that *constructors* were not
[Tim and Raymond are slugging it out about whether Decimal constructors
should respect context precision]
Tim, I find Raymond's arguments to be much more persuasive. (And that's
even BEFORE I read his 11-point missive.) I understood the concept that
*operations* are contex-dependent, but decimal
Raymond Hettinger wrote:
> Be careful with this proposed change. It is a can of worms.
> Better yet, don't do it. We already have a context aware
> constructor method if that is what you really want.
And don't forgot that 'context-aware-construction' can also be written:
val = +Decimal(strin
Addenda:
j.) The same rules would need to apply to all forms of the Decimal
contructor, so Decimal(someint) would also need to truncate/round if it
has more than precision digits -- likewise with Decimal(fromtuple) and
Decimal(fromdecimal). All are problematic. Integer conversions are
expected t
I sense a religious fervor about this so go ahead and do whatever you
want.
Please register my -1 for the following reasons:
a.) It re-introduces representation error into a module that worked so
hard to overcome that very problem. The PEP explicitly promises that a
transformation from a literal
[Guido van Rossum]
> I know I should stay out of here,
Hey, it's still your language .
> but isn't Decimal() with a string literal as argument a rare
> case (except in examples)? It's like float() with a string
> argument -- while you *can* write float("1.01"), nobody does
> that. What people do
I know I should stay out of here, but isn't Decimal() with a string
literal as argument a rare case (except in examples)? It's like
float() with a string argument -- while you *can* write float("1.01"),
nobody does that. What people do all the time is parse a number out of
some larger context into
Sorry, I simply can't make more time for this. Shotgun mode:
[Raymond]
> I have no such thoughts but do strongly prefer the current
> design.
How can you strongly prefer it? You asked me whether I typed floats
with more than 28 significant digits. Not usually . Do you?
If you don't either, h
[Tim suggesting that I'm clueless and dazzled by sparkling lights]
> There seems to be an unspoken "wow that's cool!" kind of belief
> that because Python's Decimal representation is _potentially_
> unbounded, the constructor should build an object big enough to
> hold any argument exactly (up t
[Raymond Hettinger]
> For brevity, the above example used the context free
> constructor, but the point was to show the consequence
> of a precision change.
Yes, I understood your point. I was making a different point:
"changing precision" isn't needed _at all_ to get surprises from a
constructo
On 5/18/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >>> from decimal import getcontext
> >>> context = getcontext()
> >>> x = context.create_decimal('3.104')
> >>> y = context.create_decimal('2.104')
> >>> z = context.create_decimal('0.000')
> >>> context.prec = 3
> >>> x + y
> Decimal("5.
[Raymond]
> > The following example shows the kind of oddity that can arise when
> > working with quantities that have not been rounded to the current
> precision:
> >
> > >>> from decimal import getcontext, Decimal as D
> > >>> getcontext().prec = 3
> > >>> D('3.104') + D('2.104')
> > Decimal("5.2
39 matches
Mail list logo
