[issue46187] Optionally support rounding for math.isqrt()
Case Van Horsen added the comment: FWIW, gmpy2 uses isqrt_rem. Of course, gmpy2 uses underscores a lot. And uses next_toward instead of nextafter, and copy_sign instead of copysign, and is_nan instead of isnan... :( I would keep the math module consistent and use isqrtrem. I'll look at adding aliases to remain consistent with the math module. -- nosy: +casevh ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40604] Regression in 3.8.3rc1 - error in tests run via doctest
New submission from Case Van Horsen : An error in the gmpy2 test suite was reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960201 The test suite is run using doctest and has been running without issues for many years. The first failure occurs when running the following fragment: >>> x = xmpz(16) >>> iter = x.iter_bits() >>> [b for b in iter] [False, False, False, False, True] The output is as expected when run interactively on 3.8.3rc1 but generated the following error message: /home/case/local/lib/python3.8/doctest.py:1336: RuntimeWarning: coroutine '' was never awaited exec(compile(example.source, filename, "single", RuntimeWarning: Enable tracemalloc to get the object allocation traceback ** File "test_gmpy2_xmpz_misc.txt", line 91, in test_gmpy2_xmpz_misc.txt Failed example: [b for b in iter] Differences (ndiff with -expected +actual): - [False, False, False, False, True] ** Note the runtime warning for doctest.py. -- components: Library (Lib) messages: 368703 nosy: casevh priority: normal severity: normal status: open title: Regression in 3.8.3rc1 - error in tests run via doctest versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40604> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29882] Add an efficient popcount method for integers
Case Van Horsen added the comment: I like the name bit_count and I'll gladly add it to gmpy2 with the appropriate changes to exceptions, etc. -- nosy: +casevh ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29160] pow with three int arguments works like it had two arguments
Case Van Horsen added the comment: This is a bug/limitation in numpy. If x and y are Python integers, and type(z) is of another numeric type, pow calls the nb_power slot of the underlying type. Here a quick example using numpy.int32 and gmpy2.mpz: >>> import numpy, gmpy2 >>> pow(11,13,7) 4 >>> pow(11,13,numpy.int32(7)) 34522712143931 >>> pow(11,13,gmpy2.mpz(7)) mpz(4) >>> (11).__pow__(13,7) 4 >>> numpy.int32(11).__pow__(13,7) 34522712143931 >>> gmpy2.mpz(11).__pow__(13,7) mpz(4) casevh -- nosy: +casevh ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21955] ceval.c: implement fast path for integers with a single digit
Case Van Horsen added the comment: I ran the mpmath test suite with the fastint6 and fastint5_4 patches. fastint6 results without gmpy: 0.25% faster with gmpy: 3% slower fastint5_4 results without gmpy: 1.5% slower with gmpy: 5.5% slower -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21955] ceval.c: implement fast path for integers with a single digit
Case Van Horsen added the comment: mpmath is a library for arbitrary-precision floating-point arithmetic. It uses Python's native long type or gmpy2's mpz type for computations. It is available at https://pypi.python.org/pypi/mpmath. The test suite can be run directly from the source tree. The test suite includes timing information for individual tests and for the the entire test. Sample invocation: ~/src/mpmath-0.19/mpmath/tests$ time py36 runtests.py -local For example, I've tried to optimize gmpy2's handling of binary operations between its mpz type and short Python integers. I've found it to provide useful results: improvements that are significant on a micro-benchmark (say 20%) will usually cause a small but repeatable improvement. And some improvements that looked good on a micro-benchmark would slow down mpmath. I ran the mpmath test suite with Python 3.6 and with the fastint6 patch. The overall increase when using Python long type was about 1%. When using gmpy2's mpz type, there was a slowdown of about 2%. I will run more tests tonight. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21955] ceval.c: implement fast path for integers with a single digit
Case Van Horsen added the comment: Can I suggest the mpmath test suite as a good benchmark? I've used it to test the various optimizations in gmpy2 and it has always been a valuable real-world benchmark. And it is slower in Python 3 than Python 2 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Changes by Case Van Horsen cas...@gmail.com: -- nosy: +casevh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22198] Odd floor-division corner case
Changes by Case Van Horsen cas...@gmail.com: -- nosy: +casevh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22198 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Case Van Horsen added the comment: Does Scheme's default integer type support arbitrarily large values? Yes, at least is does on the version I tested. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Case Van Horsen added the comment:
What are the use-cases for float // float where integer result is not
acceptable?
It can lead to unexpected memory consumption when dealing with
arbitrary precision values. What should Decimal('1e123456')//1 return?
The result is exactly equal to Decimal('1e123456') but the
corresponding Python integer will consume ~55KB of RAM.
I'm also concerned that returning a very large integer will lead users
to assume that the result is more precise than it really is. Assuming
standard 64-bit double format, only the first 53 bits are significant.
All the remaining bits are 0.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Case Van Horsen added the comment:
On Sat, Sep 20, 2014 at 9:38 AM, Alexander Belopolsky
rep...@bugs.python.org wrote:
Alexander Belopolsky added the comment:
Perhaps it's worth mentioning that several people on Python-ideas
took the opposite view: math.floor() should return a float.
I sympathize with the idea that math module functions should return floats.
I find it unfortunate that math.floor delegates to the __floor__ dunder on
non-floats instead of doing math.floor(x.__float__()). It would be more
natural to have a floor builtin that *always* delegates to __floor__ and keep
math a pure float library.
+1
Note that math module provides the means to compute C-style floor:
x = float('inf')
math.modf(x)[1]
inf
x = -3.4
math.modf(x)[1]
-3.0
That's not immediately obvious...
Maybe we should add floorf, ceilf, etc. as well. This, however, is a
different issue from the one at hand here.
i think the issues are related. PEP-3141 defines x//y as
int(floor(x/y)). It also defines divmod(x, y) as (x//y, x % y). These
definitions cannot all be satisfied at the same Python's divmod
function takes extra effort to calculate x//y precisely. Those
corrections are not possible via floor().
I maintain gmpy2 which wraps the GMP, MPFR, and MPC arbitrary
precision libraries. I originally implemented x//y as floor(x/y). That
choice lead to errors in divmod() that I've fixed in the development
version. I still need to fix floor division: do I make it compatible
with divmod() or floor()?
My preference would be to define floor division and divmod in terms of
each other and allow math.ceil()/floor()/trunc() to return floating
point values. The current definitions are impossible to satisfy.
I mentioned my concerns about memory growth in another comment. I'm
not as concerned about the unexpected memory growth in floor division
as I am in floor() etc.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Case Van Horsen added the comment:
What should Decimal('1e123456')//1 return?
I think Decimal case should be considered separately. Note that unlike
float, they are not part of the numerical tower, so PEP 3141 arguments don't
apply:
isinstance(1.0, numbers.Real)
True
isinstance(decimal.Decimal(1), numbers.Real)
False
I maintain gmpy2 and I've had requests to support the numeric tower.
gmpy2 has integral, rational, real, and complex types so I should be
able to.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22444
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22444] Floor divide should return int
Changes by Case Van Horsen cas...@gmail.com: -- nosy: +casevh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22444 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21955] ceval.c: implement fast path for integers with a single digit
Changes by Case Van Horsen cas...@gmail.com: -- nosy: +casevh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21922] PyLong: use GMP
Case Van Horsen added the comment: I've successfully tested the patch. The patch works fine but there are a couple of issues: 1) The patch relies on several new low-level functions that were introduced in the latest release of GMP 6.0.0. Most Linux distributions are still providing older versions. 2) The new functions are not available in any version of MPIR so I can't try a Windows build. I've done some basic tests but I'll wait until Hristo updates the patch with his improvements before I run detailed tests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21922 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21922] PyLong: use GMP
Changes by Case Van Horsen cas...@gmail.com: -- nosy: +casevh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21922 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21922] PyLong: use GMP
Case Van Horsen added the comment: Disclaimer: as Mark alluded to, I maintain gmpy2. Some comments on MPIR/GMP: For all practical purposes, building GMP on Windows requires some version of the mingw compiler toolchain. None of the performance gains of custom assembly code is available if GMP is build with the VS compiler. When compiled with mingw, GMP supports CPU detection to automatically use code optimized for the specific instruction set. This level of optimization may not be needed for Python, though. The MPIR fork of GMP can be built with VS. Assembly code is supported via the YASM assembler plugin. Only a single instruction set is supported by the lib/dll. gmpy2 currently uses MPIR. I've had no issues with its stability. The mpz type has a maximum precision. IIRC, the maximum length is 2^31 bits on a 32-bit platform and 2^37 on a 64-bit platform. The mpn interface may or may not have the same restrictions. This might impact code that runs correctly, but slowly, with Python's normal PyLong implementation. GMP does not handle out-of-memory situations gracefully. When GMP encounters a memory allocation failure (exceeding the limits above or when running our of scratch space), it will just abort. It is easy in gmpy2 to trigger an abort that will crash the Python interpreter. My main concern is tightly linking the Python interpreter to a specific version of GMP (i.e. whatever version is used for the Windows builds or the version provided by the distribution). As long as gmpy2 can continue to use another version of GMP, it shouldn't matter to me. GMP and MPIR are both licensed under LGPL v3+ (not v2+). I'll reserve any further licensing discussions for python-dev. I'll try to test the patch this weekend and that should answer some of my questions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21922 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16483] Make int(float('inf')) raise ValueError rather than OverflowError.
Case Van Horsen added the comment: I agree that ValueError is a more correct exception but I also don't think OverflowError is all that wrong. I don't think the change is worth the risk of breaking existing code. I'd be fine with either option. -- nosy: +casevh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16469] Exceptions raised by Fraction() different from those raised by int()
Case Van Horsen added the comment: Do we also want to change int(infinity) to return ValueError? I think consistent behavior between int() and Fraction() is valuable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16469 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16469] Exceptions raised by Fraction() from those raised by int()
New submission from Case Van Horsen: When attempting to convert a float(nan), float(inf), or float(-inf), fractions.Fraction() raises different exceptions than int() int(float(nan)) Traceback (most recent call last): File stdin, line 1, in module ValueError: cannot convert float NaN to integer fractions.Fraction(float(nan)) Traceback (most recent call last): File stdin, line 1, in module File /opt/local/lib/python3.2/fractions.py, line 114, in __new__ value = Fraction.from_float(numerator) File /opt/local/lib/python3.2/fractions.py, line 186, in from_float raise TypeError(Cannot convert %r to %s. % (f, cls.__name__)) TypeError: Cannot convert nan to Fraction. int(float(inf)) Traceback (most recent call last): File stdin, line 1, in module OverflowError: cannot convert float infinity to integer fractions.Fraction(float(inf)) Traceback (most recent call last): File stdin, line 1, in module File /opt/local/lib/python3.2/fractions.py, line 114, in __new__ value = Fraction.from_float(numerator) File /opt/local/lib/python3.2/fractions.py, line 186, in from_float raise TypeError(Cannot convert %r to %s. % (f, cls.__name__)) TypeError: Cannot convert inf to Fraction. int(float(-inf)) Traceback (most recent call last): File stdin, line 1, in module OverflowError: cannot convert float infinity to integer fractions.Fraction(float(-inf)) Traceback (most recent call last): File stdin, line 1, in module File /opt/local/lib/python3.2/fractions.py, line 114, in __new__ value = Fraction.from_float(numerator) File /opt/local/lib/python3.2/fractions.py, line 186, in from_float raise TypeError(Cannot convert %r to %s. % (f, cls.__name__)) TypeError: Cannot convert -inf to Fraction. Should the exceptions be changed to ValueError and OverflowError? -- components: Library (Lib) messages: 175536 nosy: casevh priority: normal severity: normal status: open title: Exceptions raised by Fraction() from those raised by int() versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16469 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Case Van Horsen cas...@gmail.com added the comment: I've found some differences between decimal and cdecimal. cdecimal 2.3 does not support the __ceil__ and __floor__ methods that exist in decimal. math.ceil converts a cdecimal.Decimal instance into a float before finding the ceiling. This can generate incorrect results. import decimal import math math.ceil(decimal.Decimal(12345678901234567890.1)) 12345678901234567168 The decimal module in previous versions returns the correct answer 12345678901234567891 cdecimal.Decimal instances do not emulate the various single-underscore methods of a decimal.Decimal instance. In gmpy2, I use _int, _exp, _sign, and _is_special to convert a decimal.Decimal into an exact fraction. I realize the issue is with gmpy2 and I will fix gmpy2, but there may be other code that uses those methods. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11395] print(s) fails on Windows with long strings
New submission from Case Van Horsen cas...@gmail.com: Python 3.2 fails when printing long strings. C:\Python32python Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. print(a*66000) Traceback (most recent call last): File stdin, line 1, in module IOError: [Errno 12] Not enough space Some observations: 1) 3.2 on Linux prints just fine. 2) 2.7.1 and 3.1.3 on Windows x64 are fine 3) The 32-bit interpreter for 3.2 also fails. 4) On 32-bit Windows, a length of 62733 works correctly but 62734, and higher, fail. 5) On 64-bit Windows, the output is visibly corrupted when the length reaches 62801 but the error does not occur until the length reaches 65536. 6) While experimenting with various lengths, I was able to crash the interpreter once. -- messages: 130029 nosy: casevh priority: normal severity: normal status: open title: print(s) fails on Windows with long strings type: crash versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11395 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11247] Error sending packets to multicast IPV4 address
Case Van Horsen cas...@gmail.com added the comment: I tested multicast without any issues using the attached script. I used RC3 on both Windows 7 and Linux. I did need to disable the firewall on my Windows system before multicast would work. Start one or more clients using: python mtest1.py client Send data using: python mtest1.py server hello 10 -- nosy: +casevh Added file: http://bugs.python.org/file20791/mtest1.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Case Van Horsen cas...@gmail.com added the comment: Has the cdecimal branch kept up with the hash value changes in 3.2? Is there a still a chance that cdecimal could be merged into 3.2? -- nosy: +casevh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Case Van Horsen cas...@gmail.com added the comment: On Win64, I get two unexpected failures: I terminated test_capi after a Windows exception box popped up. [ 37/349] test_capi test test_capi failed -- Traceback (most recent call last): File C:\svn\py3k\lib\test\test_capi.py, line 50, in test_no_FatalError_infinite_loop b'Fatal Python error:' AssertionError: bFatal Python error: PyThreadState_Get: no current thread\r\n\r\nThis application has requested the Runtime to term inate it in an unusual way.\nPlease contact the application's support team for more information. != b'Fatal Python error: PyThreadS tate_Get: no current thread' [ 67/349] test_concurrent_futures test test_concurrent_futures failed -- Traceback (most recent call last): File C:\svn\py3k\lib\test\test_concurrent_futures.py, line 442, in test_timeout future1]), finished) AssertionError: Items in the second set but not the first: Future at 0x5510fd0 state=finished raised AssertionError The dictviews test passes successfully. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10185] Py_hash_t declaration needed in _testcapimodule
New submission from Case Van Horsen cas...@gmail.com: While researching errors in issue 9778, I found a variable in _testcapimodule.c that should be declared Py_hash_t instead of long. Patch is attached. -- components: Interpreter Core files: py_hash_t_testcapimodule.diff keywords: patch messages: 119469 nosy: casevh priority: normal severity: normal status: open title: Py_hash_t declaration needed in _testcapimodule versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file19346/py_hash_t_testcapimodule.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10185 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Case Van Horsen cas...@gmail.com added the comment: I maintain gmpy and it needs to calculate hash values for integers, floats, and rationals. I converted my hash calculations to use Py_ssize_t in a 64-bit Windows enviroment. All my tests pass when I build Python with my previous patch. In hindsight, I think I made a mistake in my previous patch by eliminating Py_hash_t and using Py_ssize_t/size_t. I ended up defining Py_hash_t and Py_uhash_t in gmpy to simplify the code and to easily support older versions of Python. I will work on a patch that defines Py_hash_t and Py_uhash_t and upload it later this evening. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Case Van Horsen cas...@gmail.com added the comment: I've uploaded a patch against the current svn trunk that: 1) Defines a Py_uhash_t as equivalent to size_t. 2) Correctly defines _PyHASH_MODULUS on Win64. 3) Replaces several PyLong_FromLong with PyLong_FromSsize_t. 4) Change typeobject/wrap_hashfunc to use Py_hash_t instead of long. 5) Change tupleobject/tuplehash to use Py_hast_t instead of long. 6) Change long/double/complex hash functions to use Py_uhash_t instead of unsigned long. -- Added file: http://bugs.python.org/file19338/Py_uhash_t_patch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Case Van Horsen cas...@gmail.com added the comment: I've attached a patch that fixes hashing for numerical types, sys.hash_info is now correct, fixes typeobject.c/wrap_hashfunc and tupleobject.c/tuplehash to use Py_ssize_t instead of long, and uses Py_ssize_t instead of Py_hash_t. I think it is clearer to use Py_ssize_t instead of Py_hash_t. I found two occurances where PyLong_FromLong needed to be replaced by PyLong_FromSsize_t and I think bugs like that would be easier to catch if Py_ssize_t is used. -- Added file: http://bugs.python.org/file19317/py_ssize_t_hash_patch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Case Van Horsen cas...@gmail.com added the comment: Some quick comments on the latest patch. 1) I don't think you can remove the type cast used when comparing the hash value against -1 and -2. IIRC, GCC considers that undefined behavior. 2) In sysmodule.c, we need to use PyLong_FromSsize_t when storing _PyHASH_MODULUS. 3) In pyport.h, we need a better way to define _PyHASH_MODULUS. The existing ((1UL _PyHASH_BITS) - 1) fails when unsigned long is smaller than Py_ssize_t. ((1ULL _PyHASH_BITS) - 1) works on 64-bit Windows but is not a good solution for systems that don't have an unsigned long long type. I haven't thought of a better solution for one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Case Van Horsen cas...@gmail.com added the comment: Also, note that hash(-12) is -12. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Case Van Horsen cas...@gmail.com added the comment:
Sorry, I could have been clearer indeed. Consider the following code:
static Py_hash_t
long_hash(PyLongObject *v)
{
unsigned long x;
...
x = x * sign;
if (x == (unsigned long)-1)
x = (unsigned long)-2;
return (Py_hash_t)x;
}
Wouldn't it be cleaner if x was the same type as hash? Note that
unsigned long is now wrong. What is needed is unsigned integer type
of the same size as Py_hash_t. If Py_hash_t has to stay signed, I
think we should at least not rely of sizeof(Py_hash_t) to always
remain the same as sizeof(size_t).
The calculation of long_hash assumes an unsigned temporary type to get correct
results for the bit shifting and masking. The calculation is done on the
absolute value of the long and then the sign is applied. We either needed to
(1) add an unsigned Py_hash_t type or (2) just use size_t and Py_ssize_t.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9778
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Case Van Horsen cas...@gmail.com added the comment: I'm the maintainer of a third-party library (gmpy) that would be impacted by this and I'm definately in favor of this change. With ever increasing amounts of memory becoming standard in computers, more users will encounter performance issues with large dictionaries. I see 3.2 as the version of Python 3.x that gains wide-spread use. Regardless of the timing of a stable ABI, it's popularity will make it more difficult change the hash size in the future. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Case Van Horsen cas...@gmail.com added the comment: The patch does not address that unsigned long is still used to calculate the hash values. This breaks numeric hashing and leads to incorrect values. Python 3.2a3+ (py3k, Oct 17 2010, 19:03:38) [MSC v.1500 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import sys sys.hash_info sys.hash_info(width=64, modulus=-1, inf=314159, nan=0, imag=103) Would size_t be the appropriate type to use? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)
Changes by Case Van Horsen cas...@gmail.com: -- nosy: +casevh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9739] Output of help(...) is wider than 80 characters
Case Van Horsen cas...@gmail.com added the comment: I edited the doc string for math.modf since an indent of 8 spaces is used for the doc string with help(math). An indent of 4 spaces is used with help(math.modf). I've attached a new patch for just the math module that includes the return type as part of signature line, corrects the width issues, and uses a consistent format for defining the doc strings. -- Added file: http://bugs.python.org/file18761/math_docstring.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9739] Output of help(...) is wider than 80 characters
Case Van Horsen cas...@gmail.com added the comment: According to PEP 7, the first line of the doc string should contain the signature of the function, then there should be a blank line, and then the rest of the doc string. There may be tools that extract the signature line. The patch just decreases the line length of the remaining lines of the doc string so they don't wrap when displayed on an 80 character wide terminal window. For an example, look at the text for modf(...) in help(math). I just noticed that the math module uses modf(x) for the signature line but PEP 7 recommends including the return type, say modf(x) - (frac, int). The simplest change would be to fix the wrapping issue and leave the signature line alone. It would be more effort to make all the doc strings PEP 7 compliant by standardizing the signature line to include the return type. I'm willing to work through the standard library and create patches for either option. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9739] Output of help(...) is wider than 80 characters
New submission from Case Van Horsen cas...@gmail.com: In several modules, the output of help(some_module) is wider than 80 characters. This results in extra line wrapping and incorrect formatting of the help text. I've attached a single patch (doc_width1.diff) that corrects the issue for math, cmath, tuple, datetime, and time modules. I can continue to create patches for a few modules at a time, or I can create patches for individual modules. I'm not changing any text, only adding \n as needed. -- components: Extension Modules files: doc_width1.diff keywords: patch messages: 115359 nosy: casevh priority: normal severity: normal status: open title: Output of help(...) is wider than 80 characters type: behavior Added file: http://bugs.python.org/file18707/doc_width1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8188] Unified hash for numeric types.
Case Van Horsen cas...@gmail.com added the comment: I've spent some time working through the new hash function by re-implementing it for gmpy. Very elegant design. I like _PyHASH_MODULUS better, too. Regarding a hash function for complex types, I think documenting the existing behavior for PyComplex is sufficient. The magic number 103 could be documented in hash_info as 'multiplier' and _PyHASH_MULTIPLIER. The same constant, but a different algorithm, is also used when hashing a tuple. I think hash(m/P) should preserve sign. It just seems more symmetrical. :) -- nosy: +casevh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7767] Add PyLong_AsLongLongAndOverflow
Case Van Horsen cas...@gmail.com added the comment: The missing PyInt_Check is a mistake. I probably thought I was working on a py3k version. Let me know if I should create a new patch or if I should create one for py3k. Thanks for the review. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7767] Add PyLong_AsLongLongAndOverflow
New submission from Case Van Horsen cas...@gmail.com: There are Long and LongLong variants for most of the C API functions that work with PyLong. This patch adds a LongLong version of PyLong_AsLongAndOverflow. This function will be helpful on 64-bit Windows platforms to quickly get a 64-bit integer or detect the need for multiple precision (or overflow). I can use this functionality for gmpy. -- components: Extension Modules files: patch_longlong.diff keywords: patch messages: 98203 nosy: casevh severity: normal status: open title: Add PyLong_AsLongLongAndOverflow type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file15985/patch_longlong.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python 2.x
Case Van Horsen cas...@gmail.com added the comment: I will work on documentation and test case patches. Per comments on python-dev, there doesn't appear to be interest in distributing forward compatibility files. I will update the bug report with a slightly revised version of py3intcompat.c and just leave it at that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python 2.x
Case Van Horsen cas...@gmail.com added the comment: I uploaded a new consolidated diff that includes the original patch with (hopefully) correct whitespace, some tests, and doc updates. The test just verifies that overflow is set/cleared properly. Proper conversions to long are already tested in test_capi. Let me know if I should add more tests. I couldn't find any tests for LongAndOverflow in 3.x. -- Added file: http://bugs.python.org/file15640/patch7528.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python 2.x
New submission from Case Van Horsen cas...@gmail.com:
When I ported gmpy to Python 3.x, I began to use
PyLong_AsLongAndOverflow frequently. I found the code to slightly faster
and cleaner than using PyLong_AsLong and checking for overflow. I had
several code fragments that looked like:
#if PY_MAJOR_VERSION == 2
if(PyInt_Check(b)) {
temp = PyInt_AS_LONG(b));
Do stuff with temp.
}
#endif
if(PyLong_Check(b)) {
#if PY_MAJOR_VERSION == 3
temp = PyLong_AsLongAndOverflow(b, overflow);
if(overflow) {
#else
temp = PyLong_AsLong(b);
if(PyErr_Occurred()) {
PyErr_Clear();
#endif
Convert b to an mpz.
} else {
Do stuff with temp.
}
}
I wanted to use the PyLong_AsLongAndOverflow method with Python 2.x so I
extracted the code for PyLong_AsLongAndOverflow, tweeked it to accept
either PyInt or PyLong, and called it PyIntOrLong_AsLongAndOverflow. I
also defined PyIntOrLong_Check.
The same code fragment now looks like:
if(PyIntOrLong_Check(b)) {
temp = PyIntOrLong_AsLongAndOverflow(b, overflow);
if(overflow) {
Convert b to an mpz.
} else {
Do stuff with temp.
}
}
Is it possible to include a py3intcompat.c file with Python 2.7 that
provides this function (and possibly others) for extension authors to
include with their extension? A previous example is pymemcompat.h which
was made available in the Misc directory.
I'm specifically not in favor of adding it to the Python 2.7 API but
just in providing a file for extension authors to use. I've attached a
initial version that compiles successfully with Python 2.4+.
I'm willing to add additional functions, documentation, etc.
--
components: Extension Modules
messages: 96505
nosy: casevh
severity: normal
status: open
title: Provide PyLong_AsLongAndOverflow compatibility to Python 2.x
type: feature request
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7528
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python 2.x
Case Van Horsen cas...@gmail.com added the comment: Attached py3intcompat.c -- Added file: http://bugs.python.org/file15579/py3intcompat.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python 2.x
Case Van Horsen cas...@gmail.com added the comment: I don't want it to be a 2.7-only feature. I'm trying to maintain compatibility with 2.4 and later for gmpy. I would be in favor with adding it to 2.7 as long as we could still provide a standalone version for earlier releases of Python. I hadn't realized that PyLong_AsLong accepts PyInt also. Given that, the name PyLong_AsLongAndOverflow is fine (and easier)! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python 2.x
Case Van Horsen cas...@gmail.com added the comment: I uploaded a patch to add PyLong_AsLongAndOverflow. It was made against the 2.7a1 source. make test, gmpy's test suite, and mpmath's test suite all pass. Let me know if there is anything else I can do. -- keywords: +patch Added file: http://bugs.python.org/file15587/longobject.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python 2.x
Case Van Horsen cas...@gmail.com added the comment: Uploaded a new version of py3intcompat.c. It should be save to include with any version of Python, included 2.7 with PyLong_AsLongAndOverflow added. The file includes basic documentation on use. -- Added file: http://bugs.python.org/file15588/py3intcompat-v2.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7414] Format code C is missing from skipitem() in getargs.c
New submission from Case Van Horsen cas...@gmail.com:
An error was reported on c.l.py. The following code in a Python 3
extension module generated an error:
=
If I use the following C code
static PyObject* foo(PyObject *self, PyObject *args, PyObject *kwrds)
{
char a, b;
char *kwlist[] = {a, b, NULL};
if (!PyArg_ParseTupleAndKeywords(args, kwrds, |CC, kwlist, a,
b))
return NULL;
...
then the following works:
foo('a')
foo('a','b')
foo(a='a',b='b')
but the following fails:
foo(b='b')
RuntimeError: impossiblebad format char: 'CC'
==
I traced it down to missing case statement for C in skipitem() in
getargs.c. The attached patch seems to fix the issue.
--
components: Extension Modules
files: getargs.patch
keywords: patch
messages: 95846
nosy: casevh
severity: normal
status: open
title: Format code C is missing from skipitem() in getargs.c
versions: Python 3.1
Added file: http://bugs.python.org/file15421/getargs.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7414
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6431] Fraction fails equality test with a user-defined type
Case Van Horsen cas...@gmail.com added the comment: On Thu, Jul 16, 2009 at 11:34 AM, Mark Dickinsonrep...@bugs.python.org wrote: Mark Dickinson dicki...@gmail.com added the comment: Thanks again, casevh! The patch looks good. I've added to it a bit, though---see issue6431.patch. In detail: - don't use subtraction with unknown types for , =, , =; this is dangerous, since the unknown type may well do a lossy conversion, and comparisons should really be exact where possible; as with __eq__, it seems better to return NotImplemented and give the other type a chance. - handle infs and nans correctly in comparisons with floats - a few more tests. casevh, please could you have a look at the attached patch and let me know whether it still works with your gmpy port? I've tested gmpy with attached patch and all tests pass successfully. Thanks! Jeffrey, any comments on these changes? -- stage: test needed - patch review Added file: http://bugs.python.org/file14508/issue6431.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6431 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6431] Fraction fails equality test with a user-defined type
Case Van Horsen cas...@gmail.com added the comment: I've attached a patch that creates DummyRational and then tests comparisons between Fraction and DummyRational. The __eq__ method also verifies that the type of the other argument is fractions.Fraction. -- Added file: http://bugs.python.org/file14504/patch_test_fractions.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6431] Fraction fails equality test with a user-defined type
Case Van Horsen cas...@gmail.com added the comment: On Tue, Jul 7, 2009 at 1:26 AM, Mark Dickinsonrep...@bugs.python.org wrote: Mark Dickinson dicki...@gmail.com added the comment: I agree this should be fixed. The conversion to float in the else clause seems wrong to me: it can lose precision, making two unequal values compare equal. I also agree that we should be getting NotImplemented here. Do you have a patch available? I'll upload a patch this evening. As an aside, I'm interested that you're implementing comparisons between mpf and Decimal; how does that work? Do you also implement binary arithmetic operations between mpf and Decimal? What's the result type? When I do binary operations (including comparison), I check the type of both operands. If both operands are Integer (mpz, int, long), I convert both operands to an mpz and then perform the operation. Otherwise, if both operands are Rational (mpz, int, long, mpq, Fraction), I convert both operands to an mpq. Finally, if both operands appear to be a Number (mpz, int, long, mpq, Fraction, mpf, Decimal), I convert both operands to an mpf. In the latest release of GMPY, I always return a GMPY type (unless you are converting to float or int/long). To do the conversions, I just do mpq(str(Fraction)) or mpf(str(Decimal)). I realize that the conversions aren't perfect but are probably what a user expects. The fact that GMP uses radix 2^32 or 2^64 floating point with (randomly) either [prec+1] or [prec+2] digits makes predictable floating point challenging. ;-) (prec = floor(precision_in_bits/limb_size).) In GMPY 1.04, I forced all mpf results to have [prec+1] digits but it's still messy. Time to start working on MPFR support. -- nosy: +jyasskin, marketdickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6431 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6431] Fraction fails equality test with a user-defined type
Case Van Horsen cas...@gmail.com added the comment: Change Fraction __eq__ method to give the other operand a chance to perform the comparison if Fraction doesn't understand the other operand. -- keywords: +patch Added file: http://bugs.python.org/file14470/fractions_patch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6431] Fraction fails equality test with a user-defined type
New submission from Case Van Horsen cas...@gmail.com: I've ported the GMPY module to Python 3 and found a problem comparing Fraction to gmpy.mpq. mpq is the rational type in gmpy and knows how to convert a Fraction into an mpq. All operations appear to work properly except Fraction == mpq. mpq == Fraction does work correctly. gmpy's rich comparison routine recognizes the other argument as Fraction and converts to an mpq value properly. However, when Fraction == mpq is done, the Fraction argument is converted to a float before gmpy's rich comparison is called. The __eq__ routine in fractions.py is: def __eq__(a, b): a == b if isinstance(b, numbers.Rational): return (a._numerator == b.numerator and a._denominator == b.denominator) if isinstance(b, numbers.Complex) and b.imag == 0: b = b.real if isinstance(b, float): return a == a.from_float(b) else: # XXX: If b.__eq__ is implemented like this method, it may # give the wrong answer after float(a) changes a's # value. Better ways of doing this are welcome. return float(a) == b Shouldn't __eq__ return NotImplemented if it doesn't know how to handle the other argument? I changed return float(a) == b to return NotImplemented and GMPY and Python's test suite passed all tests. I used the same logic for comparisons between gmpy.mpf and Decimal and they all work correctly. Decimal does return NotImplemented when it can't convert the other argument. (GMPY 1.10 alpha2 fails due to this issue.) -- components: Library (Lib) messages: 90211 nosy: casevh severity: normal status: open title: Fraction fails equality test with a user-defined type type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
