My favorites | Sign in
Project Logo
                
Details: Show all Hide all

Last 7 days

  • Dec 28, 2009
    issue 173 (/usr/lib/pymodules/python2.5/py/impl/path/local.py:528: Envi...) reported by matrixhasu   -   Hello, I'm forwarding the Debian bug 560631 : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560631 . Probably due to the recent upgrade to python-codespeak-lib 1.1.1, mpmath can't run tests anymore. During the package build we run python mpmath/tests/runtests.py -strict -py -local that now results in this failure (complete log is available in the above link): ======================================================= test session starts ======================================================== python: platform linux2 -- Python 2.5.4 -- pytest-1.1.1 test object 1: /home/morph/deb/build-area/mpmath-0.13 build/lib E mpmath/tests/test_basic_ops.py ............ mpmath/tests/test_bitwise.py .......... mpmath/tests/test_calculus.py ....... mpmath/tests/test_compatibility.py ... mpmath/tests/test_convert.py ............. mpmath/tests/test_diff.py .. mpmath/tests/test_division.py ....... mpmath/tests/test_elliptic.py ........... mpmath/tests/test_functions.py ........................................... mpmath/tests/test_functions2.py ..................................... mpmath/tests/test_gammazeta.py ........................... mpmath/tests/test_hp.py ... mpmath/tests/test_identify.py .. mpmath/tests/test_interval.py ......... mpmath/tests/test_linalg.py .............. mpmath/tests/test_matrices.py ........ mpmath/tests/test_mpmath.py ........ mpmath/tests/test_ode.py ..... mpmath/tests/test_pickle.py . mpmath/tests/test_power.py ... mpmath/tests/test_quad.py ............. mpmath/tests/test_rootfinding.py ....... mpmath/tests/test_special.py ..... mpmath/tests/test_summation.py ..... mpmath/tests/test_trig.py ... ============================================================== ERRORS ============================================================== _____________________________ ERROR during collection /home/morph/deb/build-area/mpmath-0.13/build/lib _____________________________ collector = <Directory 'lib'> def pytest_make_collect_report(collector): result = excinfo = None try: > result = collector._memocollect() /usr/lib/pymodules/python2.5/py/plugin/pytest_runner.py:31: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Directory 'lib'> def _memocollect(self): """ internal helper method to cache results of calling collect(). """ > return self._memoizedcall('_collected', self.collect) /usr/lib/pymodules/python2.5/py/impl/test/collect.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Directory 'lib'>, attrname = '_collected', function = <bound method Directory.collect of <Directory 'lib'>> def _memoizedcall(self, attrname, function): exattrname = "_ex_" + attrname failure = getattr(self, exattrname, None) if failure is not None: py.builtin._reraise(failure[0], failure[1], failure[2]) if hasattr(self, attrname): return getattr(self, attrname) try: > res = function() /usr/lib/pymodules/python2.5/py/impl/test/collect.py:99: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Directory 'lib'> def collect(self): l = self._deprecated_collect() if l is not None: return l l = [] for path in self.fspath.listdir(sort=True): > res = self.consider(path) /usr/lib/pymodules/python2.5/py/impl/test/collect.py:388: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Directory 'lib'>, path = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath') def consider(self, path): > if self._ignore(path): /usr/lib/pymodules/python2.5/py/impl/test/collect.py:406: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Directory 'lib'>, path = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath') def _ignore(self, path): > ignore_paths = self.config.getconftest_pathlist("collect_ignore", path=path) /usr/lib/pymodules/python2.5/py/impl/test/collect.py:397: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <py.impl.test.config.Config object at 0x2acb5f307b50>, name = 'collect_ignore' path = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath') def getconftest_pathlist(self, name, path=None): """ return a matching value, which needs to be sequence of filenames that will be returned as a list of Path objects (they can be relative to the location where they were found). """ try: > mod, relroots = self._conftest.rget_with_confmod(name, path) /usr/lib/pymodules/python2.5/py/impl/test/config.py:170: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <py.impl.test.conftesthandle.Conftest object at 0x2acb5f307bd0>, name = 'collect_ignore' path = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath') def rget_with_confmod(self, name, path=None): > modules = self.getconftestmodules(path) /usr/lib/pymodules/python2.5/py/impl/test/conftesthandle.py:60: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <py.impl.test.conftesthandle.Conftest object at 0x2acb5f307bd0> path = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath') def getconftestmodules(self, path): """ return a list of imported conftest modules for the given path. """ try: clist = self._path2confmods[path] except KeyError: if path is None: raise ValueError("missing default conftest.") dp = path.dirpath() if dp == path: return [self.importconftest(defaultconftestpath)] clist = self.getconftestmodules(dp) conftestpath = path.join("conftest.py") if conftestpath.check(file=1): > clist.append(self.importconftest(conftestpath)) /usr/lib/pymodules/python2.5/py/impl/test/conftesthandle.py:49: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <py.impl.test.conftesthandle.Conftest object at 0x2acb5f307bd0> conftestpath = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath/conftest.py') def importconftest(self, conftestpath): # Using caching here looks redundant since ultimately # sys.modules caches already assert conftestpath.check(), conftestpath if not conftestpath.dirpath('__init__.py').check(file=1): # HACK: we don't want any "globally" imported conftest.py, # prone to conflicts and subtle problems modname = str(conftestpath).replace('.', conftestpath.sep) mod = conftestpath.pyimport(modname=modname) else: > mod = conftestpath.pyimport() /usr/lib/pymodules/python2.5/py/impl/test/conftesthandle.py:79: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath/conftest.py'), modname = 'mpmath.conftest' ensuresyspath = True def pyimport(self, modname=None, ensuresyspath=True): """ return path as an imported python module. if modname is None, look for the containing package and construct an according module name. The module will be put/looked up in sys.modules. """ if not self.check(): raise py.error.ENOENT(self) #print "trying to import", self pkgpath = None if modname is None: pkgpath = self.pypkgpath() if pkgpath is not None: if ensuresyspath: self._prependsyspath(pkgpath.dirpath()) pkg = __import__(pkgpath.basename, None, None, []) names = self.new(ext='').relto(pkgpath.dirpath()) names = names.split(self.sep) modname = ".".join(names) else: # no package scope, still make it possible if ensuresyspath: self._prependsyspath(self.dirpath()) modname = self.purebasename mod = __import__(modname, None, None, ['__doc__']) modfile = mod.__file__ if modfile[-4:] in ('.pyc', '.pyo'): modfile = modfile[:-1] elif modfile.endswith('$py.class'): modfile = modfile[:-9] + '.py' if not self.samefile(modfile): raise EnvironmentError("mismatch:\n" "imported module %r\n" "does not stem from %r\n" > "maybe __init__.py files are missing?" % (mod, str(self))) E EnvironmentError: mismatch: E imported module <module 'mpmath.conftest' from '/home/morph/deb/build-area/mpmath-0.13/mpmath/conftest.py'> E does not stem from '/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath/conftest.py' E maybe __init__.py files are missing? /usr/lib/pymodules/python2.5/py/impl/path/local.py:528: EnvironmentError =============================================== 258 passed, 1 error in 45.53 seconds ===============================================
    Hello, I'm forwarding the Debian bug 560631 : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560631 . Probably due to the recent upgrade to python-codespeak-lib 1.1.1, mpmath can't run tests anymore. During the package build we run python mpmath/tests/runtests.py -strict -py -local that now results in this failure (complete log is available in the above link): ======================================================= test session starts ======================================================== python: platform linux2 -- Python 2.5.4 -- pytest-1.1.1 test object 1: /home/morph/deb/build-area/mpmath-0.13 build/lib E mpmath/tests/test_basic_ops.py ............ mpmath/tests/test_bitwise.py .......... mpmath/tests/test_calculus.py ....... mpmath/tests/test_compatibility.py ... mpmath/tests/test_convert.py ............. mpmath/tests/test_diff.py .. mpmath/tests/test_division.py ....... mpmath/tests/test_elliptic.py ........... mpmath/tests/test_functions.py ........................................... mpmath/tests/test_functions2.py ..................................... mpmath/tests/test_gammazeta.py ........................... mpmath/tests/test_hp.py ... mpmath/tests/test_identify.py .. mpmath/tests/test_interval.py ......... mpmath/tests/test_linalg.py .............. mpmath/tests/test_matrices.py ........ mpmath/tests/test_mpmath.py ........ mpmath/tests/test_ode.py ..... mpmath/tests/test_pickle.py . mpmath/tests/test_power.py ... mpmath/tests/test_quad.py ............. mpmath/tests/test_rootfinding.py ....... mpmath/tests/test_special.py ..... mpmath/tests/test_summation.py ..... mpmath/tests/test_trig.py ... ============================================================== ERRORS ============================================================== _____________________________ ERROR during collection /home/morph/deb/build-area/mpmath-0.13/build/lib _____________________________ collector = <Directory 'lib'> def pytest_make_collect_report(collector): result = excinfo = None try: > result = collector._memocollect() /usr/lib/pymodules/python2.5/py/plugin/pytest_runner.py:31: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Directory 'lib'> def _memocollect(self): """ internal helper method to cache results of calling collect(). """ > return self._memoizedcall('_collected', self.collect) /usr/lib/pymodules/python2.5/py/impl/test/collect.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Directory 'lib'>, attrname = '_collected', function = <bound method Directory.collect of <Directory 'lib'>> def _memoizedcall(self, attrname, function): exattrname = "_ex_" + attrname failure = getattr(self, exattrname, None) if failure is not None: py.builtin._reraise(failure[0], failure[1], failure[2]) if hasattr(self, attrname): return getattr(self, attrname) try: > res = function() /usr/lib/pymodules/python2.5/py/impl/test/collect.py:99: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Directory 'lib'> def collect(self): l = self._deprecated_collect() if l is not None: return l l = [] for path in self.fspath.listdir(sort=True): > res = self.consider(path) /usr/lib/pymodules/python2.5/py/impl/test/collect.py:388: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Directory 'lib'>, path = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath') def consider(self, path): > if self._ignore(path): /usr/lib/pymodules/python2.5/py/impl/test/collect.py:406: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Directory 'lib'>, path = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath') def _ignore(self, path): > ignore_paths = self.config.getconftest_pathlist("collect_ignore", path=path) /usr/lib/pymodules/python2.5/py/impl/test/collect.py:397: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <py.impl.test.config.Config object at 0x2acb5f307b50>, name = 'collect_ignore' path = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath') def getconftest_pathlist(self, name, path=None): """ return a matching value, which needs to be sequence of filenames that will be returned as a list of Path objects (they can be relative to the location where they were found). """ try: > mod, relroots = self._conftest.rget_with_confmod(name, path) /usr/lib/pymodules/python2.5/py/impl/test/config.py:170: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <py.impl.test.conftesthandle.Conftest object at 0x2acb5f307bd0>, name = 'collect_ignore' path = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath') def rget_with_confmod(self, name, path=None): > modules = self.getconftestmodules(path) /usr/lib/pymodules/python2.5/py/impl/test/conftesthandle.py:60: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <py.impl.test.conftesthandle.Conftest object at 0x2acb5f307bd0> path = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath') def getconftestmodules(self, path): """ return a list of imported conftest modules for the given path. """ try: clist = self._path2confmods[path] except KeyError: if path is None: raise ValueError("missing default conftest.") dp = path.dirpath() if dp == path: return [self.importconftest(defaultconftestpath)] clist = self.getconftestmodules(dp) conftestpath = path.join("conftest.py") if conftestpath.check(file=1): > clist.append(self.importconftest(conftestpath)) /usr/lib/pymodules/python2.5/py/impl/test/conftesthandle.py:49: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <py.impl.test.conftesthandle.Conftest object at 0x2acb5f307bd0> conftestpath = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath/conftest.py') def importconftest(self, conftestpath): # Using caching here looks redundant since ultimately # sys.modules caches already assert conftestpath.check(), conftestpath if not conftestpath.dirpath('__init__.py').check(file=1): # HACK: we don't want any "globally" imported conftest.py, # prone to conflicts and subtle problems modname = str(conftestpath).replace('.', conftestpath.sep) mod = conftestpath.pyimport(modname=modname) else: > mod = conftestpath.pyimport() /usr/lib/pymodules/python2.5/py/impl/test/conftesthandle.py:79: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = local('/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath/conftest.py'), modname = 'mpmath.conftest' ensuresyspath = True def pyimport(self, modname=None, ensuresyspath=True): """ return path as an imported python module. if modname is None, look for the containing package and construct an according module name. The module will be put/looked up in sys.modules. """ if not self.check(): raise py.error.ENOENT(self) #print "trying to import", self pkgpath = None if modname is None: pkgpath = self.pypkgpath() if pkgpath is not None: if ensuresyspath: self._prependsyspath(pkgpath.dirpath()) pkg = __import__(pkgpath.basename, None, None, []) names = self.new(ext='').relto(pkgpath.dirpath()) names = names.split(self.sep) modname = ".".join(names) else: # no package scope, still make it possible if ensuresyspath: self._prependsyspath(self.dirpath()) modname = self.purebasename mod = __import__(modname, None, None, ['__doc__']) modfile = mod.__file__ if modfile[-4:] in ('.pyc', '.pyo'): modfile = modfile[:-1] elif modfile.endswith('$py.class'): modfile = modfile[:-9] + '.py' if not self.samefile(modfile): raise EnvironmentError("mismatch:\n" "imported module %r\n" "does not stem from %r\n" > "maybe __init__.py files are missing?" % (mod, str(self))) E EnvironmentError: mismatch: E imported module <module 'mpmath.conftest' from '/home/morph/deb/build-area/mpmath-0.13/mpmath/conftest.py'> E does not stem from '/home/morph/deb/build-area/mpmath-0.13/build/lib/mpmath/conftest.py' E maybe __init__.py files are missing? /usr/lib/pymodules/python2.5/py/impl/path/local.py:528: EnvironmentError =============================================== 258 passed, 1 error in 45.53 seconds ===============================================

Last 30 days

  • Dec 22, 2009
    r1001 (implement analytic continuation for pFq, p=q+1 to |z| >= 1; ...) committed by fredrik.johansson   -   implement analytic continuation for pFq, p=q+1 to |z| >= 1; special-case hyp3f2
    implement analytic continuation for pFq, p=q+1 to |z| >= 1; special-case hyp3f2
  • Dec 21, 2009
    r1000 (minor cleanup) committed by fredrik.johansson   -   minor cleanup
    minor cleanup
  • Dec 21, 2009
    r999 (fix besselj, expint, gammainc, erf, erfc for fp by falling b...) committed by fredrik.johansson   -   fix besselj, expint, gammainc, erf, erfc for fp by falling back to the generic code by default
    fix besselj, expint, gammainc, erf, erfc for fp by falling back to the generic code by default
  • Dec 20, 2009
    r998 (various small fixes) committed by fredrik.johansson   -   various small fixes
    various small fixes
  • Dec 19, 2009
    issue 172 (AttributeError: 'MultiPrecisionArithmetic' object has no att...) reported by nils106   -   What steps will reproduce the problem? 1. python -i mpmath/mpmath/tests/runtests.py 2. 3. What is the expected output? What do you see instead? Traceback (most recent call last): File "mpmath/mpmath/tests/runtests.py", line 142, in <module> testit(importdir, testdir) File "mpmath/mpmath/tests/runtests.py", line 101, in testit module = __import__(name) File "/home/nwagner/svn/mpmath/mpmath/tests/test_linalg.py", line 8, in <module> LU_decomp = mp.LU_decomp AttributeError: 'MultiPrecisionArithmetic' object has no attribute 'LU_decomp' What version of the product are you using? >>> mpmath.__version__ '0.13' On what operating system? Linux linux-mogv 2.6.31.5-0.1-default #1 SMP 2009-10-26 15:49:03 +0100 x86_64 x86_64 x86_64 GNU/Linux Welcome to openSUSE 11.2 "Emerald" - Kernel \r (\l). Please provide any additional information below.
    What steps will reproduce the problem? 1. python -i mpmath/mpmath/tests/runtests.py 2. 3. What is the expected output? What do you see instead? Traceback (most recent call last): File "mpmath/mpmath/tests/runtests.py", line 142, in <module> testit(importdir, testdir) File "mpmath/mpmath/tests/runtests.py", line 101, in testit module = __import__(name) File "/home/nwagner/svn/mpmath/mpmath/tests/test_linalg.py", line 8, in <module> LU_decomp = mp.LU_decomp AttributeError: 'MultiPrecisionArithmetic' object has no attribute 'LU_decomp' What version of the product are you using? >>> mpmath.__version__ '0.13' On what operating system? Linux linux-mogv 2.6.31.5-0.1-default #1 SMP 2009-10-26 15:49:03 +0100 x86_64 x86_64 x86_64 GNU/Linux Welcome to openSUSE 11.2 "Emerald" - Kernel \r (\l). Please provide any additional information below.
  • Dec 19, 2009
    issue 170 (Merge new contexts code) Status changed by Vinzent.Steinberg   -  
    Status: Fixed
    Status: Fixed
  • Dec 19, 2009
    issue 171 (Reorganization) commented on by Vinzent.Steinberg   -   Also names like math2.py and ctx_fp.py should be fixed to be consistent with the rest. Maybe libfp/?
    Also names like math2.py and ctx_fp.py should be fixed to be consistent with the rest. Maybe libfp/?
  • Dec 18, 2009
    issue 171 (Reorganization) reported by fredrik.johansson   -   I think it's long overdue to organize the files into subdirectories and split up some of the files. With the contexts update, this should no longer cause any importing or dependency headaches. A possibility: lib*.py, settings.py -> libmp/ (this code doesn't depend on anything else) functions.py -> functions/ (and split it up) matrices.py, linalg.py -> linalg/ calculus.py, odes.py, quadrature.py, optimization.py -> calculus/ (and maybe split up at least calculus.py) identification.py, visualization.py -> misc/ (maybe? or just keep in the root) Code implementing the context classes remains in the root.
    I think it's long overdue to organize the files into subdirectories and split up some of the files. With the contexts update, this should no longer cause any importing or dependency headaches. A possibility: lib*.py, settings.py -> libmp/ (this code doesn't depend on anything else) functions.py -> functions/ (and split it up) matrices.py, linalg.py -> linalg/ calculus.py, odes.py, quadrature.py, optimization.py -> calculus/ (and maybe split up at least calculus.py) identification.py, visualization.py -> misc/ (maybe? or just keep in the root) Code implementing the context classes remains in the root.
  • Dec 18, 2009
    r997 (Merge new contexts code from the mp4 branch. * All the high...) committed by fredrik.johansson   -   Merge new contexts code from the mp4 branch. * All the high level modules now use context instances and methods thereof instead of the global mp object and global functions * Implemented a fixed-precision (using float/complex) context, with a default fp instance. It mostly works but some necessary methods are not yet implemented or broken. * Most implementation details of functions.py have been removed and moved to helper methods in mptypes.py * This patch also adds the new hypergeometric series code from the mp4 branch, and a few other changes to special functions such as layout of the elliptic functions code (djtheta removed; added a derivative paramter to jtheta instead)
    Merge new contexts code from the mp4 branch. * All the high level modules now use context instances and methods thereof instead of the global mp object and global functions * Implemented a fixed-precision (using float/complex) context, with a default fp instance. It mostly works but some necessary methods are not yet implemented or broken. * Most implementation details of functions.py have been removed and moved to helper methods in mptypes.py * This patch also adds the new hypergeometric series code from the mp4 branch, and a few other changes to special functions such as layout of the elliptic functions code (djtheta removed; added a derivative paramter to jtheta instead)
  • Dec 17, 2009
    issue 170 (Merge new contexts code) commented on by Vinzent.Steinberg   -   Ok, so let's merge your code. There are quite a lot of rough ends, but this can be fixed before the next release.
    Ok, so let's merge your code. There are quite a lot of rough ends, but this can be fixed before the next release.
  • Dec 17, 2009
    issue 170 (Merge new contexts code) commented on by fredrik.johansson   -   > So do they pass or not? If not, this should probably be fixed before merging, > otherwise it will be seemingly hard for me to refactor code. The tests pass (at least for me), but the pickle tests pass only due to a workaround (see __init__.py). And there are a few broken doctests (again, broken for trivial reasons).
    > So do they pass or not? If not, this should probably be fixed before merging, > otherwise it will be seemingly hard for me to refactor code. The tests pass (at least for me), but the pickle tests pass only due to a workaround (see __init__.py). And there are a few broken doctests (again, broken for trivial reasons).
  • Dec 17, 2009
    issue 170 (Merge new contexts code) commented on by Vinzent.Steinberg   -   The force_type stuff is anyway somewhat broken, so don't worry. I'll have a closer look later. Basically I'm +1 for merging soon, it's a nice feature, and I assume it's no pleasure to maintain branches in svn. > tests basically pass So do they pass or not? If not, this should probably be fixed before merging, otherwise it will be seemingly hard for me to refactor code.
    The force_type stuff is anyway somewhat broken, so don't worry. I'll have a closer look later. Basically I'm +1 for merging soon, it's a nice feature, and I assume it's no pleasure to maintain branches in svn. > tests basically pass So do they pass or not? If not, this should probably be fixed before merging, otherwise it will be seemingly hard for me to refactor code.
  • Dec 17, 2009
    issue 170 (Merge new contexts code) reported by fredrik.johansson   -   Here is a big patch merging changes from the mp4 branch to fully support multiple contexts (both classes and instances). Also there are some optimizations and minor bugfixes from that branch. It also adds a machine precision context, which is still in a very rough state, but which supports the basics. A nifty example: >>> mp.dps = 1000 >>> timing(lambda: mp.findroot(mp.cos, 1)) 0.025849207091962804 >>> timing(lambda: mp.findroot(mp.cos, fp.findroot(fp.cos, 1))) 0.016556294165877894 All old tests pass, with the exception of some trivial printing related issues, and pickling (there is a horrible hack in place atm to fix pickling -- this needs to be done properly). This needs more cleanup, and I'd like to do a bit renaming and reorganizing. Some features that should be shared for the context implementations is currently duplicated or hackish. A couple of function/module names are awful and/or awfully inconsistent. There are also barely any fp tests. We should fix the tests and doctests to import and use mp and fp objects explicitly, and test both. Besides the pickling issue, there are also probably issues with generating the docs now that more things are created dynamically... I haven't looked at it, but the problems are probably easy to fix. Also, Vinzent, your code (optimization and matrices) perhaps needs a closer look. The force_type stuff should be possible to remove; we should always just convert the inputs, and the fp context will support float/complex. I did a bit of work on this already, but it needs to be done thoroughly. Vinzent - do you think it's ok to apply this to the trunk as it is? Although it will introduce some minor breakage at this point, tests basically pass, and I'd rather merge as soon as possible so I can also work on some overdue features and bugfixes without having to worry about having two codebases.
    Here is a big patch merging changes from the mp4 branch to fully support multiple contexts (both classes and instances). Also there are some optimizations and minor bugfixes from that branch. It also adds a machine precision context, which is still in a very rough state, but which supports the basics. A nifty example: >>> mp.dps = 1000 >>> timing(lambda: mp.findroot(mp.cos, 1)) 0.025849207091962804 >>> timing(lambda: mp.findroot(mp.cos, fp.findroot(fp.cos, 1))) 0.016556294165877894 All old tests pass, with the exception of some trivial printing related issues, and pickling (there is a horrible hack in place atm to fix pickling -- this needs to be done properly). This needs more cleanup, and I'd like to do a bit renaming and reorganizing. Some features that should be shared for the context implementations is currently duplicated or hackish. A couple of function/module names are awful and/or awfully inconsistent. There are also barely any fp tests. We should fix the tests and doctests to import and use mp and fp objects explicitly, and test both. Besides the pickling issue, there are also probably issues with generating the docs now that more things are created dynamically... I haven't looked at it, but the problems are probably easy to fix. Also, Vinzent, your code (optimization and matrices) perhaps needs a closer look. The force_type stuff should be possible to remove; we should always just convert the inputs, and the fp context will support float/complex. I did a bit of work on this already, but it needs to be done thoroughly. Vinzent - do you think it's ok to apply this to the trunk as it is? Although it will introduce some minor breakage at this point, tests basically pass, and I'd rather merge as soon as possible so I can also work on some overdue features and bugfixes without having to worry about having two codebases.
  • Dec 16, 2009
    issue 169 (mpmath docstring edits) reported by smichr   -   Version 0.13 As part of sympy editing, I have some docstring edits for mpmath available from smichr's 1509mpmath branch at github.
    Version 0.13 As part of sympy editing, I have some docstring edits for mpmath available from smichr's 1509mpmath branch at github.
  • Dec 11, 2009
    issue 168 (mpmath docstring edits) Status changed by Vinzent.Steinberg   -   This is in, thank you!
    Status: Fixed
    This is in, thank you!
    Status: Fixed
  • Dec 09, 2009
    r996 (fix some exception; thanks to Chris Smith for spotting this) committed by Vinzent.Steinberg   -   fix some exception; thanks to Chris Smith for spotting this
    fix some exception; thanks to Chris Smith for spotting this
  • Dec 09, 2009
    r995 (fix some typos; contributed by Chris Smith) committed by Vinzent.Steinberg   -   fix some typos; contributed by Chris Smith
    fix some typos; contributed by Chris Smith
  • Dec 08, 2009
    issue 168 (mpmath docstring edits) reported by smichr   -   What version of the product are you using? On what operating system? 0.13 Please provide any additional information below. A pass through the docstrings produced the patch available on 1509mpmath at smichr's github account. Only the final commit has the mpmath changes.
    What version of the product are you using? On what operating system? 0.13 Please provide any additional information below. A pass through the docstrings produced the patch available on 1509mpmath at smichr's github account. Only the final commit has the mpmath changes.

Older

  • Nov 24, 2009
    issue 167 (Error in mpf_abs) commented on by casevh   -   I fixed my refactoring in gmpy. gmpy should accept True and False everywhere again. It was a regression inadvertently added in v1.10.
    I fixed my refactoring in gmpy. gmpy should accept True and False everywhere again. It was a regression inadvertently added in v1.10.
  • Nov 21, 2009
    issue 167 (Error in mpf_abs) reported by casevh   -   I was refactoring some of the gmpy code and I encountered an error in mpmath_normalize. I was receiving a 'False' instead of 0 for the sign parameter. The old gmpy code defaulted to 0 when passed an invalid parameter; now it raises an error. I tracked it down to mpf_abs. The code: if sign: return (not sign, man, exp, bc) should be: if sign: return (0, man, exp, bc) I've made the change to my local copy and all tests pass. I didn't find any other occurrences of 'not sign' that should cause a problem. Case
    I was refactoring some of the gmpy code and I encountered an error in mpmath_normalize. I was receiving a 'False' instead of 0 for the sign parameter. The old gmpy code defaulted to 0 when passed an invalid parameter; now it raises an error. I tracked it down to mpf_abs. The code: if sign: return (not sign, man, exp, bc) should be: if sign: return (0, man, exp, bc) I've made the change to my local copy and all tests pass. I didn't find any other occurrences of 'not sign' that should cause a problem. Case
  • Nov 15, 2009
    issue 166 (lambertw is sometimes wrong) reported by bo198214   -   mpmath.lambertw(-mpmath.log(mpmath.mpc(1.4 ,0.633)),0) returns mpc(real='-1.2605156720338708', imag='1.7173503371737457') this is the same value as for the branch 1. The correct values must differ, they are: 0.7232832635 + 0.1803146260*I for branch 0 and -1.188149953 + 4.899092880*I for branch 1. In [31]: mpmath.__version__ Out[31]: '0.13' on gentoo under sage
    mpmath.lambertw(-mpmath.log(mpmath.mpc(1.4 ,0.633)),0) returns mpc(real='-1.2605156720338708', imag='1.7173503371737457') this is the same value as for the branch 1. The correct values must differ, they are: 0.7232832635 + 0.1803146260*I for branch 0 and -1.188149953 + 4.899092880*I for branch 1. In [31]: mpmath.__version__ Out[31]: '0.13' on gentoo under sage
  • Nov 11, 2009
    issue 164 ([PATCH] Support for custom axes in visualization module) commented on by jorn.baayen   -   Not sure if this has a place in mpmath, but I'm attaching it anyway, even if just for reference: A function for 3D plotting of surfaces in the style of plot() and cplot(). It depends on matplotlib >= 0.98.5.3 for availability of the mplot3d toolkit.
    Not sure if this has a place in mpmath, but I'm attaching it anyway, even if just for reference: A function for 3D plotting of surfaces in the style of plot() and cplot(). It depends on matplotlib >= 0.98.5.3 for availability of the mplot3d toolkit.
  • Nov 11, 2009
    issue 165 (Wrong output from hyp2f1 for a or b large negative integer) reported by pvirtn   -   hyp2f1 returns wrong results for a, b large negative integers: >>> mpmath.hyp2f1(10, -900, 10.5, 0.99) mpf('-7.4446255129772491e-22') >>> scipy.special.hyp2f1(10, -900, 10.5, 0.99) 1.9185370579660795e-24 1.9185370579660766480e-24 # from Mathematica >>> mpmath.hyp2f1(10, -900.000001, 10.5, 0.99) mpf('1.9185370367664393e-24') [Yes, SVN Scipy's hyp2f1 is much better now than it used to be :) Using recurrence relations to reduce magnitude of |a|, |b| >> |c| turns out to significantly improve numerical stability.]
    hyp2f1 returns wrong results for a, b large negative integers: >>> mpmath.hyp2f1(10, -900, 10.5, 0.99) mpf('-7.4446255129772491e-22') >>> scipy.special.hyp2f1(10, -900, 10.5, 0.99) 1.9185370579660795e-24 1.9185370579660766480e-24 # from Mathematica >>> mpmath.hyp2f1(10, -900.000001, 10.5, 0.99) mpf('1.9185370367664393e-24') [Yes, SVN Scipy's hyp2f1 is much better now than it used to be :) Using recurrence relations to reduce magnitude of |a|, |b| >> |c| turns out to significantly improve numerical stability.]
  • Nov 10, 2009
    issue 164 ([PATCH] Support for custom axes in visualization module) commented on by jorn.baayen   -   Great! I suppose we could test whether passing custom Axes works by checking whether the axis labels get set, for example. I attach a file doing this.
    Great! I suppose we could test whether passing custom Axes works by checking whether the axis labels get set, for example. I attach a file doing this.
  • Nov 09, 2009
    issue 164 ([PATCH] Support for custom axes in visualization module) commented on by fredrik.johansson   -   Very nice! The patch looks fine. I haven't run it yet (can't do it right now), but will commit as soon as possible, unless I discover a problem. Any way this can be tested? I know that the current code isn't tested, but this would be a nice opportunity to add some unit tests.
    Very nice! The patch looks fine. I haven't run it yet (can't do it right now), but will commit as soon as possible, unless I discover a problem. Any way this can be tested? I know that the current code isn't tested, but this would be a nice opportunity to add some unit tests.
  • Nov 07, 2009
    issue 158 (nstr should pass kwargs to low-level conversion methods) commented on by Vinzent.Steinberg   -   To reproduce, run: >>> import sys >>> sys.setrecursionlimit(100) >>> from mpmath import randmatrix >>> from mpmath.linalg import exp_pade >>> exp_pade(randmatrix(2))
    To reproduce, run: >>> import sys >>> sys.setrecursionlimit(100) >>> from mpmath import randmatrix >>> from mpmath.linalg import exp_pade >>> exp_pade(randmatrix(2))
  • Nov 07, 2009
    issue 158 (nstr should pass kwargs to low-level conversion methods) commented on by Vinzent.Steinberg   -   The error occurs in test_exp_pade, I managed to recover the stacktrace: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "mpmath/__init__.py", line 96, in runtests tests.testit(importdir, testdir) File "mpmath/tests/runtests.py", line 118, in testit module.__dict__[f]() File "/home/one/src/mpmath/mpmath/tests/test_linalg.py", line 226, in test_exp_pade e1 = exp_pade(a1) File "mpmath/linalg.py", line 521, in exp_pade cx = c*x File "<string>", line 28, in __mul__ File "<string>", line 28, in __mul__ [...] File "<string>", line 28, in __mul__ File "mpmath/mptypes.py", line 377, in convert return matrix(x) File "mpmath/matrices.py", line 324, in __init__ A = args[0].copy() File "mpmath/matrices.py", line 584, in copy new = matrix(self.__rows, self.__cols, force_type=self.force_type) File "mpmath/matrices.py", line 299, in __init__ if isinstance(args[0], (list, tuple)): RuntimeError: maximum recursion depth exceeded while calling a Python object This is quite strange, how can a commit related to nstr() affect matrix multiplication?
    The error occurs in test_exp_pade, I managed to recover the stacktrace: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "mpmath/__init__.py", line 96, in runtests tests.testit(importdir, testdir) File "mpmath/tests/runtests.py", line 118, in testit module.__dict__[f]() File "/home/one/src/mpmath/mpmath/tests/test_linalg.py", line 226, in test_exp_pade e1 = exp_pade(a1) File "mpmath/linalg.py", line 521, in exp_pade cx = c*x File "<string>", line 28, in __mul__ File "<string>", line 28, in __mul__ [...] File "<string>", line 28, in __mul__ File "mpmath/mptypes.py", line 377, in convert return matrix(x) File "mpmath/matrices.py", line 324, in __init__ A = args[0].copy() File "mpmath/matrices.py", line 584, in copy new = matrix(self.__rows, self.__cols, force_type=self.force_type) File "mpmath/matrices.py", line 299, in __init__ if isinstance(args[0], (list, tuple)): RuntimeError: maximum recursion depth exceeded while calling a Python object This is quite strange, how can a commit related to nstr() affect matrix multiplication?
  • Nov 07, 2009
    issue 164 ([PATCH] Support for custom axes in visualization module) reported by jorn.baayen   -   This patch makes it possible to use the visualization module with Reinteract [1]: > axes = replot.Axes() > plot(lambda x: exp(x)*li(x), [1, 4], axes=axes) > axes will cause the plot to be displayed inline. [1] http://reinteract.org
    This patch makes it possible to use the visualization module with Reinteract [1]: > axes = replot.Axes() > plot(lambda x: exp(x)*li(x), [1, 4], axes=axes) > axes will cause the plot to be displayed inline. [1] http://reinteract.org
  • Nov 06, 2009
    r994 (give li() an option to calculate the offset logarithmic inte...) committed by fredrik.johansson   -   give li() an option to calculate the offset logarithmic integral
    give li() an option to calculate the offset logarithmic integral
  • Nov 06, 2009
    r993 (don't cache more than MAX_LOG_INT_CACHE integer logarithms) committed by fredrik.johansson   -   don't cache more than MAX_LOG_INT_CACHE integer logarithms
    don't cache more than MAX_LOG_INT_CACHE integer logarithms
  • Nov 06, 2009
    r992 (Fix wrong generated branch for a small set of complex inputs...) committed by fredrik.johansson   -   Fix wrong generated branch for a small set of complex inputs to the Lambert W function
    Fix wrong generated branch for a small set of complex inputs to the Lambert W function
  • Nov 05, 2009
    issue 163 (cplot does not scale real or imaginary axis) commented on by Vinzent.Steinberg   -   What about just forwarding all **kwargs of cplot()? Or does matplotlib complain about invalid keyword arguments?
    What about just forwarding all **kwargs of cplot()? Or does matplotlib complain about invalid keyword arguments?
  • Nov 05, 2009
    issue 160 (Possible rounding bug in addition) Status changed by Vinzent.Steinberg   -   Fixed in r991.
    Status: Fixed
    Fixed in r991.
    Status: Fixed
  • Nov 04, 2009
    issue 163 (cplot does not scale real or imaginary axis) commented on by fredrik.johansson   -   I've run into this problem too, but I also find the current behavior nice in some situations. Perhaps add kwargs forwarding, so you can do for example cplot(..., imshow_kwargs={'aspect':'auto'})?
    I've run into this problem too, but I also find the current behavior nice in some situations. Perhaps add kwargs forwarding, so you can do for example cplot(..., imshow_kwargs={'aspect':'auto'})?
  • Nov 03, 2009
    issue 163 (cplot does not scale real or imaginary axis) commented on by jeidsath   -   A fix would be to add "aspect='auto'" to the imshow line in visualization.py: pylab.imshow(w, aspect='auto', extent=(rea, reb, ima, imb), origin='lower')
    A fix would be to add "aspect='auto'" to the imshow line in visualization.py: pylab.imshow(w, aspect='auto', extent=(rea, reb, ima, imb), origin='lower')
  • Nov 03, 2009
    issue 163 (cplot does not scale real or imaginary axis) reported by jeidsath   -   1. from mpmath import * 2. cplot(zeta, [0, 1], [0, 50]) I expected to see the real axis scaled to create a square image (as "plot" does with the x- and y- axis). Instead I get a tiny rectangular sliver for the graph (png attached). I'm using mpmath 0.13 on 64-bit Fedora 11. Python 2.6 (r26:66714, Jun 8 2009, 16:07:29).
    1. from mpmath import * 2. cplot(zeta, [0, 1], [0, 50]) I expected to see the real axis scaled to create a square image (as "plot" does with the x- and y- axis). Instead I get a tiny rectangular sliver for the graph (png attached). I'm using mpmath 0.13 on 64-bit Fedora 11. Python 2.6 (r26:66714, Jun 8 2009, 16:07:29).
  • Nov 02, 2009
    r991 (Fix addition rounding bug (issue 160) ) committed by fredrik.johansson   -   Fix addition rounding bug ( issue 160 )
    Fix addition rounding bug ( issue 160 )
  • Nov 02, 2009
    r990 (some misc changes; added an experimental zetasum function ) committed by fredrik.johansson   -   some misc changes; added an experimental zetasum function
    some misc changes; added an experimental zetasum function
  • Oct 30, 2009
    issue 162 (doc are not correctly generated) commented on by fredrik.johansson   -   Good idea. Would also make it easier to add more graphical examples to the docs.
    Good idea. Would also make it easier to add more graphical examples to the docs.
  • Oct 29, 2009
    issue 162 (doc are not correctly generated) commented on by Vinzent.Steinberg   -   What about a seperate tar ball for the images?
    What about a seperate tar ball for the images?
  • Oct 19, 2009
    issue 162 (doc are not correctly generated) commented on by fredrik.johansson   -   There is a problem with that; they would significantly increase the file size. Perhaps I can make them smaller.
    There is a problem with that; they would significantly increase the file size. Perhaps I can make them smaller.
  • Oct 19, 2009
    issue 162 (doc are not correctly generated) commented on by toms...@fedoraproject.org   -   Could you add them in the next release?
    Could you add them in the next release?
  • Oct 19, 2009
    issue 162 (doc are not correctly generated) commented on by toms...@fedoraproject.org   -   That's good. This means both images don't need to be generated in the build, they are missing in the tar.gz. So no problem why building :)
    That's good. This means both images don't need to be generated in the build, they are missing in the tar.gz. So no problem why building :)
  • Oct 19, 2009
    issue 162 (doc are not correctly generated) commented on by fredrik.johansson   -   I think the source images are not included in the release tar.gz, but they are available in an svn checkout. If you are making a package for Fedora, you may want to add them.
    I think the source images are not included in the release tar.gz, but they are available in an svn checkout. If you are making a package for Fedora, you may want to add them.
  • Oct 18, 2009
    issue 162 (doc are not correctly generated) reported by toms...@fedoraproject.org   -   What steps will reproduce the problem? 1. cd doc 2. ./build.py 3. warning:image file not readable: plot.png and cplot.png What is the expected output? What do you see instead? plot.png and cplot.png should be there. What version of the product are you using? On what operating system? version 0.13, Fedora 64-bit see bug: https://bugzilla.redhat.com/show_bug.cgi?id=525192 It would be nice to hear, if this fails only for fedora people (atm at least 3) or if this is a generell issue… Thomas
    What steps will reproduce the problem? 1. cd doc 2. ./build.py 3. warning:image file not readable: plot.png and cplot.png What is the expected output? What do you see instead? plot.png and cplot.png should be there. What version of the product are you using? On what operating system? version 0.13, Fedora 64-bit see bug: https://bugzilla.redhat.com/show_bug.cgi?id=525192 It would be nice to hear, if this fails only for fedora people (atm at least 3) or if this is a generell issue… Thomas
  • Oct 18, 2009
    issue 161 (Wrong result when integrating (weighed) Chebyshev polynomial...) commented on by fredrik.johansson   -   Well the following works, so it rather seems to be an issue with evalf returning +inf close to the singularity at -1 even when it shouldn't: >>> from mpmath import * >>> n = 3 >>> f = lambda x: diff(asin, x) * (x**2+x-2)*chebyt(3,x) >>> mp.dps = 100 >>> quad(f, [-1,1]) mpf('-2.059865464227744827411977669273198632525765165715921865963072495169589619204642003714978954969971380444e-53') It's inaccurate due to the singularity which is of type 1/sqrt(x). About half the precision is lost due to the amplification of the uncertainty in the quadrature nodes. The following simpler examples also demonstrate this: >>> mp.dps = 10; 2-quad(lambda x: 1/sqrt(x), [0,1]) mpf('1.201842678711e-7') >>> mp.dps = 20; 2-quad(lambda x: 1/sqrt(x), [0,1]) mpf('1.2219366736851552598941e-12') >>> mp.dps = 30; 2-quad(lambda x: 1/sqrt(x), [0,1]) mpf('1.41170839398550092442887420002314e-17') >>> mp.dps = 40; 2-quad(lambda x: 1/sqrt(x), [0,1]) mpf('1.402406641150261557057869824475216789991847e-22') A simple workaround is to just do the integrations at twice the precision. This problem would be possible to solve more elegantly in mpmath, either by always computing nodes to double precision (which would be somewhat wasteful) or adding an option to quad to handle this type of singularity better.
    Well the following works, so it rather seems to be an issue with evalf returning +inf close to the singularity at -1 even when it shouldn't: >>> from mpmath import * >>> n = 3 >>> f = lambda x: diff(asin, x) * (x**2+x-2)*chebyt(3,x) >>> mp.dps = 100 >>> quad(f, [-1,1]) mpf('-2.059865464227744827411977669273198632525765165715921865963072495169589619204642003714978954969971380444e-53') It's inaccurate due to the singularity which is of type 1/sqrt(x). About half the precision is lost due to the amplification of the uncertainty in the quadrature nodes. The following simpler examples also demonstrate this: >>> mp.dps = 10; 2-quad(lambda x: 1/sqrt(x), [0,1]) mpf('1.201842678711e-7') >>> mp.dps = 20; 2-quad(lambda x: 1/sqrt(x), [0,1]) mpf('1.2219366736851552598941e-12') >>> mp.dps = 30; 2-quad(lambda x: 1/sqrt(x), [0,1]) mpf('1.41170839398550092442887420002314e-17') >>> mp.dps = 40; 2-quad(lambda x: 1/sqrt(x), [0,1]) mpf('1.402406641150261557057869824475216789991847e-22') A simple workaround is to just do the integrations at twice the precision. This problem would be possible to solve more elegantly in mpmath, either by always computing nodes to double precision (which would be somewhat wasteful) or adding an option to quad to handle this type of singularity better.
  • Oct 18, 2009
    issue 161 (Wrong result when integrating (weighed) Chebyshev polynomial...) reported by jorn.baayen   -   I'm logging this here as this seems to be a mpmath problem. The polynomial 'f' defined below is of order 2, and so it does not contain the 3rd Chebyshev polynomial of the first kind: taking the scalar product (integrating with the weight function 1/sqrt(1-x**2)) should return 0. Sympy gets this right symbolically, but when integrating using quadts the result depends on the given precision. For high levels of precision quadts returns +inf, which is completely off. Some test code to illustrate this behaviour: >>> from sympy.interactive import * >>> from sympy import mpmath >>> f = x**2 + x - 2 >>> weight = diff(asin(x), x) >>> def integrand(n, func): ... return weight * func * chebyshevt(n, x) >>> mpmath.mp.dps = 100 >>> mpmath.quadts(lambda t : integrand(3, f).subs(x, t).evalf(), [-1, 1]) mpf('+inf') >>> mpmath.mp.dps = 10 >>> mpmath.quadts(lambda t : integrand(3, f).subs(x, t).evalf(), [-1, 1]) mpf('-1.781695653964e-7') >>> integrate(integrand(3, f), (x, -1, 1)) 0
    I'm logging this here as this seems to be a mpmath problem. The polynomial 'f' defined below is of order 2, and so it does not contain the 3rd Chebyshev polynomial of the first kind: taking the scalar product (integrating with the weight function 1/sqrt(1-x**2)) should return 0. Sympy gets this right symbolically, but when integrating using quadts the result depends on the given precision. For high levels of precision quadts returns +inf, which is completely off. Some test code to illustrate this behaviour: >>> from sympy.interactive import * >>> from sympy import mpmath >>> f = x**2 + x - 2 >>> weight = diff(asin(x), x) >>> def integrand(n, func): ... return weight * func * chebyshevt(n, x) >>> mpmath.mp.dps = 100 >>> mpmath.quadts(lambda t : integrand(3, f).subs(x, t).evalf(), [-1, 1]) mpf('+inf') >>> mpmath.mp.dps = 10 >>> mpmath.quadts(lambda t : integrand(3, f).subs(x, t).evalf(), [-1, 1]) mpf('-1.781695653964e-7') >>> integrate(integrand(3, f), (x, -1, 1)) 0
  • Oct 10, 2009
    issue 160 (Possible rounding bug in addition) commented on by casevh   -   That fixes the issue. I'll extend the test programs I'm writing for the _mpmath_ routines to also test a large number of random values. I will be testing add, mult, div, and sqrt.
    That fixes the issue. I'll extend the test programs I'm writing for the _mpmath_ routines to also test a large number of random values. I will be testing add, mult, div, and sqrt.
  • Oct 10, 2009
    issue 160 (Possible rounding bug in addition) commented on by fredrik.johansson   -   In the code if tsign: sman -= 1 else: sman += 1 if ssign: tman -= 1 else: tman += 1 i think it should check if ssign != tsign. It would be nice to have a test function that automatically tries a lot of random arguments with all rounding modes and programmatically verifies the rounding; it would probably have revealed this a long time ago.
    In the code if tsign: sman -= 1 else: sman += 1 if ssign: tman -= 1 else: tman += 1 i think it should check if ssign != tsign. It would be nice to have a test function that automatically tries a lot of random arguments with all rounding modes and programmatically verifies the rounding; it would probably have revealed this a long time ago.
 
Hosted by Google Code