[Python-3000] Math in Python 3.0
Fredrik Johansson
fredrik.johansson at gmail.com
Fri May 12 13:38:03 CEST 2006
On 5/11/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> IMO, the free mixing decimal and binary floats is not a good idea.
On 5/12/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Er, I thought Decimals were explicitly designed *not*
> to merge seamlessly with floats, so that one can't
> accidentally lose the decimal exactness that one is
> using Decimals for in the first place.
I want to avoid writing code that looks like this:
if isinstance(x, float):
x += 0.1
elif isinstance(x, Decimal):
x += 0.1d
I don't see any difference between mixing binary and decimal floats,
and mixing decimals of different precision. I see why
decimalInstance+0.1 should be illegal if 0.1 evaluates to a binary
float, but the problem goes away if float literals evaluate to
decimals.
On 5/11/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> I write:
> if n&1:
> handle_odd()
> else:
> handle_even()
>IMO, functions like is_even() and is_odd() are clutter. Also, the
>performance of &1 is unlikely to be matched function calls.
In your example, the problem is that same thing has to be stated
twice, so the gain from expressing it differently in different places
is an artificial one. More concretely, I can't recall ever seeing an
explicit reference to "handle_odd" directly after an n&1 test. The
information is usually contained entirely in the if-clause.
> When it comes to numerous small changes, it is better to create a third
> party extension and see how it fares in the real-world. I suspect that
> such a module would be ignored. If that turns out to be true, then it
> means that the additions to the standard library are not warranted.
Agreed, it is better to start by implementing library additions
externally. On the other hand, third-party utility libraries rarely
get used even when they could save trouble, because no one likes
dependencies outside the standard library. My personal utility library
for math-related stuff is decently sizable (about 10K lines of code);
I might pack some of it up for release some day.
Fredrik Johansson
More information about the Python-3000
mailing list