Mailman 3 September 2013 - SciPy-Dev

ANN: 1.8.0b2 release.
by Charles R Harris Sept. 14, 2013

Sept. 14, 2013

Hi all, I'm happy to announce the second beta release of Numpy 1.8.0. This release should solve the Windows problems encountered in the first beta. Many thanks to Christolph Gohlke and Julian Taylor for their hard work in getting those issues settled. It would be good if folks running OS X could try out this release and report any issues on the numpy-dev mailing list. Unfortunately the files still need to be installed from source as dmg files are not avalable at this time. Source tarballs and release notes can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.8.0b2/. The Windows and OS X installers will follow when the infrastructure issues are dealt with. Chuck

2 1

reported error for numpy 1.8
by Charles R Harris Sept. 13, 2013

Sept. 13, 2013

Hi all, I don't know if this is known or not, so posting here before opening an issue. This shows up in scipy master as well as 0.12, along with a ton of (expected) deprecation warnings for the latter. Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/charris/.local/lib/python2.7/site-packages/scipy/io/matlab/tests/test_mio.py", line 301, in _load_check_case matdict = loadmat(file_name, struct_as_record=True) File "/home/charris/.local/lib/python2.7/site-packages/scipy/io/matlab/mio.py", line 126, in loadmat matfile_dict = MR.get_variables(variable_names) File "/home/charris/.local/lib/python2.7/site-packages/scipy/io/matlab/mio5.py", line 288, in get_variables res = self.read_var_array(hdr, process) File "/home/charris/.local/lib/python2.7/site-packages/scipy/io/matlab/mio5.py", line 248, in read_var_array return self._matrix_reader.array_from_header(header, process) File "mio5_utils.pyx", line 616, in scipy.io.matlab.mio5_utils.VarReader5.array_from_header (scipy/io/matlab/mio5_utils.c:5889) File "mio5_utils.pyx", line 657, in scipy.io.matlab.mio5_utils.VarReader5.array_from_header (scipy/io/matlab/mio5_utils.c:5446) File "mio5_utils.pyx", line 814, in scipy.io.matlab.mio5_utils.VarReader5.read_char (scipy/io/matlab/mio5_utils.c:7270) TypeError: buffer is too small for requested array Chuck

1 0

tol parameter to minimize_scalar is inconsistent [without HTML this time]
by Micky Latowicki Sept. 13, 2013

Sept. 13, 2013

[sorry for the HTML in the first try] Hi, I'm a longtime user of scipy and greatly appreciate your work. I'd like to ask/suggest something about minimize_scalar. It seems to me that the tol parameter is relative tolerance when the method is 'brent' and absolute tolerance when the method is 'bounded'. Isn't this confusing? Perhaps this parameter should be deprecated, until both methods can support either relative or absolute tolerance? Meanwhile, parameters with names such as 'abs_xtol' and 'rel_xtol' can be introduced, and invalid combinations of parameters and method would be rejected with a ValueError? Cheers. This mail was sent via Mail-SeCure system. ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************

4 3

recent scipy.stats work
by josef.pktd＠gmail.com Sept. 12, 2013

Sept. 12, 2013

Evgeni (mainly) has been busy to improve stats.distributions stats.distributions is on the way to losing it's remaining bugs in higher moments and entropy. :( and is getting a reliable test suite for them. Here is a, maybe incomplete, list to see if we want to backport any of them to 0.13 https://github.com/scipy/scipy/pull/2801 fix beta_gen.fit (Warren) https://github.com/scipy/scipy/pull/2845 open, numerical improvemnt (but also vonmises_line) https://github.com/scipy/scipy/pull/2774 open, bugfix for entropy docs https://github.com/scipy/scipy/pull/2814 not bugfix https://github.com/scipy/scipy/pull/2822 speed improvement https://github.com/scipy/scipy/pull/2841 numerical improvements not ready https://github.com/scipy/scipy/pull/2821 fixing moments https://github.com/scipy/scipy/pull/2790 Josef

2 1

tol parameter to minimize_scalar is inconsistent
by Micky Latowicki Sept. 11, 2013

Sept. 11, 2013

1 0

Akima Interpolation
by Andreas Hilboll Sept. 10, 2013

Sept. 10, 2013

I'd like to have Akima interpolation in scipy.interpolate, as I couldn't find any. 1.) Did I miss something and there actually *is* an Akima interpolation in scipy? 2.) Is there interest in having Akima interpolation in Scipy? 3.) Does anyone have a good recommendation which implementation I should consider for pulling into Scipy? -- Andreas.

7 8

Consensus on the future of integrate.ode
by boyfarrell＠gmail.com Sept. 10, 2013

Sept. 10, 2013

Dear list, I think it would be interesting to start a discussion regarding the direction of integrate.ode. Reading the list, there seems to be many people interested seeing improvements. Is there a roadmap for development? If not can we come to a consensus about how best to contribute to this part of scipy? I think it is fair to say that other projects have overtaken scipy in terms integrating new solvers and general development in this area. Which is a shame. Personally, speaking as a user, I would like to see the use of more modern solvers. For example the code could be updated to use CVODE. This has many improvements/fixes over the Fortran VODE solver that is currently used. This would be a nice place to start, clearly that is still a nontrivial task. Also, is there a way that developers could be encourage to contribute additional solvers? For example by making an elegant low level API that makes this easier. Moreover, say that in order for a developer to connect a new solver to scipy all that had to be done was implement a particular, well defined, interface for their wrapper. Once implemented the new solver could be called with the exciting integrate.ode interface. Has anybody got experience is such design? Surely something like this has been attempted? The GNU Scientific Library interface springs to mind as a good example, http://www.gnu.org/software/gsl/manual/html_node/Ordinary-Differential-Equa… Finally, I have read some discussion here regarding changing the API and or unifying the odeint and ode. I don't want to get too distracted with this as my main point is outlined above. Personally the current API doesn't bother me too much, I find both easy to use. But if this is being considered for an update I think the crucial thing is to have the interface have no reliance on any particular solver. Abstraction is key. Happy to know your thoughts and if we can make a push together for some improvements in this area then all the better. Best regard, Dan

7 16

Fwd: [Numpy-discussion] ANN: 1.8.0b2 release.
by Daπid Sept. 8, 2013

Sept. 8, 2013

On 8 September 2013 21:14, Charles R Harris <charlesr.harris(a)gmail.com>wrote: > It would be good if folks running OS X could try out this release and > report any issues on the numpy-dev mailing list. Unfortunately the files > still need to be installed from source as dmg files are not avalable at > this time. > Hi, I have tried on a intel Mac with Python2.7 and gcc installed with Macports and it builds fine. The FORTRAN compiler is gfortran. There are a bunch of compiling warnings and errors* (attachment log27.log), but it works fine. Running the tests it gets printed: .......Parameter 4 to routine DGETRF was incorrect....... but all of them pass. I did not specify which BLAS to use, and it choose Accelerate, but ATLAS is also installed. >>> numpy.show_config() atlas_threads_info: NOT AVAILABLE blas_opt_info: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] extra_compile_args = ['-msse3', '-I/System/Library/Frameworks/vecLib.framework/Headers'] define_macros = [('NO_ATLAS_INFO', 3)] atlas_blas_threads_info: NOT AVAILABLE openblas_info: NOT AVAILABLE lapack_opt_info: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] extra_compile_args = ['-msse3'] define_macros = [('NO_ATLAS_INFO', 3)] Running SciPy (from Macports) test does raise two errors and a bunch of Deprecation warnings. See attachment scipy.log. The first two warnings were present before upgrading NumPy, but not the rest. Let me know if you need me to run it again, or change the configuration in any way. Regards, David. ------- * Errors such as: _configtest.c:1:20: error: endian.h: No such file or directory _configtest.c:5: error: size of array ‘test_array’ is negative _configtest.c:7: error: ‘Py_UNICODE_WIDE’ undeclared (first use in this function)

2 2

Consensus on the future of integrate.ode
by Mario Mulansky Sept. 5, 2013

Sept. 5, 2013

> Please, please don't implement anything in the SciPy ODE solvers with Boost. > odeint unless it's a separate interface that requires extreme generality. > > Boost.odeint uses Boost.uBLAS for its linear algebra (see > http://headmyshoulder.github.io/odeint-v2/doc/boost_numeric_odeint/concepts/ > implicit_system.html), and Boost.uBLAS is slow because it tries to be > general (everything is templated), and it has debugging features added by > default. > > A lot of users (myself included) don't need that generality, and would > prefer the extra performance that you'd get from a code that can use a > faster dense linear algebra library (like an optimized LAPACK, Eigen, > Elemental, maybe MTL4). I agree with the concerns but I would like to note that the current implementation of implicit routines in Boost.odeint is preliminary. We are currently working on a generalization of these routines to allow the usage of arbitrary backends that should be done by the end of the year. However, Boost.odeint misses some more of the functionality of CVODE, e.g. automatic detection of stiffness or numerical Jacobi approximation. But I think that using Boost.odeint could be benefitial for scipy.odeint (e.g. parallelization) and we would be happy to assist scipy developers, e.g. by providing missing functionality, if you want to use Boost.odeint. Best regards, Mario

1 0

contributing to scipy.spatial.distance
by Michael Yang Sept. 4, 2013

Sept. 4, 2013

hi - I'm new to this development list so please excuse me if I'm not doing things right (like top-posting or bottom-posting, etc.) I would like to contribute an additional vector distance function to the absolutely wonderful scipy.spatial.distance package written by Damian Eads. I have a patch for scipy/spatial/distance.py written for scipy version 0.7.1 a while back. Could someone please advise me on how to incorporate the patch? I don't know if the repo is in github or somewhere else. Also (not to be self-aggrandizing!) but would it be possible to add my name somewhere to this file if the patch gets makes it in successfully? Thanks, Michael Yang

3 2