Mark Dickinson added the comment:
Committed, revision 59929.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1780>
__
___
P
Mark Dickinson added the comment:
About .trim and .approximate:
it sounds like these are different, but quite closely related, methods: one
takes a positive
integer and returns the best approximation with denominator bounded by that
integer; the other
returns the 'smallest' r
Mark Dickinson added the comment:
I spoke too soon. This came up again in the discussion for issue #1780
and there was general support for allowing trailing and leading
whitespace.
Fixed for Python 2.6, revision 59929
--
resolution: -> fixed
status: open -> closed
supe
New submission from Mark Dickinson:
Division of two longs can produce results that are needlessly
inaccurate:
>>> from __future__ import division
>>> 10**40/10**39
10.002
The correct result is, of course, 10.0, which is exactly representable
as a float.
The a
Changes by Mark Dickinson:
--
components: +Interpreter Core
versions: +Python 2.6, Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1811>
__
___
Mark Dickinson added the comment:
It would be easy and safe to just use a/b = float(a)/float(b) if both a and b
are less
than 2**53 (assuming IEEE doubles). Then there wouldn't be any loss of speed
for
small integers.
For large integers the algorithm I posted should run in time line
Mark Dickinson added the comment:
For Python 3.0, this is a trivial fix: two lines need to be removed
from PyLong_FromString in longobject.c, and then the tests in
test_builtin need to be fixed up.
(For Python 2.6, the fix would be a bit more involved: PyOS_strtol
would also need fixing
Mark Dickinson added the comment:
Tim: is this worth fixing?
--
nosy: +tim_one
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1811>
__
___
Python-bugs-
Mark Dickinson added the comment:
The latest version of rational.py looks good to me---nice work! (I haven't
looked properly at
numbers.py or test_rational.py, yet. I do plan to, eventually.)
I do think it's important to be able to create Rational instances from strings:
e.g.,
Mark Dickinson added the comment:
Just had a quick look at numbers.py. Only two comments:
1. I think there's a typo in the docstring for Inexact: one of those == should
be a !=
2. Not that it really matters now, but note that at least for Decimal, x-y is
not the same
as x+(-y)
Mark Dickinson added the comment:
> Inexact is saying that one thing could be ==3 and the other ==0, so I
> think it's correct.
You're right, of course :)
__
Tracker <[EMAIL PROTECTED]>
<http://
Mark Dickinson added the comment:
A related problem is that float(n) isn't always correctly rounded for an
integer
n. A contrived example:
>>> n = 2**68 + 2**16 - 1
>>> float(n)
2.9514790517935283e+20
Here the difference between float(n) and the true value of n is a
Mark Dickinson added the comment:
Could you give an example showing the unexpected behaviour, and
describing what behaviour you'd expect, please?
As far as I can tell, the patch has no effect on textwrap.wrap or
textwrap.fill, since any newlines have already been converted to spaces
b
Mark Dickinson added the comment:
Is it worth double checking with Greg Ward that this behaviour really is
intentional?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Mark Dickinson added the comment:
For what it's worth, I think there is a legitimate complaint here, though it
was initially
unclear to me exactly what that complaint was. Consider the following:
>>> from textwrap import *
>>> T = TextWrapper(replace_whitespace=False,
Mark Hammond added the comment:
I'm not sure why the approach of "load-em-all" is being taken.
Interestingly, SHGetFolderPathW is listed as deprecated, so I doubt that
list will grow too much, but the implementation as specified prevents
the user from using other facilities av
Mark Dickinson added the comment:
I'm closing this as invalid.
--
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Dickinson added the comment:
Raymond:
> Were the new methods part of the spec update? If so that's great.
Yes. See http://www2.hursley.ibm.com/decimal/damisc.html
> If not, we need to take them out. We want zero API creep that isn't
> mandated by the spec (no pla
New submission from Mark Dickinson:
The documentation for the builtin round(x, n) says:
"Values are rounded to the closest multiple of 10 to the power minus n."
This isn't always true; for example:
Python 2.6a0 (trunk:59634M, Dec 31 2007, 17:27:56)
[GCC 4.0.1 (Apple Compu
Mark Dickinson added the comment:
(About the latest patch): this all looks good to me.
The comment that "Decimal provides no other public way to detect nan and
infinity." is not
true (though it once was). Decimal has public methods is_nan and is_infinite,
added as
part of updat
Mark Dickinson added the comment:
See also issue #923643.
--
nosy: +marketdickinson
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1023290>
_
___
Mark Dickinson added the comment:
It seems to me that this issue is almost entirely subsumed by issue #1023290.
I'm quite tempted
to close this and direct further discussion there---personally, I'd support
Josiah's proposed
struct addition.
Paul: if you're still list
Mark Dickinson added the comment:
It's a little odd: the relevant code is in floatobject.c, in _PyFloat_Pack4.
The
issue is what happens when a Python float (stored internally as a platform
double)
is packed as an IEEE-754 single-precision float. The current code doesn'
Mark Dickinson added the comment:
Aha: the C99 standard, section 6.3.1.5, says:
When a double is demoted to float, a long double is demoted to double or
float, or a value being represented in greater precision and range than
required by its
semantic type (see 6.3.1.8) is explicitly converted
Mark Dickinson added the comment:
George: I'm certainly still interested in having asinh, acosh and atanh in
math---I'm
not sure about anyone else, but I consider these three functions to be basic
ingredients in any math library. They even appear in most calculus texts. And
th
Mark Dickinson added the comment:
Here's a patch that fixes the test that Collin mentioned to reflect what's
actually been
happening for the last nearly 5 years, and changes _PyFloat_Pack4 and
_PyFloat_Pack8, as
follows.
When packing a float that's too large for the destinat
Mark Dickinson added the comment:
Excellent! I'll take a look.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1640>
__
___
Python-bugs-list mailing list
U
Mark Dickinson added the comment:
One question: is there a policy on what should happen for singularities and
domain errors? If
not, I think it would be useful to have one. Following the policy may not be
achievable on all
platforms, but it should be easy to do on major platforms, and at
Mark Dickinson added the comment:
whoops. OverflowError should be something else in the previous post; of
course,
OverflowError is inappropriate for domain errors (but entirely appropriate for
something like exp(1000)).
Currently, on Linux I get:
- overflow (exp(1000
Mark Dickinson added the comment:
Okay: for now, I guess we just follow the pattern that already exists on
Linux and Windows.
I think the OS X sqrt(-1) behaviour is a bug.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Mark Dickinson added the comment:
No: IEEE-754r and the C99 standard both say clearly that atanh(1) should be
infinity
and atanh(-1) should be -infinity, and furthermore that the 'divide-by-zero'
exception
should be raised rather than the 'invalid' exception. It's
Mark Dickinson added the comment:
George: I think my last post was a bit rude. I apologize if it came across
that way.
Mathematical rigor and IEEE-754 recommendations aren't necessarily in conflict
here,
though. For example, the natural log function from (0, infinity) to
(-inf
New submission from Mark Dickinson:
On OS X 10.4, and probably other versions of OS X too, calls to math.log and
math.sqrt that
should raise ValueError instead return a NaN:
Python 2.6a0 (trunk:60144, Jan 20 2008, 21:43:56)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "
Mark Dickinson added the comment:
Thanks, Tim!
Dare I suggest extending these rules to encompass things like sqrt(NaN),
log(inf), etc.,
as follows:
- return a special value in Python where IEEE-754r/C99 specifies a special
value, but
doesn't raise any of the three divide-by-zero, in
Mark Dickinson added the comment:
I'm not sure either that such a generalization would belong in math (which
right now
does little more than expose some basic functions from the C library) or that
it
should be called hypot.
It seems to me that this would belong with other vector-type
Mark Dickinson added the comment:
Christian: I'm definitely not proposing atanh(1) = inf: it should raise
ValueError. I'm proposing that we follow Tim's rules for now; this means no
change for finite inputs.
The new thing here is that since you've made inf and nan
Mark Dickinson added the comment:
Christian: would it be possible for you to tell me what the argument of the
log1p call is on Windows in that last branch of c_atanh, for the testcase
atanh0022.
On OS X I get:
Input to log1p is 3.2451855365842669075e+32
It's hard to imagine that th
Mark Dickinson added the comment:
Okay: here's an attempted guess at what's happening on Windows:
Near the end of c_atanh, there's a line that reads:
r.real = log1p(4.*z.real/((1-z.real)*(1-z.real) + ay*ay))/4.;
Somehow, when z.real is 0.99989 and ay is 0, the ar
Mark Dickinson added the comment:
Sorry: those lines should have been:
double temp = 1-z.real;
printf("temp is %.19e\n", temp);
r.real = log1p(4.*z.real/(temp*temp + ay*ay))/4.;
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Mark Dickinson added the comment:
This is a duplicate of issue #1742669
--
nosy: +marketdickinson
resolution: -> duplicate
status: open -> closed
superseder: -> "%d" format handling for long values
_
Tracker <[E
Mark Dickinson added the comment:
Sorry: I should have read more carefully. So math.atanh works on Linux
but is producing some strange results on Windows.
It's still rather puzzling though. I still suspect that it's the
argument to log1p that's coming out wrong rather
Mark Dickinson added the comment:
The problem with atanh is that it should be using absx throughout, rather than
x.
So in "if (absx < 0.5)" branch and the following branch, replace all
occurrences of x with
absx, and it should work.
One other comment: asinh shouldn't dire
Mark Dickinson added the comment:
Also, for the C-level routines, atanh(1.0) and atanh(-1.0) should definitely
return
infinity and -infinity (and probably set errno as well.)
Note that this is not an argument about what Python should do: Python will
still raise a
ValueError for atanh(1.0
Mark Dickinson added the comment:
One more comment: the Py_IS_NAN test in acosh is likely never reached, since
the
comparison x >= two_pow_p28 will probably evaluate to 0 when x is a NaN.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Mark Dickinson added the comment:
Also: -1.0 shouldn't be returned at this level to indicate an error; these
are pure C functions
we're writing---the Python wrappers, and Python error conventions, apply
further up the chain
somewhere.
Just so I'm doing something a little mo
Mark Dickinson added the comment:
This was fixed in the trunk in revision 57284. I've backported the fix to
Python 2.5.2 in revision
60183.
Leaving this open because there's still a problem for complex numbers, though I
guess this is less
likely to bite people:
Python 2.6a0 (tr
Mark Dickinson added the comment:
Here's a patch, against the trunk, that imitates Alex's fix for the complex
case.
--
keywords: +patch
Added file: http://bugs.python.org/file9255/plus_minus_0j.patch
_
Tracker <[EMAIL PROT
Mark Dickinson added the comment:
This can be closed, I think: it's already been fixed in the trunk (with a
different
fix, also due to Alex, from the one given here) and the fix has been backported
to
2.5.2.
Not sure what the appropriate resolution is here; plumping for 'o
Mark Dickinson added the comment:
Hmmm.
For atanh(1): raising OverflowError is actually consistent with what currently
happens.
The only singularity that's already present in math is log(0), and it seems
that that
raises OverflowError on OS X, Linux and Windows... I wonder whether
New submission from Mark Summerfield:
I am using:
Python 3.0a2 (r30a2:59382, Dec 17 2007, 08:47:22)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
IDLE 3.0a1
This seems wrong:
>>> while False:
print("no")
else:
print("yes")
>
Mark Dickinson added the comment:
This bug is also present in the trunk, with while 0 instead of while
False.
This appears closely related to issue #1875.
In my opinion this is a serious bug in the core language. I'm not sure
whether it's serious enough to be considered a shows
Mark Dickinson added the comment:
See also issue #1920
--
nosy: +marketdickinson
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1875>
__
___
Python-bugs-
Mark Dickinson added the comment:
Looks like Amaury found his svn access. Is it okay to close this now?
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson added the comment:
Forgot to say: Amaury checked his fix in in revision #60265 (trunk) and
revision #60268 (Python 2.5).
Thanks for the bug report, Mark!
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Changes by Mark Dickinson:
--
resolution: -> duplicate
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1933>
__
___
Python
Mark Dickinson added the comment:
I noticed that the ability to type Rational("2.3") has been added (and I
think this is a very useful addition). One minor nit: would it make
sense to have Rational("2.") and Rational(".3") also work? These strings
work for flo
Mark Dickinson added the comment:
Closing this due to little-or-no activity for over three years. Antoine's
use case seems to me to be covered by issue #1023290.
Trevor, please speak up if you want to keep this alive.
--
resolution: -> rejected
status: open -> pending
Mark Dickinson added the comment:
I can reproduce this in the trunk, on OS X 10.5.1/Intel: after a
./configure --enable-framework && make && sudo make altinstall
ctrl-clicking on a simple python file on the Desktop and selecting OpenWith ->
PythonLauncher fails to run th
New submission from Mark Dickinson:
For Python 3.0 the decimal module got rich comparisons. Those comparisons have
somewhat unconventional
behavior with respect to NaNs, as seen below: <, <= and == comparisons
involving NaNs always return False,
while >, >= and != comparisons a
Mark Dickinson added the comment:
Yes, I think it's necessary.
Speaking of standards, it's the current behavior which isn't backed by any
standard or rationale other than the historical one involving now-defunct 3-
way comparisons.
The proposed behavior is much closer to that s
Mark Dickinson added the comment:
Here's a patch (richcmp_signal.patch) that gives an alternative way of doing
things: all
<, <=, > and >= comparisons involving a NaN raise the InvalidOperation flag
(using exactly
the same semantics as those specified for compar
Mark Dickinson added the comment:
Bug identifying 0j and -0j fixed for Python 2.6 in revision 60483.
Martin, can this be backported to 2.5.2? I'll assume not, unless I hear
otherwise from you.
--
status: open -> pending
_
Tracker <[EMAI
Mark Dickinson added the comment:
See issue #1979 for a possible fix.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1514428>
_
___
Python-bugs-list
Mark Dickinson added the comment:
About Rational('3.') and Rational('.2'):
It's not so much to do with consistency with float and Decimal; more to do
with the fact that some people like to write floats these ways (which
presumably is why float and Decimal allow such
Mark Dickinson added the comment:
Regex changed in r60530.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1682>
__
___
Python-bugs-list mailing list
Unsubs
Mark Dickinson added the comment:
I assume this is on OS X 10.4? I can't reproduce the failure on Leopard.
--
nosy: +marketdickinson
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Mark Dickinson added the comment:
I'm stealing this issue from Tim, and downgrading the priority to normal
(it was the original bug that was high priority).
--
assignee: tim_one -> marketdickinson
priority: high -> normal
versions: +Python 2.6,
Mark Dickinson added the comment:
Okay: I checked in this change in r60630. The checkin includes comments
in the code and an extra paragraph describing this behavior in the
documentation.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Mark Dickinson added the comment:
Fixed for Python 2.6 in r60630.
--
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Mark Dickinson added the comment:
I think the docs do a good job of explaining this; in particular, they
say,
in http://docs.python.org/dev/reference/datamodel.html#special-method-
names:
"However, built-in types in CPython currently still implement
__getslice__()."
and ex
Mark Dickinson added the comment:
Well, documentation patches are always welcome, I believe :)
If you can point to a particular place in the documentation and suggest
alternative (or extra) wording that might help, post it here and I'll deal
with it.
--
resolution: -> invali
Mark Dickinson added the comment:
Closing.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1979>
__
_
Mark Dickinson added the comment:
from Guido:
> I have one minor nit on the current rational.py code: all internal
> accesses to the numerator and denominator should use self._numerator
> and self._denominator -- going through the properties makes it *much*
> slower. Remember
Mark Dickinson added the comment:
Guido:
> Correct -- the thing is that you can't know the signature of the
> subclass's constructor so you can't very well blindly call that.
Jeffrey, is it okay for me to change the three class methods
(from_float, from_decimal, from_c
Mark Dickinson added the comment:
staticmethod substituted for classmethod in r60712.
I'm not sure I like the idea of names Rational and Fraction; the two
classes numbers.Rational and rational.Rational are quite different beasts,
and using two almost-synonyms for their names seems like
Mark Dickinson added the comment:
We still need to sort out the trim/approximate/convergents decisions.
Currently, we have:
from_continued_fraction
to_continued_fraction
approximate (what we've been calling trim: limit the denominator)
At this point I'm not sure how much I
Mark Dickinson added the comment:
Fair enough. Should it be fractions.Fraction or fraction.Fraction?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1682>
__
___
Mark Dickinson added the comment:
Any reason not to make the name change? Is further discussion/time
required, or can we go ahead and rename Rational to Fraction and
rational.py to fractions.py? It seems like everybody's happy with the
idea.
I note that the name change affects Lib
Mark Dickinson added the comment:
Name change in r60721.
--
title: Move Demo/classes/Rat.py to Lib/rational.py and fix it up. -> Move
Demo/classes/Rat.py to Lib/fractions.py and fix it up.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Mark Dickinson added the comment:
I just checked in another very minor change in r60723. The repr of a
Fraction now looks like Fraction(1, 2) instead of Fraction(1,2). Let me
know if this change is more controversial than I think it is.
__
Tracker <[EM
Mark Dickinson added the comment:
A late comment: I agree with Ronald here; mightn't it make more sense
to raise an exception (ValueError?) for long(float("nan"))?
For comparison, long(float("inf")) currently raises OverflowError, at
least on OS X.
Mark Dickinson added the comment:
> BTW I think the next goal should be to reduce the cost of constructing
> a Fraction out of to plain ints by at least an order of magnitude. I
> believe this is possible.
I certainly hope so! Here's a very simple (and simplistic) benchmark:
# s
Mark Dickinson added the comment:
limit_denominator implemented in r60752
from_decimal and from_float restored to classmethods in r60754
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Mark Dickinson added the comment:
Okay, Nick; you've got me convinced. For some reason I wasn't really
thinking of these methods as alternative constructors---in this light,
your arguments about doing the same as __new__, and about established
patterns, make perfect sense.
Looki
Mark Dickinson added the comment:
Nick Coghlan wrote:
> I mentioned my dislike of the classmethod->staticmethod change on the
> python-checkins list, but given the lack of response there, I figure I
> should bring it up here.
Yes, I missed it. Apologies. I'll rethink this (
Mark Dickinson added the comment:
Thanks for the report!
It looks like this was previously reported in issue #1575746, and has
been fixed in the 2.5 maintenance branch and the trunk. Python 2.5.2
should be out any day now; the fix should then hit docs.python.org.
--
nosy
Mark Dickinson added the comment:
Closing.
--
status: pending -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1678380>
_
___
Python-bu
Mark Dickinson added the comment:
I'm guessing that you used the 'search in open issues' box at the top
right. Of course, the problem is that this issue was already closed.
Instead, go to 'Search' on the left-hand side under 'Issues', enter
'pro
Mark Dickinson added the comment:
I should have added:
You can also check the in-development version of the documentation at
docs.python.org/dev
to see if it's already been fixed.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Mark Dickinson added the comment:
It looks like you've got a stale normalize.decTest file in
Lib/test/decimaltestdata. This file shouldn't be present. Can you do a
fresh svn checkout and see if the problem persists?
--
nosy: +marke
Mark Dickinson added the comment:
Hmm. But others may run into this problem as well.
Is there any way to force the upgrade install to remove this file?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Mark Dickinson added the comment:
A cheap and easy fix would be to update normalize.decTest so that's it's
an exact copy of reduce.decTest. This would result in all the
normalization tests being run twice, but that's probably better than
seeing failing tests.
(What happened he
Mark Dickinson added the comment:
I can take a look at this if you like. But I don't want to spoil your fun
:)
--
nosy: +marketdickinson
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Mark Dickinson added the comment:
I don't think it would be appropriate to add this as a method of int;
it seems like unnecessary clutter on a core type.
Perhaps a math.factorial function could be considered? Historically,
the math module has just been a way to wrap the (mostly floating-
Mark Dickinson added the comment:
> Yeah, it's a one-liner, but so is hypot
Except that hypot is not a one-liner, if you want to get edge cases
right. (Consider hypot(1e200, 1e200), or hypot(1e-200, 1e-200).)
__
Tracker <[EMAIL PROTEC
Mark Dickinson added the comment:
> Should there be some upper limit on the argument math.factorial would
take?
I'd say not. Any such limit would be artificial, and an arbitrary
choice. Just let the natural time and space requirements be the
limitin
Mark Dickinson added the comment:
I know I'm coming a bit late to this discussion, but I wanted to point
out that the C99 standard does actually specify how many digits should
be in the exponent of a "%e"-formatted number:
In section 7.19.6, in the documentation for fprintf,
Mark Dickinson added the comment:
Two things:
(1) Speedup. I haven't been helping much here; apologies. Christian
suggested that a C implementation of gcd might help. Is this true, or
are we not yet at the stage where the gcd calls are significant? There
are some basic tricks tha
Mark Dickinson added the comment:
> Since the domain and range are ints/longs, this makes more sense as a
> method on than as a math module function.
Fair enough. Raymond, do you have any thoughts on where a gcd
implementation might most usefully live? Should it stay in
fractions.
Mark Dickinson added the comment:
The other issue here is that I see factorial as being the thin end of
the
wedge. If factorial were implemented, it would probably only be on the
order of minutes before people wanted to know where the binomial()
function was.
So it seems to me that either
2201 - 2300 of 12223 matches
Mail list logo