[Ka-Ping Yee]
#- On Thu, 15 Apr 2004, Batista, Facundo wrote:
#- >...
#- > Here I think you're confused. *Precision* is a parameter
#- of the context, and
#- > determines in how many digits you will get the coefficient after an
#- > operation.
#- >
#- > The issue when constructing from float, is how many
#- *positions* after the
#- > decimal point will be relevant when creating from a float.
#-
#- I never mentioned positions, and i don't see any reason why it is
#- necessary to isolate these two ways of specifying precision.
Because they are two totally different concepts. And they're not two ways of
specifying precision.
Precision is the maximum of significant digits the number can have. And
positions is the number of digits after the decimal point at which you want
to round the number you're creating from and discard the other digits.
#- Sometimes
#- it will be useful to specify a number of significant digits and other
#- times it will be useful to specify a number of digits after
#- the decimal
#- point. Both kinds of specification are useful as a context
#- for arithmetic
#- operations and useful when constructing from any type
#- including float.
#-
#- So it would be nice if contexts were able to specify
#- precision in either
#- fashion.
Well. If you want the positions to be included in the context to be used in
arithmetic operations, you're out of spec. And the PEP is for implementing
the "General Decimal Arithmetic Specification", so the answer to that is NO.
#- But that is a separate issue from the one i was trying to raise. To
#- bring up this precision vs. position question is to miss my point.
#-
#- Here is my point, again: Decimal(1.1, significant_digits=4)
#- is unambiguous.
I don't think so. For example:
>>> d = Decimal.Decimal.from_float(25364.1254)
>>> str(d)
'25364.12540000000080908648669719696044921875'
What whould mean here "significant_digits=4"?
To have '2536E2'? You use "precision" to achieve this.
To have '25364.1254'? You use "position" in from_float method to achieve
this.
#- Converting from float is not confusing when the precision is
#- specified
#- (either in terms of significant digits or decimal places).
Don't confuse the terminology. Precision means only one thing, and it's
specified in Cowlishaw work. You can not change that. Maybe all the
discussion doesn't make sense if we talk about different things.
#- I want to supply a context for constructing the Decimal value.
I'm +1 with this. But the context that you supply affect the PRECISION to be
used. It has nothing to do with POSITIONS.
. Facundo

Mike Pall:
> About GC: yes, refcounting is the silent killer.
>... Py_DECREF is awful ... > 3500 locations
Is it always needed?
What if a few common (constant, singleton) objects
(such as None, -1, 0, 1) were declared immortal at
compile-time? They would be created at initial
load in a special untracked pool, and their
tp_dealloc would do nothing.
The slot for tracking references would still be
there, but could be ignored -- even if it went
negative.
Since the reference count no longer has to be
correct (for these objects), the reference
counting macros could optimize to nothing when
they know at compile time that they'll have one
of these constant objects.
-jJ

Is anyone championing PEP 328? This is planned for inclusion in 2.4,
but not much movement has happened. If it's stuck on the decision
whether to use multiple dots (one per level up) or a single dot (to
indicate searching upwards until found), I'm willing to pronounce that
it should be multiple dots.
At least "from . import X" and "from .. import X" are completely clear
and more levels up are not likely to occur in practice...
--Guido van Rossum (home page: http://www.python.org/~guido/)

I'm willing to pay money for someone to write {}.sortedkeys() and/or
sets.Set().sorteditems() (since IANACH (I am not a C hacker)). I'm just
*really* tired of writing what should be a one-liner in three lines:

I wrote:
> I'm willing to pay money for someone to write {}.sortedkeys() and/or
> sets.Set().sorteditems() (since IANACH (I am not a C
> hacker)). I'm just
> *really* tired of writing what should be a one-liner in three lines:
... e.g.
dkeys = d.keys()
dkeys.sort()
for key in dkeys:
instead of:
for key in d.sortedkeys():
Robert Brewer
MIS
Amor Ministries
fumanchu(a)amor.org

[Casey Duncan]
#- I find boolean arguments a general anti-pattern, especially given we
#- have class methods. Why not use an alternate constructor like::
#-
#- pi =
#- Decimal.rounded_to_context("3.1415926535897932384626433832795")
This is a good idea to me.
We all must decide which of the following is better:
a) Decimal(number) # no context used
Decimal(number, context)
b) Decimal(number) # no context used
Decimal.using_context(number, context)
"number" can be string, int, etc., but NOT float. The issue with rounding at
a defined position has nothing to do with context.
. Facundo

[Kevin Jacobs]
#- Don't forget that many financial applications use fixed scale and
#- precision as
#- their primary mechanism for specifying Decimal types. As such, it
#- would be very nice to have a constructor that took a literal
#- representation
#- as well as scale and precision. While using context is
What is "fixed scale"?
Could you provide examples of the functionality that you're asking for?
Thanks.
. Facundo

I had a strange idea for decorator syntax.
def.classmethod func(cls,...):
Multiple decorators are going to need the usual [] thing (or the current
clumsy notation), but the strange thought is allowing
def.iter
so one could be more explicit about defining iterator functions w/out
adding a keyword.
Sorry to beat that dead horse. Back to the real notation.
-- Russell
P.S. one could imagine allowing these, as well,, but I can't imagine
users typing them:
def.func
def.instancemethod

Does anyone have any issues with changing the hash multiplier for the
string and Unicode hash functions?
Instead of 1000003, I would like to use Aho's 65599, a prime near 2**16
that is efficiently expressible as (x << 6) + (x << 16) - x. This
replaces a multiply with fast adds and shifts (with the two shifts
potentially being executed in parallel).
Googling for "hash 65599" shows a long history of widespread use and
testing without any problems.
Raymond Hettinger

Paul Moore:
> Decimal(1.1, significant_digits=34) is unambiguous,
> but confusing.
What would the preferred solution be?
Requiring the user to explicitly type zeros so as to
have 34 digits?
Implicitly doing a Decimal(str(1.1)) and then adding
32 zeros to the internal representation? (Note: in
at least my environment, str(1.1) = '1.1'; it is only
repr that adds the extra digits.)
Living with the fact that it will have some confusing
non-zero digits?
Facundo Batista:
> ... what is "exact conversion" to you:
> 1.1 -> "1.1"
> 1.1 -> "1.1000000000000001"
> 1.1 -> "1.100000000000000088817841970012523233890533447265625"
machine precision of floats, whatever that happens to be.
That implementation-dependent part is one reason to use a
longer name, like exact_float.
But if I say
Decimal(1.1, precision=4)
Decimal(1.1, positions=3)
Those are unambiguous. If the context is 43, then later
calculations will effectively fill in the extra digits;
I have just said to fill them in with zeros, rather than
whatever the float approximations were.
Ka-Ping Yee:
>> I never mentioned positions, and i don't see any reason
>> why it is necessary to isolate these two ways of specifying
>> precision.
Facundo Batista:
> Because they are two totally different concepts. And they're
> not two ways of specifying precision.
Sure they are; the reason to specify positions is that the
underlying data wasn't really floating point -- it was an
integer which by convention is written in a larger unit.
Example with money:
Assume meat is 0.987USD/pound. There are three
price digits to multiply by the weight, but the
final cost is rounded to an integer number of
pennies.
10 pounds cost 9.87, but
1 pound costs 0.99
I don't want to say that my prices have three digits of
precision, or I'll keep fractions of a penny. I don't
want to say that they have only two, or I'll drop the
pennies on expensive items. I want to say that the
precision varies depending on the actual price.
> What whould mean here "significant_digits=4"?
It means precision. In many US classrooms,
"precision" applies to the original measurement.
Once you start doing calculations, it gets called
"significant digits", as a reminder not to let your
answer be more precise than your inputs.
Ka-Ping Yee:
>> Converting from float is not confusing when the
>> precision is specified (either in terms of significant
>> digits or decimal places).
> Don't confuse the terminology. Precision means only one
> thing, and it's specified in Cowlishaw work.
But for any *specific* value, specifying either the total
number of valid digits (signficant figures, precision)
or the number of fractional digits (position) is enough
to determine both.
> "number" can be string, int, etc., but NOT float.
> The issue with rounding at a defined position has
> nothing to do with context.
I assume that a new Decimal would normally be created
with as much precision as the context would need for
calculations. By passing a context/precision/position,
the user is saying "yeah, but this measurement wasn't
that precise in the first place. Use zeros for the
rest, no matter what this number claims."
-jJ