Mark Dickinson added the comment:
Roumen: good catch! Indeed, nested functions aren't legal in standard C, and
the test for -fno-strict-aliasing now fails on my OS X 10.6.3 machine, where it
used to pass:
checking whether gcc accepts -fno-strict-aliasing... no
config.log con
Mark Dickinson added the comment:
Merged to py3k, and fixed up an additional nested 'int main()', in r81078.
--
___
Python tracker
<http://bugs.python.
Changes by Mark Dickinson :
--
assignee: -> rhettinger
nosy: +rhettinger
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue8685>
___
___
Py
Mark Dickinson added the comment:
See also issue 8685.
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue8425>
___
___
Python-bugs-list m
Mark Dickinson added the comment:
BTW, it looks as though the nested functions were introduced in r76030;
nothing to do with Matthias's autoconf 2.65 update.
--
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Just double checked that r80969 didn't introduce any other non-whitespace
changes: apart from the now-fixed OS X 10.5 SDK issue), the only other
non-whitespace change was:
@@ -7018,7 +7023,7 @@
int
main ()
{
-long double x; x = (long double)0.;
Mark Dickinson added the comment:
Closing. Roumen, please open a new issue for any other configure issues that
aren't related to this autoconf update.
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
Mark Dickinson added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file17294/audioop_Py_ssize_t.patch
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Fixed one more bogus overflow check in r81079 through r81082.
--
___
Python tracker
<http://bugs.python.org/issue8674>
___
___
Mark Dickinson added the comment:
The audioop module was made PY_SSIZE_T_CLEAN in r81083.
--
components: +Extension Modules
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Mark Dickinson added the comment:
Python's result looks fine to me, as does numpy's: they're both giving a valid
inverse hyperbolic sine:
>>> from cmath import sinh
>>> sinh(1.3169578969248166-1.5707963267948966j)
(1.0605752387249067e-16-1.99
Mark Dickinson added the comment:
A bit more explanation: Python takes account of the sign of zero when deciding
which side of the branch cut a value lies, which is the proper thing to do when
you have signed zeros available (according to the likes of Kahan, anyway); I
suspect that numpy
Mark Dickinson added the comment:
> that may very well be so, but I'd naively standardize on C/Fortran >
> behaviour (but that's probably my physicist bias)
Yep, that's exactly what Python does. :) (Also follows the LISP standard).
Note that in your program, you
Mark Dickinson added the comment:
> Note that in your program, you're feeding complex(-0.0, -2.0) to asinh,
> not complex(0.0, 2.0).
Bah; that should be complex(0.0, -2.0) in the second line, of course.
Anyway, try passing conj(2*I) to asinh in your C program and see w
Mark Dickinson added the comment:
Yes, I'm interested in seeing the pure Python version. It could go into
test_math, and would be a useful form of documentation.
Are there sufficient tests already in test_math.py to exercise the code
thoroughly, or are more needed?
I'll try to fi
Mark Dickinson added the comment:
On Tue, May 11, 2010 at 11:33 PM, Alexander Belopolsky
wrote:
> It seems to me that the value of n for which number of digits will exceed
> sys.maxsize can be estimated fairly accurately using Stirling formula. Only
> two values are relevant in
Mark Dickinson added the comment:
Some quick comments:
(1) Agree about the extra bound checks: let's treat those as a separate issue
and just concentrate on performance here.
(2) log2 isn't portable: it's not part of C89 (though it is in C99) and I
don't think it exist
Mark Dickinson added the comment:
Now that I've looked at the patch properly:
I'm +1 on including some version of this patch. At the time that the original
math.factorial went in (see issue 2138) we were hurrying a bit to get it in
before the first 2.6 beta, so ended up wit
Mark Dickinson added the comment:
> (cf. C99 6.3.1.4,p2).
Oops. C99 6.3.1.4,p1. That'll teach me not to cite chapter and verse.
--
___
Python tracker
<http://bugs.python.or
Mark Dickinson added the comment:
>I was planning to add a "if (dx > (double) LONG_MAX)" check. Would
> that be sufficient?
Hmm. It's subtle. On an LP64 machine, LONG_MAX will be 2**63-1, which isn't
exactly representable as a double. So (double) LONG_MAX wou
Mark Dickinson added the comment:
Interesting---thanks for the analysis!
Realistically though, I don't see an iterative version of
factorial_part_product as an option for the C patch, without a significant
increase in complexity. Daniel's current patch is remarkably clean and si
Mark Dickinson added the comment:
maix: good point. Fixed in revisions r81126 through r81129.
--
___
Python tracker
<http://bugs.python.org/issue2138>
___
___
Mark Dickinson added the comment:
I think difflib is behaving as intended here; changing to feature request.
Could you please clarify about the information loss? I'm not seeing it. As
far as I can tell, the fact that unified_diff produces a list rather than a
single string (as GNU
Mark Dickinson added the comment:
It turns out that this problem was already reported in issue 2142 (which has a
patch); closing as a duplicate.
--
resolution: -> duplicate
status: open -> closed
superseder: -> naive use of ''.join(difflib.unified_diff(...)) resu
Mark Dickinson added the comment:
Closed 8702 as a duplicate of this one. Combining nosy lists.
--
nosy: +mark.dickinson, techtonik
___
Python tracker
<http://bugs.python.org/issue2
Changes by Mark Dickinson :
--
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue2142>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Hmm. Not in my version of diff: it seems to use '\ No newline at end of file'
for both unified and 'normal' diffs.
$ diff --version
diff (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.
...
$ diff 1.txt 2.txt
2c
Mark Dickinson added the comment:
Does anyone feel like doing a speed comparison between Daniel's C patch and a
version with a direct no-frills iterative version of factorial_part_product
(i.e., just a simple 'for (i = n; i <= m; i += 2) { }? I have a sneaking suspicion that
Mark Dickinson added the comment:
And why are we trying to speed up the pure Python factorial code here? I don't
imagine that those speed differences are going to translate well to C.
--
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
> It prefer if it were clear why these tests fail
I agree. There's little point having tests if we're just going to disable them
when they fail without understanding why they're failing first.
At that point a green buildbot just means &qu
Mark Dickinson added the comment:
> I would expect that for large factorials the performance will be
> determined by the number of long multiplications and the size of
> multiplicands.
Okay, but I don't think we should care about the performance of *really* large
factori
Mark Dickinson added the comment:
> Daniel Stutzbach added the comment:
>
> Speaking of getting side-tracked, I didn't see an answer to a question I
> asked earlier. I'd like to get some feedback before I proceed with revising
> the patch.
>
> For the find-las
Mark Dickinson added the comment:
> I am attaching an iterative version in C patch.
Thanks for doing this comparison.
> The performance appears to be identical to Daniel's with no small
> integer multiplication optimization.
Okay, let's stick with the recursive version
Mark Dickinson added the comment:
I think it's arguable whether this is a bug or not. There's no official
specification for the unified diff format that I can find anywhere; the GNU
description at
http://www.gnu.org/software/hello/manual/diff/Detailed-Unified.html#Detailed-Unifie
Mark Dickinson added the comment:
Yes, please do apply the patch!
--
___
Python tracker
<http://bugs.python.org/issue6419>
___
___
Python-bugs-list mailin
Mark Summerfield added the comment:
On 2007-11-30, Christian Heimes wrote:
> Christian Heimes added the comment:
>
> Fixed in r59233. Please adjust the error message if you don't like it.
>
> TypeError: register() cannot be called on an ABCMeta subclass, use class
> Exampl
Mark Dickinson added the comment:
A (probably stupid) question: what's supposed to happen on platforms that
don't define things like DBL_MAX_10_EXP, which isn't part of ANSI C89? Or
are there no such platforms?
--
nosy: +marketdickinson
___
Mark Dickinson added the comment:
And it looks as though DBL_MAX_10_EXP *is* part of ANSI C anyway... I
shouldn't have assumed that just because it's not in Kernighan and Ritchie
(2nd edition) it doesn't exist... Apologies.
__
Tracker &l
Mark Dickinson added the comment:
No, I don't know of any platforms that don't define these constants.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1534>
__
_
Mark Dickinson added the comment:
The site that persuaded me about DBL_MAX_10_EXP was
http://www.schweikhardt.net/identifiers.html
Googling 'C89 draft' also turns up some potentially useful stuff.
__
Tracker <[EMAIL PROTECTED]>
<htt
Mark Dickinson added the comment:
It's not clear to me that this would be the right behaviour. Unless I'm
missing something, Decimal behaves in just the same way as types like
int, float and str in this respect:
>>> class myint(int): pass
...
>>> a = myint(2
Mark Russell added the comment:
Here's an updated version of the patch. Changes:
- Updated to work against current py3k branch (r59441)
- Added support for universal newlines
- Added unit tests
- Added docs
The patch includes documentation for reversed() and __reversed__(
New submission from Mark Russell:
This patch adds documentation for the reversed() builtin and
__reversed__() special method.
--
components: Documentation
files: reverse-2.6-docs.diff
messages: 58369
nosy: mark_t_russell
severity: normal
status: open
title: Documentation patch for
Mark Russell added the comment:
As Guido requested I've split off the generic reversed() and __reversed__()
doc additions to this patch against 2.6: http://bugs.python.org/issue1582
The I/O error from reversed(open("/etc/passwd")) was caused by the inner
TextIOWrapper calling c
New submission from Mark Summerfield:
When I start IDLE I get this:
Python 3.0a2 (r30a2:59382, Dec 10 2007, 14:21:37)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "copyright", "credits" or "licens
Mark Summerfield added the comment:
Amaury Forgeot d'Arc says he's fixed this in change 59456 (but I don't
know how---or if---I can change its status).
__
Tracker <[EMAIL PROTECTED]>
<http://b
New submission from Mark Summerfield:
When I do:
import sys; dir(sys)
everything is shown in plain black & white, but in the IDLE that came
with Py30a1 color syntax highlighting is used.
--
components: IDLE
messages: 58423
nosy: mark
severity: minor
status: open
title: IDL
New submission from Mark Summerfield:
>>> x = complex(1, 2/3)
>>> "{0} {0:.5}".format(x)
'(1+0.6667j) (1+0.'
The complex number is being formatted as if it were a string and simply
truncated to 5 characters. I would expect each part of the complex
n
New submission from Mark Tomczak:
The help documentation for the popen2.Popen3 class includes the
following information:
class Popen3
| Class representing a child process. Normally instances are created
| by the factory functions popen2() and popen3().
This information is
Mark Summerfield added the comment:
On 2007-12-11, Guido van Rossum wrote:
> Guido van Rossum added the comment:
>
> This really is a feature request -- in Python 2.x there is no formatting
> code for complex numbers at all, and "%.5s" % complex(...) does the same
> t
Mark Summerfield added the comment:
On 2007-12-11, Guido van Rossum wrote:
> Guido van Rossum added the comment:
>
> This really is a feature request -- in Python 2.x there is no formatting
> code for complex numbers at all, and "%.5s" % complex(...) does the same
> th
New submission from Mark Summerfield:
(1) IDLE starts up on Windows OK, but if I press Alt+F the file menu
comes up giant sized (i.e., each menu entry is almost as tall as the
screen).
(2) If I open a file using Ctrl+O, the Open dialog pops up fine, but
when I select a file and click Open, IDLE
New submission from Mark Summerfield:
I don't know if this is a bug, but it is certainly a difference in
behavior between platforms:
Python 3.0a2 on linux2:
>>> "{0:.3e}".format(123.45678901)
'1.235e+02'
Python 3.0a2 on win32:
>>> "{0:.3e}&qu
New submission from Mark Summerfield:
I am not sure if this is a Python bug or simply a limitation of cmd.exe.
I am using Windows XP Home.
I run cmd.exe with the /u option and I have set my console font to
"Lucida Console" (the only TrueType font offered), and I run chcp 65001
to se
Mark Summerfield added the comment:
On 2007-12-12, Guido van Rossum wrote:
> Guido van Rossum added the comment:
>
> Again, a (not unreasonable) feature request. AFAIK %e behaves the same
> way. I'm sure if you submitted a patch it would be accepted happily.
Unfortunately, I
New submission from Mark Summerfield:
In the attached file there are two tiny functions, flatten1() and
flatten2(). There is only one difference between them:
flatten1() has the line:
if isinstance(x, list):
and flatten2() has this line instead:
if isinstance(x, collections.Sequence
Mark Summerfield added the comment:
I've looked into this a bit more, and from what I can see, code page
65001 just doesn't work---so it is a Windows problem not a Python problem.
A possible solution might be to read/write UTF16 which "managed" Windows
Mark Dickinson added the comment:
I think you probably don't want to use quantize here: it makes use of
the current context, which means (for example) that
trunc(Decimal(integer_with_30_digits))
will fail with an InvalidOperation exception. I assume what's wanted is
some
Mark Dickinson added the comment:
Sorry: that was nonsense. trunc is fine---it's round, floor and ceil that
fail on large arguments with this patch:
>>> import decimal, math
>>> math.floor(decimal.Decimal("1e30"))
Traceback (most recent call last):
Fi
Mark Summerfield added the comment:
On 2007-12-15, Christian Heimes wrote:
> Christian Heimes added the comment:
>
> Guido is right. On Linux the system's sprintf() family prints %e, %g and
> %f with two or three digits while Windows always uses three digits:
>
>
Mark Summerfield added the comment:
On 2007-12-15, Christian Heimes wrote:
> Christian Heimes added the comment:
>
> Mark Summerfield wrote:
> > It seems to me that Python should provide consistent results across
> > platforms wherever possible and that this is a gra
Mark Summerfield added the comment:
On 2007-12-15, Christian Heimes wrote:
> Christian Heimes added the comment:
>
> Mark Summerfield wrote:
> > It seems to me that Python should provide consistent results across
> > platforms wherever possible and that this is a gra
Mark Summerfield added the comment:
Attached is new version of test_float.py with a few tests to check
str.format() with exponents formats, plus a diff. They test that the
exponent is always 3 digits and that the case of the e in the format is
respected.
Added file: http://bugs.python.org
Mark Summerfield added the comment:
My C is rusty! Attached is new pystrtod.c & diff, this time using
memset() instead of looping to padd with zeros.
Added file: http://bugs.python.org/file8971/pystrtod.c
Added file: http://bugs.python.org/file8972/pystrtod.
Mark Dickinson added the comment:
Cool! Works for me.
I agree that it's not 100% clear that round(large_decimal) should return an
integer rather
than raising an exception. But, rightly or wrongly, this is what
int(large_decimal) does at
the moment, and it would be surprising to hav
Mark Dickinson added the comment:
Cool! If there's a move to add functions to the math module, there are
some others that are part of C99 (but not C89), would be good to have, and
that I'd consider more fundamental than the Bessel, error, gamma
functions; for example, the inverse
Mark Summerfield added the comment:
On 2007-12-17, Christian Heimes wrote:
> Christian Heimes added the comment:
>
> Hi Mark!
>
> In general the patch is fine but it has some small issues.
>
> * Your patches are all reversed. They remove (-) the new lines instead
> of add
Mark Dickinson added the comment:
Unfortunately, implementing asinh, acosh, atanh correctly is not as simple as
just using the formulas
(this is one of the reasons that it's useful to be able to get at the library
definitions). For
example, the formula
asinh(x) = log(x + sqrt(1.
Mark Dickinson added the comment:
Is there anything in the Python documentation that implies that '%.1f' % 2.25
should be the string '2.3'? I know
that the documentation for the builtin round function implies that round(2.25,
1) should be (the closest
representable float
Mark Dickinson added the comment:
It's worth noting that Python's round function doesn't quite work as
advertised, either:
Python 2.6a0 (trunk:59634M, Dec 31 2007, 17:27:56)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright&quo
Mark Dickinson added the comment:
Tracing the calls through ast_for_factor -> ast_for_atom -> parsenumber ->
PyOS_ascii_atof ->
PyOS_ascii_strtod -> strtod, it looks as though the cause is simply that strtod
behaves differently on
the two platforms. I get that the following
Mark Dickinson added the comment:
Presumably float('-1e-1000') should also give -0. (?)
If so, then it looks as though the fix ought to go in PyOS_ascii_strtod:
one obvious possibility would be to replace any leading '-' sign by a '+'
sign before calling the
New submission from Mark Dickinson:
This request relates to issue 1635:
http://bugs.python.org/issue1635
which allows cross-platform creation of infinities and nans.
The IEEE754 standard, the C99 standard, and the standard on which
Decimal is based all allow creation of an infinity from the
Mark Dickinson added the comment:
Here's a possible fix for this issue; it parses a number by first stripping
leading
whitespace and any sign, then passing the remaining string to the system strtod.
This patch also fixes another bug in pystrtod.c, where ValueError is not raised
on a
Mark Dickinson added the comment:
Sorry: brain not working. Please close as invalid.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1729>
__
___
Python-bugs-
Mark Dickinson added the comment:
Why not implement copysign? It's a standard, familiar function with well-
documented meaning all over the web, and it can easily be used to create
whatever sign test is necessary, letting the user decide what results
(s)he wants for +/-0, +/-nan
Mark Dickinson added the comment:
Here's an updated patch for cmath, complete with tests and documentation
changes.
There's an extra file, Lib/test/cmath.ctest, containing test values for the
various functions;
these test values were obtained using MPFR and interval arithmetic, a
Mark Dickinson added the comment:
Some random comments: take with a large pinch of salt
(1) In __init__ I think you want something like:
self._numerator = int(numerator)//g
instead of
self._numerator = int(numerator / g)
and similarly for the denominator. At the moment I get, for
Mark Dickinson added the comment:
Two more questions:
(1) should a Rational instance be hashable?
(2) Should "Rational(5,2) == Decimal('2.5')" evaluate to True or False?
If Rationals are hashable and 2.5 == Rational(5, 2) == Decimal('2.5') then the
rule t
Mark Dickinson added the comment:
You need to remove the old files in decimaltestdata before copying the
new ones across: nrmx218 is an old, and buggy, testcase; at some point
Mike Cowlishaw renamed normalize.decTest to reduce.decTest. He also
renamed the operation from normalize to reduce
Mark Dickinson added the comment:
P.S. I've just noticed that both versions of __hash__ are buggy: the
hash value of a Decimal depends on the current context. I'll open a new
bug report.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
New submission from Mark Dickinson:
The value of the Decimal hash() depends on the current context:
>>> from decimal import *
>>> x = Decimal("123456789.1")
>>> hash(x)
1989332493
>>> getcontext().prec = 6
>>> hash(x)
-2034270682
This has
Mark Dickinson added the comment:
One minor point: Decimals are also created by the _dec_from_triple
function: presumably that call to __new__ should also be changed to use
super?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Mark Dickinson added the comment:
Here's a patch for the trunk.
Added file: http://bugs.python.org/file9101/issue1757.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Mark Dickinson added the comment:
Some more comments:
(1) I don't think I understand the mechanism by which __lt__ and __le__ are
supposed to
be called. For example, by adding a few print statements it seems that the
comparison
Decimal(2) > 3
doesn't call __lt__ at any st
Mark Dickinson added the comment:
It seems likely that Decimal is going to grow rich comparisons anyway,
either as a result of PEP 3141 or as a result of removal of __cmp__.
Given this, would there be any objections to making comparisons do the
right thing (in the sense of IEEE-754) for NaNs
Mark Dickinson added the comment:
Unfortunately, I think this backport still breaks hash:
bernoulli:~/python_source/release25-maint dickinsm$ ./python.exe
Python 2.5.2a0 (release25-maint:59859M, Jan 8 2008, 11:54:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "
Mark Dickinson added the comment:
A note to any potential reviewers for this patch (cmath3.patch): I'm
especially
looking for non-mathematical feedback here, so please don't be put off by the
mathematics. Some questions:
- there's a new file cmath.ctest containing testcase
Mark Dickinson added the comment:
hash fixed in revision 59863.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1182>
__
___
Python-bugs-list mailing list
Unsubs
Mark Dickinson added the comment:
Okay: would it be okay for me to move the #ifdef MS_WINDOWS sequence
somewhere where it can be used by both mathmodule.c and cmathmodule.c,
then?
There are replacements for log1p and asinh in the patch, so it shouldn't
matter than they're missing
Mark Dickinson added the comment:
I don't think anything's missing from Cowlishaw's test-suite. An old,
buggy test (nrmx218) was both renamed (to redx218) and fixed by Cowlishaw.
I think Facundo ended up with both tests---so naturally the old, brok
New submission from Mark Dickinson:
After seeing issue #1761, I realized that there's a bug in the Decimal
constructor: it accepts newline-terminated strings:
>>> from decimal import *
>>> s = "2.3\n"
>>> Decimal(s)
Decimal("2.3")
I think
Mark Dickinson added the comment:
Okay: in that case, I propose:
(1) adding a to_number method to the Decimal and Context class, so that
we're still in full compliance with the specification, and
(2) altering Decimal.__new__ to allow trailing and leading white
Mark Dickinson added the comment:
Aargh! It's only the Context class that needs a to_number method---it
makes no sense as a Decimal method. And to_number is almost already
there, in the form of Context.create_decimal.
I'll work out exactly what the minimum is that needs to
Mark Dickinson added the comment:
In the spirit of making the Decimal constructor match the rest of the language,
can I propose another change: make Decimal("not a decimal") raise a
ValueError.
Currently, Decimal("not a decimal") either raises InvalidOperation or re
Mark Dickinson added the comment:
Allowing automatic coercion to and from Decimal sounds dangerous and
complicated to me. Mightn't it be safer just to disallow this (at least for
now)?
I think something like trim() (find the closest rational approximation with
denominator bounded
Mark Dickinson added the comment:
Allowing leading and trailing whitespace causes failures in Cowlishaw's
test suite. I guess Raymond's right: this bug report should be
dismissed. It still bothers me a little that there isn't a strictly
conforming implementation of to-nu
Mark Dickinson added the comment:
I can certainly fix the Decimal constructor to reject trailing newlines, if
that's what people want, but that doesn't fit with the proposal to accept
and strip leading and trailing whitespace.
The other option that maintains full complianc
Mark Dickinson added the comment:
Here's a patch that alters the Decimal constructor to allow leading and
trailing whitespace.
The Context.create_decimal method should now be a fully conforming
implementation of to-number: it doesn't accept any leading or trailing
Mark Dickinson added the comment:
More comments, questions, and suggestions on the latest patch:
1. In _binary_float_to_ratio, the indentation needs adjusting. Also 'top = 0L'
could be replaced with 'top =
0', unless you need this code to work with Python 2.3 and earlier
2101 - 2200 of 12223 matches
Mail list logo
