Comments (7)
This is when
man & 255
is a gmpy's mpz. So it may as well be a bug in gmpy. Here is a fix that works:
# Index: mpmath/lib.py
--- mpmath/lib.py ( revision 518 ) +++ mpmath/lib.py (working copy) @@ -279,13 +279,13 @@ bc = prec # Strip trailing bits if not man & 1: - t = trailtable[man & 255] - t = trailtable[int(man & 255)] if not t: while not man & 255: man >>= 8 exp += 8 bc -= 8 - t = trailtable[man & 255] - t = trailtable[int(man & 255)] man >>= t exp += t bc -= t @@ -373,7 +373,7 @@ sign = 1 man = -man if man < 1024: - bc = bctable[man] - bc = bctable[int(man)] else: bc = bitcount(man) if not prec:
**Status:** Started
Original comment: http://code.google.com/p/mpmath/issues/detail?id=49#c1
Original author: https://code.google.com/u/104039945248245758823/
from mpmath.
I'd like to know how much slowdown this causes. An option would be to replace
trailtable and bctable by dicts if pyversion < 2.5 and gmpy-mode is used.
Original comment: http://code.google.com/p/mpmath/issues/detail?id=49#c2
Original author: https://code.google.com/u/111502149103757882156/
from mpmath.
Or just use this patch only for python < 2.5. Slow mpmath is better than no mpmath.
Original comment: http://code.google.com/p/mpmath/issues/detail?id=49#c3
Original author: https://code.google.com/u/104039945248245758823/
from mpmath.
The difference between Python 2.4 and 2.5 is that Python 2.5 uses the **index** method when indexing a list. The **index** method was added in gmpy 1.02.
I used int() when I was testing the gmpy patches because I was using gmpy 1.01 originally. I inadvertently removed when I started testing with gmpy 1.03.
I don't think using int() creates much of a slowdown.
Sorry about not testing under Python 2.4.
Original comment: http://code.google.com/p/mpmath/issues/detail?id=49#c4
Original author: https://code.google.com/u/casevh/
from mpmath.
I'm working on a patch but it's not as easy as it seems. It wasn't difficult to add int() to all the occurrences of bctable and trailtable. But while testing I've encountered another subtle issue.
I've been assuming that the types of the components of an mpf are (int, MP_BASE, int, int). But I've found at least one location where exp has type MP_BASE and a couple other places where bc or exp is type long. I fixed the occurrence where exp has type MP_BASE. I allowed bc and exp to become type long since I didn't think it was worth the overhead.
I updated the test in -strict mode. It's easy to edit the tests to catch when bc and exp are type long.
Original comment: http://code.google.com/p/mpmath/issues/detail?id=49#c5
Original author: https://code.google.com/u/casevh/
from mpmath.
Thanks for your work, now it works indeed. I'll update the mpmath in sympy.
Original comment: http://code.google.com/p/mpmath/issues/detail?id=49#c6
Original author: https://code.google.com/u/104039945248245758823/
from mpmath.
Just closing the issue since Ondrej reports the problem is fixed.
**Status:** Fixed **Owner:** casevh
Original comment: http://code.google.com/p/mpmath/issues/detail?id=49#c7
Original author: https://code.google.com/u/casevh/
from mpmath.
Related Issues (20)
- findpoly returning combination which is very far off HOT 2
- asinh returns incorrect results at complex infinities HOT 2
- Enhance autoprec function in mpmath library for precision control and early termination
- Better integration with numpy HOT 5
- Implement directed rounding in to_str()
- Random failures in CI on various PyPy versions: TypeError: expected some sort of stmt, but got <ast.Name/Load...
- Cross Product Function HOT 2
- Run mpmath as module (for interactive work)?
- log and log1p return incorrect results at complex infinities HOT 2
- sqrt returns incorrect results at complex infinities HOT 1
- Unable to compute mpmath.legenp(Even number, Odd number, 0) HOT 1
- mp.tanh and mp.tan return incorrect results at complex infinities HOT 2
- Manual zeta of Riemann diverges of "manual" implementation HOT 1
- mp.asin(z).imag and fp.asin(z).imag use inconsistent sign choices when z.real > 1 and z.imag==0 HOT 23
- mp.asin is inaccurate for small complex inputs HOT 3
- Poor result in log1p(complex) HOT 46
- mp.asin returns incorrect results at complex infinities HOT 8
- mpf shouldn't have __complex__ magic method
- mp.acot(cmath.infj) is mpc(real='nan', imag='nan'), should be 0
- Consider adding support for special numbers in almosteq()
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mpmath.