[ python-Bugs-1118729 ] Error in representation of complex numbers(again)
Bugs item #1118729, was opened at 2005-02-08 17:26
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Martin v. Löwis (loewis)
Summary: Error in representation of complex numbers(again)
Initial Comment:
>>> -(1+0j)
(-1+-0j)
I encountered this while I was calculating conjugate of
complex numbers(e.g. z.conjugate()).
Related bug
* http://www.python.org/sf/1013908
One thing to note is that -(0j) can return 0j or -0j
dependeing on OSes.
Confirmed on SuSE 9.1 & cygwin.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-05-15 09:57
Message:
Logged In: YES
user_id=21627
What do you think about the patch attached?
--
Comment By: George Yoshida (quiver)
Date: 2005-03-19 18:11
Message:
Logged In: YES
user_id=671362
Martin, what's your take on this?
The representation of '-(1+0j)' has changed since Revision 2.71
(complexobject.c) and you applied the patch.
# original patch
making Python LC_NUMERIC agnostic
http://www.python.org/sf/774665
--
Comment By: George Yoshida (quiver)
Date: 2005-02-10 01:02
Message:
Logged In: YES
user_id=671362
Hi, Björn.
Sorry, not to be clear about what my complaint is. I'm not
talking about if -(0j) should be 0j or -0j. It's been that way
for a long time, so changing it would break old codes.
My point is the signature of imaginary part. As you can see,
it's represented as '+-'. Before the commit of patch #774665,
it was represented as '-1-0j'. But after that, '-1+-0j'.
If you test it with Python <= 2.3, you'll get (-1-0j) and I think
this is how -(1+0j) should be represented on machines where -
(0j) is represented as -0j.
--
Comment By: Björn Lindqvist (sonderblade)
Date: 2005-02-09 19:54
Message:
Logged In: YES
user_id=51702
What you are seeing is negative zero (-0.0). It is distinct
from positive zero (0.0) but 0.0 == -0.0 is always true. On
some machines you can also see it by typing:
>>> -0.0
-0.0
On other machines you will see "0.0" instead. You can also try
printf("%f\n", -0.0); and you will notice the same thing. So
I'm not sure it is a bug per se. However, it can be worked
around by adding "if (v->cval.imag == 0.) v->cval.imag =
0.0;" to complexobject.c, assuming ofcourse it is OK to
change negative zeros to positive ones.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1118729 ] Error in representation of complex numbers(again)
Bugs item #1118729, was opened at 2005-02-09 01:26
Message generated for change (Comment added) made by quiver
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Martin v. Löwis (loewis)
Summary: Error in representation of complex numbers(again)
Initial Comment:
>>> -(1+0j)
(-1+-0j)
I encountered this while I was calculating conjugate of
complex numbers(e.g. z.conjugate()).
Related bug
* http://www.python.org/sf/1013908
One thing to note is that -(0j) can return 0j or -0j
dependeing on OSes.
Confirmed on SuSE 9.1 & cygwin.
--
>Comment By: George Yoshida (quiver)
Date: 2005-05-15 21:22
Message:
Logged In: YES
user_id=671362
The fix seems reasonable to me and it passed the test
suites.
Please apply it.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-15 16:57
Message:
Logged In: YES
user_id=21627
What do you think about the patch attached?
--
Comment By: George Yoshida (quiver)
Date: 2005-03-20 02:11
Message:
Logged In: YES
user_id=671362
Martin, what's your take on this?
The representation of '-(1+0j)' has changed since Revision 2.71
(complexobject.c) and you applied the patch.
# original patch
making Python LC_NUMERIC agnostic
http://www.python.org/sf/774665
--
Comment By: George Yoshida (quiver)
Date: 2005-02-10 09:02
Message:
Logged In: YES
user_id=671362
Hi, Björn.
Sorry, not to be clear about what my complaint is. I'm not
talking about if -(0j) should be 0j or -0j. It's been that way
for a long time, so changing it would break old codes.
My point is the signature of imaginary part. As you can see,
it's represented as '+-'. Before the commit of patch #774665,
it was represented as '-1-0j'. But after that, '-1+-0j'.
If you test it with Python <= 2.3, you'll get (-1-0j) and I think
this is how -(1+0j) should be represented on machines where -
(0j) is represented as -0j.
--
Comment By: Björn Lindqvist (sonderblade)
Date: 2005-02-10 03:54
Message:
Logged In: YES
user_id=51702
What you are seeing is negative zero (-0.0). It is distinct
from positive zero (0.0) but 0.0 == -0.0 is always true. On
some machines you can also see it by typing:
>>> -0.0
-0.0
On other machines you will see "0.0" instead. You can also try
printf("%f\n", -0.0); and you will notice the same thing. So
I'm not sure it is a bug per se. However, it can be worked
around by adding "if (v->cval.imag == 0.) v->cval.imag =
0.0;" to complexobject.c, assuming ofcourse it is OK to
change negative zeros to positive ones.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202395 ] Description of string.lstrip() needs improvement
Bugs item #1202395, was opened at 2005-05-15 13:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Description of string.lstrip() needs improvement Initial Comment: In http://docs.python.org/lib/string-methods.html, under lstrip(), it says, "chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on". It would be clearer if it said: "chars must be a string; the characters in the string constitute a set of characters to be stripped from the beginning of the string this method is called on". Similarly for rstrip() and strip(). There was a recent posting to comp.lang.python where it appears that the poster thought the argument to lstrip() was a leading string to be removed, not a set of characters. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202395 ] Description of string.lstrip() needs improvement
Bugs item #1202395, was opened at 2005-05-15 13:50 Message generated for change (Comment added) made by roysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Description of string.lstrip() needs improvement Initial Comment: In http://docs.python.org/lib/string-methods.html, under lstrip(), it says, "chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on". It would be clearer if it said: "chars must be a string; the characters in the string constitute a set of characters to be stripped from the beginning of the string this method is called on". Similarly for rstrip() and strip(). There was a recent posting to comp.lang.python where it appears that the poster thought the argument to lstrip() was a leading string to be removed, not a set of characters. -- >Comment By: Roy Smith (roysmith) Date: 2005-05-15 13:55 Message: Logged In: YES user_id=390499 I notice bug #1196824 (recently submitted and closed as "not a bug") relates to the same issue. It seems more than one person has gotten confused by this :-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202475 ] httplib docs mentioning HTTPConnection.getreply
Bugs item #1202475, was opened at 2005-05-15 20:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: httplib docs mentioning HTTPConnection.getreply Initial Comment: ... instead of getresponse in the description of send(). Also, a general note or explanation like that could be given before the description of send(): """ You can send requests in two ways: either using the request() method as described above, which combines all request parameters, or using a sequence of putrequest(), zero or more times addheader(), endheaders() and then send(). """ It is sort of confusing in its current state. Oh yes, and while you're at it ;), you could add a note that the response object must be read completely before a new request can be sent. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202493 ] RE parser too loose with {m,n} construct
Bugs item #1202493, was opened at 2005-05-15 16:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470
Category: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct
Initial Comment:
This seems wrong to me:
>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)
With no numbers or commas, "{}" should not be considered
special in the pattern. The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}. There's no
description of {} meaning anything. Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
