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
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 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/i
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
On Tue, Feb 7, 2012 at 9:37 PM, Alec Taylor alec.tayl...@gmail.com wrote:
Thanks all for your replies.
I have now installed MSVC8 and YASM.
I assume you installed Visual Studio. I've omitted the commands to use
the SDK compiler below.
I was able to successfully run configure.bat and make.bat
into that DLL. Only the innvocation of setup.py should need
to refer to the MPIR library locations. I don't use pip so I'm not sure how to
get pip to install the resulting DLL, etc.
On Wed, Feb 8, 2012 at 9:48 PM, Case Van Horsen cas...@gmail.com wrote:
On Tue, Feb 7, 2012 at 9:37 PM, Alec Taylor
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
57 matches
Mail list logo
