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 lo
New submission from Case Van Horsen :
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,
Case Van Horsen 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
Changes by Case Van Horsen :
--
nosy: +casevh
___
Python tracker
<http://bugs.python.org/issue9778>
___
___
Python-bugs-list mailing list
Unsubscribe:
Case Van Horsen 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 pa
Case Van Horsen 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
Case Van Horsen 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 "he
Case Van Horsen 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 st
Case Van Horsen added the comment:
Also, note that hash(-12) is -12.
--
___
Python tracker
<http://bugs.python.org/issue9778>
___
___
Python-bugs-list mailin
Case Van Horsen 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 lon
Case Van Horsen 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 clear
Case Van Horsen 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
Case Van Horsen 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 t
Case Van Horsen 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", l
New submission from Case Van Horsen :
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
Case Van Horsen 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
<http://bugs.python.org/issue7
New submission from Case Van Horsen :
Python 3.2 fails when printing long strings.
C:\Python32>python
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 inform
Case Van Horsen 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&q
New submission from Case Van Horsen :
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 qu
Case Van Horsen 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
Case Van Horsen 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 PyCompl
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
Case Van Horsen 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 gen
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
<http://bugs.python.org/is
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 "
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
<http://bugs.python.org/issue16
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.
Changes by Case Van Horsen :
--
nosy: +casevh
___
Python tracker
<http://bugs.python.org/issue21922>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
Changes by Case Van Horsen :
--
nosy: +casevh
___
Python tracker
<http://bugs.python.org/issue21955>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Case Van Horsen :
--
nosy: +casevh
___
Python tracker
<http://bugs.python.org/issue22444>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.pyth
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
Case Van Horsen added the comment:
On Sat, Sep 20, 2014 at 9:38 AM, Alexander Belopolsky
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
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:
>
>&
Changes by Case Van Horsen :
--
nosy: +casevh
___
Python tracker
<http://bugs.python.org/issue22198>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Case Van Horsen :
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".
&
Case Van Horsen added the comment:
On Tue, Jul 7, 2009 at 1:26 AM, Mark Dickinson wrote:
>
> Mark Dickinson 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
Case Van Horsen 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
Case Van Horsen 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/file
Case Van Horsen added the comment:
On Thu, Jul 16, 2009 at 11:34 AM, Mark Dickinson wrote:
>
> Mark Dickinson 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
New submission from Case Van Horsen :
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
New submission from Case Van Horsen :
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
Case Van Horsen added the comment:
Attached py3intcompat.c
--
Added file: http://bugs.python.org/file15579/py3intcompat.c
___
Python tracker
<http://bugs.python.org/issue7
Case Van Horsen 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&
Case Van Horsen 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: +pa
Case Van Horsen 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
Case Van Horsen 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 lea
Case Van Horsen 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
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
>>&
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 Pyt
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 s
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
Changes by Case Van Horsen :
--
nosy: +casevh
___
Python tracker
<http://bugs.python.org/issue4709>
___
___
Python-bugs-list mailing list
Unsubscribe:
55 matches
Mail list logo
