Mailman 3 September 2012 - SciPy-Dev

tomorrow 0.11.0 final
by Ralf Gommers Sept. 23, 2012

Sept. 23, 2012

Hi all, The 0.11.0 release cycle has taken quite a bit longer than previous cycles unfortunately, but I think now the 0.11.x branch is ready. Final commit marking the test TestEig.test_singular that was failing on Windows for some people as knownfail in 0.11.x is at https://github.com/scipy/scipy/pull/323. The sort keyword to linalg.qz, which has been giving problems on several platforms, has been disabled in both master and 0.11.x. I consider the issues with arpack and single precision linalg routines on OS X 10.8 out of scope for 0.11.0. It would be great if someone who's on that OS could investigate, but it shouldn't block this release. The few changes since RC2 don't require a new RC imo, so I plan to tag the release tomorrow. If there's any commits I missed that absolutely need to be backported, please let me know. Cheers, Ralf

1 0

TestNorm.test_stable failure [was ANN: SciPy 0.11.0 release candidate 2]
by Ralf Gommers Sept. 22, 2012

Sept. 22, 2012

On Sat, Sep 8, 2012 at 9:38 PM, <josef.pktd(a)gmail.com> wrote: > > ------------------------- > If I just unzip the superpack instead of installing the sse3, I get > only one failure > > ====================================================================== > FAIL: test_basic.TestNorm.test_stable > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "E:\Josef\testing\tox\py27b\lib\site-packages\nose-1.1.2-py2.7.egg\nose\case.py", > line 197, in runTest > self.test(*self.arg) > File > "E:\Josef\testing\tox\py27b\lib\site-packages\scipy\linalg\tests\test_basic.py", > line 592, in > test_stable > assert_almost_equal(norm(a) - 1e4, 0.0, err_msg=msg) > File > "E:\Josef\testing\tox\py27b\lib\site-packages\numpy-1.6.2-py2.7-win32.egg\numpy\testing\utils.py", > line 468, in assert_almost_equal > raise AssertionError(msg) > AssertionError: > Arrays are not almost equal to 7 decimals > : Result should equal either 0.0 or 0.5 (depending on implementation of > snrm2). > ACTUAL: 0.4990234375 > DESIRED: 0.0 > > maybe some sse incompatibilities. > This one keeps on coming back. We fixed the test for allowing 0.0 or 0.5, but it can also just break like this. It does so at least for some people on OS X 10.8 and on Windows. Since the problem seems to be in ATLAS / Accelerate, should we leave it as is or not? Ralf

2 4

Re: [SciPy-Dev] [SciPy-User] ANN: SciPy 0.11.0 release candidate 2
by Ralf Gommers Sept. 22, 2012

Sept. 22, 2012

On Tue, Aug 14, 2012 at 3:35 PM, John Hassler <hasslerjc(a)comcast.net> wrote: > > On 8/14/2012 7:21 AM, Pauli Virtanen wrote: > > Ralf Gommers <ralf.gommers <at> gmail.com> writes: > > [clip] > >> Does anyone have an idea about that test_singular failure? > > That's very likely some problem with the underlying LAPACK library. > > I think the problem solved is close to a numerical instability. > > > > The failing comparison compares eigenvalues computed by > > > > eig(A, B) > > eig(A, B, left=False, right=False) > > > > which differ solely in passing 'N' vs. 'V' to DGGEV. The eigenvalue > > property of the former is also checked and seems to pass. Interestingly, > > the result obtained from the two seems to differ (therefore, the latter > > is probably wrong), which appears to point to a LAPACK issue. > > > > Here, it would be interesting to know if the problem occurs with > > the official Scipy binaries, or something else. > > > > I installed rc2 on Python 2.7.3. Same problem. I get the test_singular > error on some, but not all, of the runs. Both are win32-superpack from > http://sourceforge.net/projects/scipy/files/scipy/0.11.0rc2/. > > The error occurs on less than half but more than 1/3 (based on a very > small sample) of the runs on both 2.7 and 3.2. > > I've been working on computers for more than 50 years. Somehow, I had > developed the delusion that they were deterministic ..... > john > What are we going to do about this one? I'm tempted to open a ticket for it and mark it as knownfail on Windows for now, since it's a corner case. Ralf > ------------- Python 2.7 -------------------- > >>> import scipy > >>> scipy.test() > Running unit tests for scipy > NumPy version 1.6.2 > NumPy is installed in C:\Python27\lib\site-packages\numpy > SciPy version 0.11.0rc2 > SciPy is installed in C:\Python27\lib\site-packages\scipy > Python version 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit > (Intel)] > nose version 0.11.2 > > ====================================================================== > FAIL: test_decomp.TestEig.test_singular > Test singular pair > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "C:\Python27\lib\site-packages\nose-0.11.2-py2.7.egg\nose\case.py", line > 186, in runTest > self.test(*self.arg) > File > "C:\Python27\lib\site-packages\scipy\linalg\tests\test_decomp.py", line > 201, in test_singular > self._check_gen_eig(A, B) > File > "C:\Python27\lib\site-packages\scipy\linalg\tests\test_decomp.py", line > 188, in _check_gen_eig > err_msg=msg) > File "C:\Python27\lib\site-packages\numpy\testing\utils.py", line > 800, in assert_array_almost_equal > header=('Arrays are not almost equal to %d decimals' % decimal)) > File "C:\Python27\lib\site-packages\numpy\testing\utils.py", line > 636, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Arrays are not almost equal to 6 decimals > > array([[22, 34, 31, 31, 17], > [45, 45, 42, 19, 29], > [39, 47, 49, 26, 34], > [27, 31, 26, 21, 15], > [38, 44, 44, 24, 30]]) > array([[13, 26, 25, 17, 24], > [31, 46, 40, 26, 37], > [26, 40, 19, 25, 25], > [16, 25, 27, 14, 23], > [24, 35, 18, 21, 22]]) > (mismatch 25.0%) > x: array([ -2.45037885e-01 +0.00000000e+00j, > 5.17637463e-16 -4.01120590e-08j, > 5.17637463e-16 +4.01120590e-08j, 2.00000000e+00 > +0.00000000e+00j]) > y: array([ -3.74550285e-01 +0.00000000e+00j, > -5.17716907e-17 -1.15230800e-08j, > -5.17716907e-17 +1.15230800e-08j, 2.00000000e+00 > +0.00000000e+00j]) > > ---------------------------------------------------------------------- > Ran 5490 tests in 103.250s > > FAILED (KNOWNFAIL=14, SKIP=36, failures=1) > <nose.result.TextTestResult run=5490 errors=0 failures=1> > >>> > > -------------- Python 3.2 -------------- > >>> scipy.test() > Running unit tests for scipy > NumPy version 1.6.2 > NumPy is installed in C:\Python32\lib\site-packages\numpy > SciPy version 0.11.0rc2 > SciPy is installed in C:\Python32\lib\site-packages\scipy > Python version 3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit > (Intel)] > nose version 1.0.0 > > ====================================================================== > FAIL: test_decomp.TestEig.test_singular > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "C:\Python32\lib\site-packages\nose-1.0.0-py3.2.egg\nose\case.py", line > 188, in runTest > self.test(*self.arg) > File > "C:\Python32\lib\site-packages\scipy\linalg\tests\test_decomp.py", line > 201, in test_singular > self._check_gen_eig(A, B) > File > "C:\Python32\lib\site-packages\scipy\linalg\tests\test_decomp.py", line > 188, in _check_gen_eig > err_msg=msg) > File "C:\Python32\lib\site-packages\numpy\testing\utils.py", line > 800, in assert_array_almost_equal > header=('Arrays are not almost equal to %d decimals' % decimal)) > File "C:\Python32\lib\site-packages\numpy\testing\utils.py", line > 636, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Arrays are not almost equal to 6 decimals > > array([[22, 34, 31, 31, 17], > [45, 45, 42, 19, 29], > [39, 47, 49, 26, 34], > [27, 31, 26, 21, 15], > [38, 44, 44, 24, 30]]) > array([[13, 26, 25, 17, 24], > [31, 46, 40, 26, 37], > [26, 40, 19, 25, 25], > [16, 25, 27, 14, 23], > [24, 35, 18, 21, 22]]) > (mismatch 25.0%) > x: array([ -2.450e-01 +0.000e+00j, 5.176e-16 -4.011e-08j, 5.176e-16 > +4.011e-08j, > 2.000e+00 +0.000e+00j]) > y: array([ -3.746e-01 +0.000e+00j, -5.177e-17 -1.152e-08j, -5.177e-17 > +1.152e-08j, > 2.000e+00 +0.000e+00j]) > >

3 4

ANN: SciPy 0.11.0 release candidate 2
by Ralf Gommers Sept. 22, 2012

Sept. 22, 2012

Hi, I am pleased to announce the availability of the second release candidate of SciPy 0.11.0. For this release many new features have been added, and over 120 tickets and pull requests have been closed. Also noteworthy is that the number of contributors for this release has risen to over 50. Some of the highlights are: - A new module, sparse.csgraph, has been added which provides a number of common sparse graph algorithms. - New unified interfaces to the existing optimization and root finding functions have been added. Sources and binaries can be found at http://sourceforge.net/projects/scipy/files/scipy/0.11.0rc2/, release notes are copied below. For this release candidate all known issues (with the exception of one Qhull issue on Debian, s390x platform) have been solved. In the meantime also OS X 10.8 was released, this RC contains a few build fixes for that platform. If no more serious issues are reported, the final release will be in one week. Cheers, Ralf ========================== SciPy 0.11.0 Release Notes ========================== .. note:: Scipy 0.11.0 is not released yet! .. contents:: SciPy 0.11.0 is the culmination of 8 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. Highlights of this release are: - A new module has been added which provides a number of common sparse graph algorithms. - New unified interfaces to the existing optimization and root finding functions have been added. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Our development attention will now shift to bug-fix releases on the 0.11.x branch, and on adding new features on the master branch. This release requires Python 2.4-2.7 or 3.1-3.2 and NumPy 1.5.1 or greater. New features ============ Sparse Graph Submodule ---------------------- The new submodule :mod:`scipy.sparse.csgraph` implements a number of efficient graph algorithms for graphs stored as sparse adjacency matrices. Available routines are: - :func:`connected_components` - determine connected components of a graph - :func:`laplacian` - compute the laplacian of a graph - :func:`shortest_path` - compute the shortest path between points on a positive graph - :func:`dijkstra` - use Dijkstra's algorithm for shortest path - :func:`floyd_warshall` - use the Floyd-Warshall algorithm for shortest path - :func:`breadth_first_order` - compute a breadth-first order of nodes - :func:`depth_first_order` - compute a depth-first order of nodes - :func:`breadth_first_tree` - construct the breadth-first tree from a given node - :func:`depth_first_tree` - construct a depth-first tree from a given node - :func:`minimum_spanning_tree` - construct the minimum spanning tree of a graph ``scipy.optimize`` improvements ------------------------------- The optimize module has received a lot of attention this release. In addition to added tests, documentation improvements, bug fixes and code clean-up, the following improvements were made: - A unified interface to minimizers of univariate and multivariate functions has been added. - A unified interface to root finding algorithms for multivariate functions has been added. - The L-BFGS-B algorithm has been updated to version 3.0. Unified interfaces to minimizers ```````````````````````````````` Two new functions ``scipy.optimize.minimize`` and ``scipy.optimize.minimize_scalar`` were added to provide a common interface to minimizers of multivariate and univariate functions respectively. For multivariate functions, ``scipy.optimize.minimize`` provides an interface to methods for unconstrained optimization (`fmin`, `fmin_powell`, `fmin_cg`, `fmin_ncg`, `fmin_bfgs` and `anneal`) or constrained optimization (`fmin_l_bfgs_b`, `fmin_tnc`, `fmin_cobyla` and `fmin_slsqp`). For univariate functions, ``scipy.optimize.minimize_scalar`` provides an interface to methods for unconstrained and bounded optimization (`brent`, `golden`, `fminbound`). This allows for easier comparing and switching between solvers. Unified interface to root finding algorithms ```````````````````````````````````````````` The new function ``scipy.optimize.root`` provides a common interface to root finding algorithms for multivariate functions, embeding `fsolve`, `leastsq` and `nonlin` solvers. ``scipy.linalg`` improvements ----------------------------- New matrix equation solvers ``````````````````````````` Solvers for the Sylvester equation (``scipy.linalg.solve_sylvester``, discrete and continuous Lyapunov equations (``scipy.linalg.solve_lyapunov``, ``scipy.linalg.solve_discrete_lyapunov``) and discrete and continuous algebraic Riccati equations (``scipy.linalg.solve_continuous_are``, ``scipy.linalg.solve_discrete_are``) have been added to ``scipy.linalg``. These solvers are often used in the field of linear control theory. QZ and QR Decomposition ```````````````````````` It is now possible to calculate the QZ, or Generalized Schur, decomposition using ``scipy.linalg.qz``. This function wraps the LAPACK routines sgges, dgges, cgges, and zgges. The function ``scipy.linalg.qr_multiply``, which allows efficient computation of the matrix product of Q (from a QR decompostion) and a vector, has been added. Pascal matrices ``````````````` A function for creating Pascal matrices, ``scipy.linalg.pascal``, was added. Sparse matrix construction and operations ----------------------------------------- Two new functions, ``scipy.sparse.diags`` and ``scipy.sparse.block_diag``, were added to easily construct diagonal and block-diagonal sparse matrices respectively. ``scipy.sparse.csc_matrix`` and ``csr_matrix`` now support the operations ``sin``, ``tan``, ``arcsin``, ``arctan``, ``sinh``, ``tanh``, ``arcsinh``, ``arctanh``, ``rint``, ``sign``, ``expm1``, ``log1p``, ``deg2rad``, ``rad2deg``, ``floor``, ``ceil`` and ``trunc``. Previously, these operations had to be performed by operating on the matrices' ``data`` attribute. LSMR iterative solver --------------------- LSMR, an iterative method for solving (sparse) linear and linear least-squares systems, was added as ``scipy.sparse.linalg.lsmr``. Discrete Sine Transform ----------------------- Bindings for the discrete sine transform functions have been added to ``scipy.fftpack``. ``scipy.interpolate`` improvements ---------------------------------- For interpolation in spherical coordinates, the three classes ``scipy.interpolate.SmoothSphereBivariateSpline``, ``scipy.interpolate.LSQSphereBivariateSpline``, and ``scipy.interpolate.RectSphereBivariateSpline`` have been added. Binned statistics (``scipy.stats``) ----------------------------------- The stats module has gained functions to do binned statistics, which are a generalization of histograms, in 1-D, 2-D and multiple dimensions: ``scipy.stats.binned_statistic``, ``scipy.stats.binned_statistic_2d`` and ``scipy.stats.binned_statistic_dd``. Deprecated features =================== ``scipy.sparse.cs_graph_components`` has been made a part of the sparse graph submodule, and renamed to ``scipy.sparse.csgraph.connected_components``. Calling the former routine will result in a deprecation warning. ``scipy.misc.radon`` has been deprecated. A more full-featured radon transform can be found in scikits-image. ``scipy.io.save_as_module`` has been deprecated. A better way to save multiple Numpy arrays is the ``numpy.savez`` function. The `xa` and `xb` parameters for all distributions in ``scipy.stats.distributions`` already weren't used; they have now been deprecated. Backwards incompatible changes ============================== Removal of ``scipy.maxentropy`` ------------------------------- The ``scipy.maxentropy`` module, which was deprecated in the 0.10.0 release, has been removed. Logistic regression in scikits.learn is a good and modern alternative for this functionality. Minor change in behavior of ``splev`` ------------------------------------- The spline evaluation function now behaves similarly to ``interp1d`` for size-1 arrays. Previous behavior:: >>> from scipy.interpolate import splev, splrep, interp1d >>> x = [1,2,3,4,5] >>> y = [4,5,6,7,8] >>> tck = splrep(x, y) >>> splev([1], tck) 4. >>> splev(1, tck) 4. Corrected behavior:: >>> splev([1], tck) array([ 4.]) >>> splev(1, tck) array(4.) This affects also the ``UnivariateSpline`` classes. Behavior of ``scipy.integrate.complex_ode`` ------------------------------------------- The behavior of the ``y`` attribute of ``complex_ode`` is changed. Previously, it expressed the complex-valued solution in the form:: z = ode.y[::2] + 1j * ode.y[1::2] Now, it is directly the complex-valued solution:: z = ode.y Minor change in behavior of T-tests ----------------------------------- The T-tests ``scipy.stats.ttest_ind``, ``scipy.stats.ttest_rel`` and ``scipy.stats.ttest_1samp`` have been changed so that 0 / 0 now returns NaN instead of 1. Other changes ============= The SuperLU sources in ``scipy.sparse.linalg`` have been updated to version 4.3 from upstream. The function ``scipy.signal.bode``, which calculates magnitude and phase data for a continuous-time system, has been added. The two-sample T-test ``scipy.stats.ttest_ind`` gained an option to compare samples with unequal variances, i.e. Welch's T-test. ``scipy.misc.logsumexp`` now takes an optional ``axis`` keyword argument. Authors ======= This release contains work by the following people (contributed at least one patch to this release, names in alphabetical order): * Jeff Armstrong * Chad Baker * Brandon Beacher + * behrisch + * borishim + * Matthew Brett * Lars Buitinck * Luis Pedro Coelho + * Johann Cohen-Tanugi * David Cournapeau * dougal + * Ali Ebrahim + * endolith + * Bjørn Forsman + * Robert Gantner + * Sebastian Gassner + * Christoph Gohlke * Ralf Gommers * Yaroslav Halchenko * Charles Harris * Jonathan Helmus + * Andreas Hilboll + * Marc Honnorat + * Jonathan Hunt + * Maxim Ivanov + * Thouis (Ray) Jones * Christopher Kuster + * Josh Lawrence + * Denis Laxalde + * Travis Oliphant * Joonas Paalasmaa + * Fabian Pedregosa * Josef Perktold * Gavin Price + * Jim Radford + * Andrew Schein + * Skipper Seabold * Jacob Silterra + * Scott Sinclair * Alexis Tabary + * Martin Teichmann * Matt Terry + * Nicky van Foreest + * Jacob Vanderplas * Patrick Varilly + * Pauli Virtanen * Nils Wagner + * Darryl Wally + * Stefan van der Walt * Liming Wang + * David Warde-Farley + * Warren Weckesser * Sebastian Werk + * Mike Wimmer + * Tony S Yu + A total of 55 people contributed to this release. People with a "+" by their names contributed a patch for the first time.

2 3

Re: [SciPy-Dev] Adding solvers to scipy.integrate [Was: A step toward merging odeint and ode]
by Ralf Gommers Sept. 18, 2012

Sept. 18, 2012

<moved to scipy-dev> On Tue, Aug 21, 2012 at 10:22 AM, Fabrice Silva <silva(a)lma.cnrs-mrs.fr>wrote: > Le lundi 20 août 2012 à 22:04 +0200, Ralf Gommers a écrit : > > > https://github.com/FabricioS/scipy/commit/f867f2b8133d3f6ea47d449bd760a77a7… > > > This is probably not worth the cost for existing users imho. It is a > > backwards compatibility break that doesn't really add anything except > > for some consistency (right?). > > Hi Ralf, > Ok concerning this point. > > Hi Fabrice, sorry for the slow reply. > > In addition, I have been looking to suggest additional solvers, > essentially simpler scheme, that would thus allow to easily switch > between "complex" (lsode, vode, cvode) and basic schemes (Euler, > Nicholson, etc...) > Sounds like a good idea. I think though that for each solver added there should be a gain in performance for some problems, whether that's speed, accuracy, robustness or something else. Adding a solver for educational purposes or completeness only wouldn't be all that useful. > I came across some code on the Montana Univ.'s Computer Science dpt: > http://wiki.cs.umt.edu/classes/cs477/index.php/Creating_ODE_Solver_Objects > and asked Jesse Johnson (the responsible for that class) what is the > license for that code. Here is his answer : > > Any thing that you find on those pages, you may use. However, > I'm not sure how to go about officially giving the code a > particular license. Can I add a license to the wiki, stating > that it applies to all the code therein? > > PS It is fantastic you're doing this. I've often thought that > scipy.ode could use some improvements. > > He is cc'ed of this mail, could anyone concerned about scipy license > requirements and more generally in code licensing answer him ? > Hi Jesse, thanks a lot for contributing your code. As for the licensing question, I think the best would be to either add a license at the bottom of each page, or in the code itself. Adding a page somewhere on your wiki saying "license X applies to all code in this wiki" is in principle enough, but it may be hard to find for readers. And if they can't find a license, they have to assume they can't reuse your code. As for the license itself, it would be good to be explicit ("public domain" or "BSD" for example). Disclaimer: I'm not a lawyer. Best, Ralf

1 0

Two speed/enhancement PRs
by Jacob VanderPlas Sept. 17, 2012

Sept. 17, 2012

Hello, I currently have two small open PRs which are basically ready for merge, and have been sitting inactive for a while. I'd love a few people to read-through so we can merge: https://github.com/scipy/scipy/pull/289 This PR speeds up the pseudoinverse calculation, adds a fast hermitian pseudoinverse, and adds a `return_rank` option on all pseudoinverse methods https://github.com/scipy/scipy/pull/311 This PR speeds up single-row access in CSR matrices, and allows for fast generic slicing of CSR matrix rows. Thanks! Jake

1 0

distributions.py
by nicky van foreest Sept. 16, 2012

Sept. 16, 2012

Hi, Now that I understand github (Thanks to Ralf for his explanations in Dutch) and got some simple stuff out of the way in distributions.py I would like to tackle a somewhat harder issue. The function argsreduce is, as far as I can see, too generic. I did some tests to see whether its most generic output, as described by its docstring, is actually swallowed by the callers of argsreduce, but this appears not to be the case. My motivation to simplify the code in distributions.py (and clean it up) is partly based on making it simpler to understand for myself, but also to others. The fact that github makes code browsing a much nicer experience, perhaps more people will take a look at what's under the hood. But then the code should also be accessible and clean. Are there any reasons not to pursue this path, and focus on more important problems of the stats library? Nicky

6 18

distributions.py expect
by nicky van foreest Sept. 14, 2012

Sept. 14, 2012

Hi, I am trying to implement the expect method in rv_frozen. To understand the normal working of the expect method I tried the following: from scipy.stats import geom, norm, gamma print norm.expect(loc = 3,scale =5) print gamma.expect(None, 4.5) print gamma.expect(lambda x: x, 4.5) print geom.expect(lambda x: x, 1./3) This is the result: 3.0 4.5 4.5 Traceback (most recent call last): File "expecttest.py", line 6, in <module> print geom.expect(lambda x: x, 1./3) File "/home/nicky/prog/scipy/scipy/stats/distributions.py", line 6375, in expect self._argcheck(*args) # (re)generate scalar self.a and self.b TypeError: _argcheck() argument after * must be a sequence, not float So the first examples work, but the rv_discrete example doesn't. One thing is that the _argcheck is not called in rv_continuous while it is in rv_discrete. Removing this line results in another error: 3.0 4.5 4.5 Traceback (most recent call last): File "expecttest.py", line 6, in <module> print geom.expect(lambda x: x, 1./3) File "/home/nicky/prog/scipy/scipy/stats/distributions.py", line 6394, in expect low, upp = self._ppf(0.001, *args), self._ppf(0.999, *args) TypeError: _ppf() argument after * must be a sequence, not float What would be actually the right way to call the expect method for rv_discrete? Or perhaps the other way around, should this method be changed so that my example with geom works? ---- I extended rv_frozen with this method, and this appears to work well for continuous rvs, but also fails for discrete rvs. def expect(self, *args, **kwds): args += self.args kwds.update(self.kwds) return self.dist.expect(*args, **kwds) Nicky

2 1

stats some further clean up
by nicky van foreest Sept. 13, 2012

Sept. 13, 2012

Hi, distributions.py contains some #hashed documentation from lines https://github.com/nokfi/scipy/blob/master/scipy/stats/distributions.py#L509 to https://github.com/nokfi/scipy/blob/master/scipy/stats/distributions.py#L598 I would prefer to remove it as some parts should better fit in the documentation at http://docs.scipy.org/doc/scipy/reference/tutorial/stats/continuous.html#co… while a lot is already covered in the standard doc strings of rv_continuous and rv_discrete. Should I just go ahead, or first make a somewhat more specified list of what I intend to do? nicky

2 2

continuous distributions documentation
by nicky van foreest Sept. 13, 2012

Sept. 13, 2012

Hi, I updated my git version of https://github.com/scipy/scipy/blob/master/doc/source/tutorial/stats/contin… somewhat. I converted it to latex to convert it, with pandoc, to rst. However, the result is dramatic. Does anybody know how the lyx file was converted to rst so as to get a decent result? BTW, the latex file looks ok, so the problem resides in the conversion to rst. thanks Nicky

1 1