<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 30, 2018 at 8:17 PM, Ralf Gommers <span dir="ltr"><<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Fri, Mar 30, 2018 at 12:03 PM, Eric Larson <span dir="ltr"><<a href="mailto:larson.eric.d@gmail.com" target="_blank">larson.eric.d@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Top-level module for them alone sounds overkill, and I'm not sure if discoverability alone is enough.<br></blockquote><div><br></div></span><div>Fine by me. And if we follow the idea that these should be added sparingly, we can maintain discoverability without it growing out of hand by populating the See Also sections of each function.</div></div></div></div></blockquote><div><br></div></span><div>I agree with this, the 2 images and 1 ECG signal (to be added) that we have doesn't justify a top-level module. We don't want to grow more than the absolute minimum of datasets. The package is already very large, which is problematic in certain cases. E.g. numpy + scipy still fits in the AWS Lambda limit of 50 MB, but there's not much margin.<span class="gmail-HOEnZb"><font color="#888888"><br><br></font></span></div></div></div></div></blockquote><div><br><br></div><div>Note: this is a reply to the thread, and not specifically to Ralf's comments (but those are included).<br><br>After reading all the replies, the first question that comes to mind is: should SciPy have *any* datasets?<br><br>I think this question has already been answered: we have had functions that return images in scipy.misc for a long time, and I don't recall anyone ever suggesting that these be removed.  (Well, there was lena(), but I don't think anyone had a problem with adding a replacement image.)  And the pull request for the ECG dataset has been merged (added to scipy.misc), so there is current support among the developers for providing datasets.<br><br>So the remaining questions are:<br>   (1) Where do the datasets reside?<br>   (2) What are the criteria for adding a new datasets?<br><br>Here's my 2¢:<br><br>(1) Where do the datasets reside?<br><br>My preference is to keep all the datasets in the top-level module scipy.datasets. Robert preferred this module for discoverability, and I agree.  By having all the datasets in one place, anyone can easily see what is available.  Teachers and others developing educational material know where to find source material for examples.  Developers, too, can easily look for examples to use in our docstrings or tutorials. (By the way, adding examples to the docstrings of all functions is an ongoing effort: <a href="https://github.com/scipy/scipy/issues/7168">https://github.com/scipy/scipy/issues/7168</a>.)<br><br>Also, there are many well-known datasets that could be used as examples for multiple scipy packages.  For a concrete example, a dataset that I could see adding to scipy is the Hald cement dataset.  SciPy should eventually have an implementation of the PCA decomposition, and it could conceivably live in scipy.linalg.  It would be reasonable to use the Hald data in the docstrings of the new PCA function(s) (cf. <a href="https://www.mathworks.com/help/stats/pca.html">https://www.mathworks.com/help/stats/pca.html</a>).  At the same time, the Hald data could enrich the docstrings of some functions in scipy.stats.<br><br>Similarly, Fisher's iris dataset provides a well-known example that could be used in docstrings in both scipy.cluster and scipy.stats.<br><br><br>(2) What are the criteria for adding a new datasets?<br><br>So far, the only compelling reason I can see to even have datasets is to have interesting examples in the docstrings (or at least in our tutorials).  For example, the docstring for scipy.ndimage.gaussian_filter and several other transformations in ndimage use the image returned by scipy.misc.ascent():<br><br>    <a href="https://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.gaussian_filter.html">https://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.gaussian_filter.html</a><br><br>I could see the benefit of having well-known datasets such as Fisher's iris data, the Hald cement data, and some version of a sunspot activity time series, to be used in the docstrings in scipy.stats, scipy.signal, scipy.cluster, scipy.linalg, and elsewhere.<br><br>Stéfan expressed regret about including datasets in sciki-image.  The main issue seems to be "bloat".  Scikit-image is an image processing library, so the datasets used there are likely all images, and there is a minimum size for a sample image to be useful as an example.  For scipy, we already have two images, and I don't think we'll need more.  The newly added ECG dataset is 116K (which is less than the existing image datasets: "ascent.dat" is 515K and "face.dat" is 1.5M).  The potential datasets that I mentioned above (Hald, iris, sunspots) are all very small.   If we are conservative about what we include, and focus on datasets chosen specifically to demonstrate scipy functionality, we should be able to avoid dataset bloat.<br><br>This leads to my proposal for the criteria for adding a dataset:<br><br>(a) Not too big.  The size of a dataset should not exceed $MAX (but I don't have a good suggestion for what $MAX should be at the moment).<br>(b) The dataset should be well-known, where "well-known" means that the dataset is one that is already widely used as an example and many people will know it by name (e.g. the iris dataset), or the dataset is a sample of a common signal type or format (e.g an ECG signal, or an image such as misc.ascent).<br>(c) We actually *use* the dataset in one of *our* docstrings or tutorials.  I don't think our datasets package should become a repository of interesting scientific data with no connection to the scipy code.  Its purpose should be to enrich our documentation.  (Note that by this criterion, the recently added ECG signal would not qualify!) <br><br>To summarize: I'm in favor scipy.datasets, a conservatively curated subpackage containing well-known datasets.<br><br><br>Warren<br><br><br>P.S. I should add that I'm not in favor putting code in scipy that fetches data from the web.  That type of data retrieval could be useful, but it seems more appropriate for a package that is independent of scipy.<br><br><br><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span class="gmail-HOEnZb"><font color="#888888">Ralf<br><br></font></span></div><div> <br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
<br></blockquote></div><br></div></div>