[Numpy-discussion] Handling warnings when solving nearly-singular matrices
Hey folks, The mathematicians over at Walking Randomly have expressed some dissatisfaction with the lack of warnings when solving nearly-singular matrices: http://www.walkingrandomly.com/?p=5092 An issue has been raised here: https://github.com/numpy/numpy/issues/3755 The Julia developers are also discussing this here: https://github.com/JuliaLang/julia/issues/4286 I don't have the cycles to submit a patch immediately, but I can come up with something this weekend if somebody doesn't want to work on this sooner. Cheers, Aron ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Binary releases
On Mon, Sep 16, 2013 at 10:05 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Sep 16, 2013 at 8:15 PM, Peter Cock p.j.a.c...@googlemail.com wrote: On Mon, Sep 16, 2013 at 8:05 PM, Nathaniel Smith n...@pobox.com wrote: Why not just release numpy 1.8 with the old and terrible system? As you know I'm 110% in favor of getting rid of it, but 1.8 is ready to go and 1.9 is coming soon enough, and the old and terrible system does work right now, today. None of the other options have this property. The above makes a lot of sense, so I decided to check that it actually does work. Unsurprisingly, it needs fixing: https://github.com/numpy/numpy/issues/3760 Ralf On the down side, the old and terrible system does not cover providing pre-built binaries for 64 bit Windows. Doing that right is important not just for SciPy but for any other downstream package including C code compiled against the NumPy C API (and the people doing this probably will only have access to free compilers). That's not a downside -- that's the situation right now and will continue to be the situation for the immediate future, if we cut a 1.8rc1 tomorrow and also if we don't cut a 1.8rc1 tomorrow. Again, I'm absolutely behind getting this sorted out, but holding up the release on all platforms is not going to make win64 standalone binaries appear any faster, and in the mean time everyone seems to be getting along OK, either because they're using a distribution, are on another platform, or taking advantage of Cristoph's generosity (thank you Cristoph!). Worst case, if it all gets sorted out next week we could release an 1.8.1 to celebrate... -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Using setuptools develop mode with numpy distutils
Hi, I need to use numpy's distutils Extension to build a fortran / f2py extension. But I also really like setuptools' develop mode. However, if I do: from numpy.distutils.core import Extension and use that to define my Extension object, but use: from setuptools import setup And use that for the main setup, I get: error: each element of 'ext_modules' option must be an Extension instance or 2-tuple So apparently setuptools doesn't recognize numpy's Extension object as an Extension object. Is there a way around this? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] multiprocessing, numpy and 32-64 bit cohabitation
Hi all, While I realize that this is certainly tweaking multiprocessing beyond its specifications, I would like to use it on Windows to start a 32-bit Python process from a 64-bit Python process (use case: I need to interface with a 64-bit DLL and use an extension (pyFFTW) for which I can only find a 32-bit compiled version (yes, I could try to install MSVC and compile it myself but I'm trying to avoid that...)) In fact, this is easy to do by using multiprocessing.set_executable (...while that may not be its original role): import multiprocessing as mp import imp, site, sys if 32 in sys.executable: # checking for my 32-bit Python install del sys.path[1:] # recompute sys.path print(sys.path) site.main() print(sys.path) # now points to the 32bit site-packages import numpy if __name__ == '__main__': mp.set_executable(sys.executable.replace(33, 33-32)) # path of my 32-bit Python install mp.Process(target=lambda: None).start() The sys.path modifications are needed as otherwise the child process inherits the parent's sys.path and importing numpy (from the 64-bit path) fails as it is not a valid Win32 application, complains Python (rightly). However, even after the sys.path modifications, the numpy import fails with the error message (that I had never seen before): sorry, I can't copy paste from the Windows command prompt... from . import multiarray # - numpy/core/__init__.py, line 5 SystemError: initialization of multiarray raised an unreported exception Any hints as to how this could be fixed would be most welcome. Thanks in advance, Antony ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
