Greg Ewing wrote:
Raymond Hettinger wrote:
I think this would harm more than it would help. It more confusing to
have several rounding-thingies to choose from than it is have an
explicit two-step.
But is it more confusing enough to be worth forcing
everyone to pay two function calls
Martin v. Löwis wrote:
Anthony Baxter schrieb:
In any case, I bumped the version number to 2.5, according to the
policy discussed in
Could this not simply use the Python version number directly, instead?
See the prior discussion at
Travis Oliphant wrote:
Probably the most interesting thing now would be for Travis to review
it, and see whether it makes things easier to handle for the Numeric
scalar types (given the amount of code the patch deleted from the
builtin and standard library data types, hopefully the benefits
M.-A. Lemburg wrote:
I suppose you don't know about the optional argument
to round that lets you round up to a certain decimal ?!
Yes, I know about, but I rarely if ever use it.
Rounding a binary float to a number of decimal
places seems a fundamentally ill-considered thing
to do anyway. What
Greg Ewing wrote:
M.-A. Lemburg wrote:
I suppose you don't know about the optional argument
to round that lets you round up to a certain decimal ?!
Yes, I know about, but I rarely if ever use it.
Rounding a binary float to a number of decimal
places seems a fundamentally ill-considered
M.-A. Lemburg [EMAIL PROTECTED] wrote:
You often have a need for controlled rounding when doing
financial calculations or in situations where you want to
compare two floats with a given accuracy, e.g. to work
around rounding problems ;-)
The latter is a crude hack, and was traditionally used
On Tue, Aug 01, 2006, M.-A. Lemburg wrote:
You often have a need for controlled rounding when doing financial
calculations or in situations where you want to compare two floats
with a given accuracy, e.g. to work around rounding problems ;-)
The usual approach is to use full float accuracy
Aahz [EMAIL PROTECTED] wrote:
On Tue, Aug 01, 2006, M.-A. Lemburg wrote:
You often have a need for controlled rounding when doing financial
calculations or in situations where you want to compare two floats
with a given accuracy, e.g. to work around rounding problems ;-)
The usual
Nick Maclaren wrote:
Well, maybe. There are other approaches, too, and Decimal has its
problems with that. In particular, when people need precisely
defined decimal rounding, they ALWAYS need fixed-point and not
floating-point.
The decimal spec was designed to encompass both
Raymond Hettinger [EMAIL PROTECTED] wrote:
Hogwash.nbsp; The only issues with decimal are ease-of-use and speed.br
I suggest that you get hold of a good 1960s or 1970s book on computer
arithmetic, and read up about wobbling precision. While it is not
a big deal, it was regarded as such, and is
Nick Coghlan wrote:
Travis Oliphant wrote:
Probably the most interesting thing now would be for Travis to review
it, and see whether it makes things easier to handle for the Numeric
scalar types (given the amount of code the patch deleted from the
builtin and standard library data types,
This has probably been discussed before, however ...
Is there any reason to use clock_gettime() in preference to gettimeofday()
if it exists? It pretends to at least return seconds + nanoseconds, where
gettimeofday() returns seconds + microseconds. Are there perhaps some
platforms where it's
Nick Maclaren wrote:
M.-A. Lemburg [EMAIL PROTECTED] wrote:
You often have a need for controlled rounding when doing
financial calculations or in situations where you want to
compare two floats with a given accuracy, e.g. to work
around rounding problems ;-)
The latter is a crude hack, and
We seem to have stumbled upon some strange behavior in cPickle's memo
use when pickling instances.
Here's the repro:
[mymodule.py]
class C:
def __getstate__(self): return ('s1', 's2', 's3')
[interactive interpreter]
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
[Bruce Christensen]
We seem to have stumbled upon some strange behavior in cPickle's memo
use when pickling instances.
Here's the repro:
[mymodule.py]
class C:
def __getstate__(self): return ('s1', 's2', 's3')
[interactive interpreter]
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC
M.-A. Lemburg wrote:
You often have a need for controlled rounding when doing
financial calculations
You should NOT be using binary floats for money
in the first place.
or in situations where you want to
compare two floats with a given accuracy,
Pseudo-rounding to decimal places is not
On Sat, 29 Jul 2006 15:44:33 +1200
Greg Ewing [EMAIL PROTECTED] wrote:
Michael Urman wrote:
The fact that
round returns a float rather than an int, while intentional, does not
feature prominently in one's mine when the first version yielded the
expected results.
As an aside, does
I'm wondering if the following change should be made to Include/weakrefobject.h:
-PyAPI_FUNC(long) _PyWeakref_GetWeakrefCount(PyWeakReference *head);
+PyAPI_FUNC(Py_ssize_t) _PyWeakref_GetWeakrefCount(PyWeakReference *head);
And the 2 other files which use this (weakref obj and module). Should
[Neal Norwitz]
I'm wondering if the following change should be made to
Include/weakrefobject.h:
Yes.
-PyAPI_FUNC(long) _PyWeakref_GetWeakrefCount(PyWeakReference *head);
+PyAPI_FUNC(Py_ssize_t) _PyWeakref_GetWeakrefCount(PyWeakReference *head);
And the 2 other files which use this
Neal Norwitz wrote:
I'm wondering if the following change should be made to
Include/weakrefobject.h:
On Wednesday 02 August 2006 00:53, Tim Peters wrote:
Yes.
...
+1 on biting the bullet for 2.5.
Agreed. This should definately go with the rest of the Py_ssize_t changes.
-Fred
--
Patch / Bug Summary
___
Patches : 396 open ( -5) / 3354 closed (+12) / 3750 total ( +7)
Bugs: 864 open (-32) / 6087 closed (+52) / 6951 total (+20)
RFE : 226 open ( +2) / 234 closed ( +1) / 460 total ( +3)
New / Reopened Patches
__
Move
21 matches
Mail list logo
