[ python-Bugs-1741130 ] struct.pack("I", "foo"); struct.pack("L", "foo") should fail
Bugs item #1741130, was opened at 2007-06-21 20:36
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=1741130&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.pack("I", "foo"); struct.pack("L", "foo") should fail
Initial Comment:
The following code prints out "I L" when run with python 2.5 and current SVN
trunk (if you silence the DeprecationWarnings):
"""
import struct
for c in "bBhHiIlLqQdf":
try:
struct.pack(c, "foo bar")
except struct.error:
pass
else:
print c
"""
It works correctly (prints nothing) in Python 2.4.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741130&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1740599 ] python: Modules/gcmodule.c:240: update_refs: Assertion `gc->
Bugs item #1740599, was opened at 2007-06-20 16:24 Message generated for change (Comment added) made by stuffduff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sean (stuffduff) Assigned to: Nobody/Anonymous (nobody) Summary: python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Initial Comment: Extension module loads and runs correctly. When exiting python the following error occurrs: GNU gdb Red Hat Linux (6.5-15.fc6rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: python2.4 ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208243504 (LWP 12884)] collect (generation=2) at Modules/gcmodule.c:241 241 Modules/gcmodule.c: No such file or directory. in Modules/gcmodule.c (gdb) bt #0 collect (generation=2) at Modules/gcmodule.c:241 #1 0x080e1ec5 in PyGC_Collect () at Modules/gcmodule.c:1196 #2 0x080da88a in Py_Finalize () at Python/pythonrun.c:353 #3 0x08055176 in Py_Main (argc=0, argv=0xbfb8dae4) at Modules/main.c: 513 #4 0x08054962 in main (argc=-1208273400, argv=0x812ed68) at Modules/python.c:23 Debug build of python2.4.4 gives: python: Modules/gcmodule.c:240: update_refs: Assertion `gc->gc.gc_refs == (-3)' failed. -- >Comment By: Sean (stuffduff) Date: 2007-06-21 15:55 Message: Logged In: YES user_id=1093262 Originator: YES Very stripped down, but complex instructions. See the README file. PUTENV replaces the need for an environment variable. File Added: pyGTMbug.tar.gz -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-21 00:41 Message: Logged In: YES user_id=33168 Originator: NO I forgot to mention about the putenv()s. Are those necessary? The directories won't exist on any one else's box. If those are not necessary to cause the assertion, remove those too from the minimal test case. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-21 00:40 Message: Logged In: YES user_id=33168 Originator: NO I looked at the attachment and it's not clear how you are using this given there is a main(). The main() doesn't have a Py_Initialize() either. So I'm guessing that was left over and you are really using this as a module. Can you reduce it to the minimal test case? Remove the main() and all the methods that are not used and will cause the crash. Also what is the python code that you execute. Basically can you demonstrate a complete scenario (how to build and execute) to cause the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1741218 ] string formatter %x problem with indirectly given long
Bugs item #1741218, was opened at 2007-06-21 16:33
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=1741218&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kenji Noguchi (kenjinoguchi)
Assigned to: Nobody/Anonymous (nobody)
Summary: string formatter %x problem with indirectly given long
Initial Comment:
"%x" % v fails if the v is a instance, and its __int__ returns larger than
0x8000 on 32bit OS.
I've reported the problem at Python ML.
http://mail.python.org/pipermail/python-list/2007-June/446103.html
"%x" % int(v)
"%x" % 0x8000L
above two work fine because string formatter processes a long value
exceptionally. It looks inconsistent. So I made this patch.
--- stringobject.c.org 2007-06-21 13:57:54.745877000 -0700
+++ stringobject.c 2007-06-21 13:59:19.576646000 -0700
@@ -4684,6 +4684,15 @@
case 'X':
if (c == 'i')
c = 'd';
+ /* try to convert objects to number*/
+ PyNumberMethods *nb;
+ if ((nb = v->ob_type->tp_as_number) &&
+ nb->nb_int) {
+ v = (*nb->nb_int) (v);
+ if(v == NULL)
+ goto error;
+ }
+
if (PyLong_Check(v)) {
int ilen;
temp = _PyString_FormatLong(v, flags,
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741218&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1725899 ] decimal sqrt method doesn't use round-half-even
Bugs item #1725899, was opened at 2007-05-25 22:52
Message generated for change (Comment added) made by marketdickinson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: decimal sqrt method doesn't use round-half-even
Initial Comment:
According to version 1.66 of Cowlishaw's `General Decimal Arithmetic
Specification' the square-root operation in the decimal module should
round using the round-half-even algorithm (regardless of the rounding
setting in the current context). It doesn't appear to do so:
>>> from decimal import *
>>> getcontext().prec = 6
>>> Decimal(9123455**2).sqrt()
Decimal("9.12345E+6")
The exact value of this square root is exactly halfway between two
representable Decimals, so using round-half-even with 6 digits I'd
expect the answer to be rounded to the neighboring representable
Decimal with *even* last digit---that is,
Decimal("9.12346E+6")
This bug only seems to occur when the number of significant digits in
the argument exceeds the current precision (indeed, if the number of
sig. digits in the argument is less than or equal to the current
precision then it's impossible for the square root to be halfway
between two representable floats).
It seems to me that this is a minor bug that will occur rarely and is
unlikely to have any serious effect even when it does occur; however,
it does seem to be a deviation from the specification.
--
>Comment By: Mark Dickinson (marketdickinson)
Date: 2007-06-22 06:16
Message:
Logged In: YES
user_id=703403
Originator: YES
Some more strange results for sqrt(): with Emax = 9, Emin = -9 and prec =
3:
1. In the following, should the Subnormal and Underflow flags be set? The
result before rounding is subnormal, even though the post-rounding result
is not, and the spec seems to say that those flags should be set in this
situation. But Cowlishaw's reference implementation (version 3.50) doesn't
set these flags. (If 9.998 is replaced by 9.99 then the flags *are* set,
which seems inconsistent.)
>>> Decimal("9.998E-19").sqrt()
Decimal("1.00E-9")
>>> getcontext()
Context(prec=3, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, capitals=1,
flags=[Rounded, Inexact], traps=[DivisionByZero, Overflow,
InvalidOperation])
2. As I understand the spec, the following result is incorrect:
>>> Decimal("1.12E-19").sqrt()
Decimal("3.4E-10")
(The true value of the square root is 3.34664...e-10, which should surely
be rounded to 3.3E-10, not 3.4E-10?).
But again, Cowlishaw's reference implementation also gives 3.4E-10.
3. Similarly for the following
>>> Decimal("4.21E-20").sqrt()
Decimal("2.0E-10")
The answer should, I think, be 2.1E-10; here the reference implementation
also gives 2.1E-10.
4. And I can't justify this one at all...
>>> Decimal("1.01001").sqrt()
Decimal("1.01")
Shouldn't this be 1.00? But again Python agrees with the reference
implementation.
Either all this is pretty mixed up, or I'm fundamentally misunderstanding
things. I have a patch that I think fixes all these bugs; if there's any
agreement that they really are bugs then I'll post it. Can anyone shed any
light on the above results?
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-05-25 23:30
Message:
Logged In: YES
user_id=703403
Originator: YES
I don't think inputs should be rounded; note 1 near the start of the
`Arithmetic Operations' section of the specification says:
"Operands may have more than precision digits and are not rounded before
use."
--
Comment By: Tim Peters (tim_one)
Date: 2007-05-25 23:24
Message:
Logged In: YES
user_id=31435
Originator: NO
Doesn't the spec also require that /inputs/ get rounded to working
precision /before/ operations are performed? If so, the exact square
83237431137025 is rounded down to 832374, and sqrt(832374)
is 9.12345E+6 rounded to 6 digits.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1725899 ] decimal sqrt method doesn't use round-half-even
Bugs item #1725899, was opened at 2007-05-25 22:52
Message generated for change (Comment added) made by marketdickinson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: decimal sqrt method doesn't use round-half-even
Initial Comment:
According to version 1.66 of Cowlishaw's `General Decimal Arithmetic
Specification' the square-root operation in the decimal module should
round using the round-half-even algorithm (regardless of the rounding
setting in the current context). It doesn't appear to do so:
>>> from decimal import *
>>> getcontext().prec = 6
>>> Decimal(9123455**2).sqrt()
Decimal("9.12345E+6")
The exact value of this square root is exactly halfway between two
representable Decimals, so using round-half-even with 6 digits I'd
expect the answer to be rounded to the neighboring representable
Decimal with *even* last digit---that is,
Decimal("9.12346E+6")
This bug only seems to occur when the number of significant digits in
the argument exceeds the current precision (indeed, if the number of
sig. digits in the argument is less than or equal to the current
precision then it's impossible for the square root to be halfway
between two representable floats).
It seems to me that this is a minor bug that will occur rarely and is
unlikely to have any serious effect even when it does occur; however,
it does seem to be a deviation from the specification.
--
>Comment By: Mark Dickinson (marketdickinson)
Date: 2007-06-22 06:35
Message:
Logged In: YES
user_id=703403
Originator: YES
One more result. This is definitely getting suspicious now--I'll submit my
patch.
>>> from decimal import *
>>> getcontext().prec = 3
>>> Decimal(11772).sqrt()
Decimal("109")
>>> Decimal(11774).sqrt()
Decimal("108")
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-06-22 06:16
Message:
Logged In: YES
user_id=703403
Originator: YES
Some more strange results for sqrt(): with Emax = 9, Emin = -9 and prec =
3:
1. In the following, should the Subnormal and Underflow flags be set? The
result before rounding is subnormal, even though the post-rounding result
is not, and the spec seems to say that those flags should be set in this
situation. But Cowlishaw's reference implementation (version 3.50) doesn't
set these flags. (If 9.998 is replaced by 9.99 then the flags *are* set,
which seems inconsistent.)
>>> Decimal("9.998E-19").sqrt()
Decimal("1.00E-9")
>>> getcontext()
Context(prec=3, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, capitals=1,
flags=[Rounded, Inexact], traps=[DivisionByZero, Overflow,
InvalidOperation])
2. As I understand the spec, the following result is incorrect:
>>> Decimal("1.12E-19").sqrt()
Decimal("3.4E-10")
(The true value of the square root is 3.34664...e-10, which should surely
be rounded to 3.3E-10, not 3.4E-10?).
But again, Cowlishaw's reference implementation also gives 3.4E-10.
3. Similarly for the following
>>> Decimal("4.21E-20").sqrt()
Decimal("2.0E-10")
The answer should, I think, be 2.1E-10; here the reference implementation
also gives 2.1E-10.
4. And I can't justify this one at all...
>>> Decimal("1.01001").sqrt()
Decimal("1.01")
Shouldn't this be 1.00? But again Python agrees with the reference
implementation.
Either all this is pretty mixed up, or I'm fundamentally misunderstanding
things. I have a patch that I think fixes all these bugs; if there's any
agreement that they really are bugs then I'll post it. Can anyone shed any
light on the above results?
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-05-25 23:30
Message:
Logged In: YES
user_id=703403
Originator: YES
I don't think inputs should be rounded; note 1 near the start of the
`Arithmetic Operations' section of the specification says:
"Operands may have more than precision digits and are not rounded before
use."
--
Comment By: Tim Peters (tim_one)
Date: 2007-05-25 23:24
Message:
Logged In: YES
user_id=31435
Originator: NO
Doesn't the spec also require that /inputs/ get rounded to working
precision /before/ operations are performed? If so, the exact square
83237431137025 is rounded down to 832374, and sqrt(832374)
is 9.12345E+6 rounded to 6 digits.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=
