Mailman 3 February 2016 - NumPy-Discussion

Proposal to add `weights` to `np.percentile` and `np.median`
by Joseph Fox-Rabinovitz 16 Feb '16

16 Feb '16

I would like to add a `weights` keyword to `np.partition`, `np.percentile` and `np.median`. My reason for doing so is to to allow `np.histogram` to process automatic bin selection with weights. Currently, weights are not supported for the automatic bin selection and would be difficult to support in `auto` mode without having `np.percentile` support a `weights` keyword. I suspect that there are many other uses for such a feature. I have taken a preliminary look at the C implementation of the partition functions that are the basis for `partition`, `median` and `percentile`. I think that it would be possible to add versions (or just extend the functionality of existing ones) that check the ratio of the weights below the partition point to the total sum of the weights instead of just counting elements. One of the main advantages of such an implementation is that it would allow any real weights to be handled correctly, not just integers. Complex weights would not be supported. The purpose of this email is to see if anybody objects, has ideas or cares at all about this proposal before I spend a significant amount of time working on it. For example, did I miss any functions in my list? Regards, -Joe

3 5

Re: [Numpy-discussion] [Suggestion] Labelled Array
by Sérgio 16 Feb '16

16 Feb '16

Just something I tried with pandas: >>> image array([[[ 0, 1, 2, 3, 4], [ 5, 6, 7, 8, 9], [10, 11, 12, 13, 14], [15, 16, 17, 18, 19]], [[20, 21, 22, 23, 24], [25, 26, 27, 28, 29], [30, 31, 32, 33, 34], [35, 36, 37, 38, 39]], [[40, 41, 42, 43, 44], [45, 46, 47, 48, 49], [50, 51, 52, 53, 54], [55, 56, 57, 58, 59]]]) >>> label array([[0, 1, 2, 3, 4], [1, 2, 3, 4, 5], [2, 3, 4, 5, 6], [3, 4, 5, 6, 7]]) >>> dt = pd.DataFrame(np.vstack((label.ravel(), image.reshape(3, 20))).T) >>> labelled_image = dt.groupby(0) >>> labelled_image.mean().values array([[ 0, 20, 40], [ 3, 23, 43], [ 6, 26, 46], [ 9, 29, 49], [10, 30, 50], [13, 33, 53], [16, 36, 56], [19, 39, 59]]) Sergio > Date: Sat, 13 Feb 2016 22:41:13 -0500 > From: Allan Haldane <allanhaldane(a)gmail.com> > To: numpy-discussion(a)scipy.org > Subject: Re: [Numpy-discussion] [Suggestion] Labelled Array > Message-ID: <56BFF759.7010505(a)gmail.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Impressive! > > Possibly there's still a case for including a 'groupby' function in > numpy itself since it's a generally useful operation, but I do see less > of a need given the nice pandas functionality. > > At least, next time someone asks a stackoverflow question like the ones > below someone should tell them to use pandas! > > (copied from my gist for future list reference). > > http://stackoverflow.com/questions/4373631/sum-array-by-number-in-numpy > > http://stackoverflow.com/questions/31483912/split-numpy-array-according-to-… > > http://stackoverflow.com/questions/31863083/python-split-numpy-array-based-… > > http://stackoverflow.com/questions/28599405/splitting-an-array-into-two-sma… > > http://stackoverflow.com/questions/7662458/how-to-split-an-array-according-… > > Allan > > > On 02/13/2016 01:39 PM, Jeff Reback wrote: > > In [10]: pd.options.display.max_rows=10 > > > > In [13]: np.random.seed(1234) > > > > In [14]: c = np.random.randint(0,32,size=100000) > > > > In [15]: v = np.arange(100000) > > > > In [16]: df = DataFrame({'v' : v, 'c' : c}) > > > > In [17]: df > > Out[17]: > > c v > > 0 15 0 > > 1 19 1 > > 2 6 2 > > 3 21 3 > > 4 12 4 > > ... .. ... > > 99995 7 99995 > > 99996 2 99996 > > 99997 27 99997 > > 99998 28 99998 > > 99999 7 99999 > > > > [100000 rows x 2 columns] > > > > In [19]: df.groupby('c').count() > > Out[19]: > > v > > c > > 0 3136 > > 1 3229 > > 2 3093 > > 3 3121 > > 4 3041 > > .. ... > > 27 3128 > > 28 3063 > > 29 3147 > > 30 3073 > > 31 3090 > > > > [32 rows x 1 columns] > > > > In [20]: %timeit df.groupby('c').count() > > 100 loops, best of 3: 2 ms per loop > > > > In [21]: %timeit df.groupby('c').mean() > > 100 loops, best of 3: 2.39 ms per loop > > > > In [22]: df.groupby('c').mean() > > Out[22]: > > v > > c > > 0 49883.384885 > > 1 50233.692165 > > 2 48634.116069 > > 3 50811.743992 > > 4 50505.368629 > > .. ... > > 27 49715.349425 > > 28 50363.501469 > > 29 50485.395933 > > 30 50190.155223 > > 31 50691.041748 > > > > [32 rows x 1 columns] > > > > > > On Sat, Feb 13, 2016 at 1:29 PM, <josef.pktd(a)gmail.com > > <mailto:josef.pktd@gmail.com>> wrote: > > > > > > > > On Sat, Feb 13, 2016 at 1:01 PM, Allan Haldane > > <allanhaldane(a)gmail.com <mailto:allanhaldane@gmail.com>> wrote: > > > > Sorry, to reply to myself here, but looking at it with fresh > > eyes maybe the performance of the naive version isn't too bad. > > Here's a comparison of the naive vs a better implementation: > > > > def split_classes_naive(c, v): > > return [v[c == u] for u in unique(c)] > > > > def split_classes(c, v): > > perm = c.argsort() > > csrt = c[perm] > > div = where(csrt[1:] != csrt[:-1])[0] + 1 > > return [v[x] for x in split(perm, div)] > > > > >>> c = randint(0,32,size=100000) > > >>> v = arange(100000) > > >>> %timeit split_classes_naive(c,v) > > 100 loops, best of 3: 8.4 ms per loop > > >>> %timeit split_classes(c,v) > > 100 loops, best of 3: 4.79 ms per loop > > > > > > The usecases I recently started to target for similar things is 1 > > Million or more rows and 10000 uniques in the labels. > > The second version should be faster for large number of uniques, I > > guess. > > > > Overall numpy is falling far behind pandas in terms of simple > > groupby operations. bincount and histogram (IIRC) worked for some > > cases but are rather limited. > > > > reduce_at looks nice for cases where it applies. > > > > In contrast to the full sized labels in the original post, I only > > know of applications where the labels are 1-D corresponding to rows > > or columns. > > > > Josef > > > > > > In any case, maybe it is useful to Sergio or others. > > > > Allan > > > > > > On 02/13/2016 12:11 PM, Allan Haldane wrote: > > > > I've had a pretty similar idea for a new indexing function > > 'split_classes' which would help in your case, which > > essentially does > > > > def split_classes(c, v): > > return [v[c == u] for u in unique(c)] > > > > Your example could be coded as > > > > >>> [sum(c) for c in split_classes(label, data)] > > [9, 12, 15] > > > > I feel I've come across the need for such a function often > > enough that > > it might be generally useful to people as part of numpy. The > > implementation of split_classes above has pretty poor > > performance > > because it creates many temporary boolean arrays, so my plan > > for a PR > > was to have a speedy version of it that uses a single pass > > through v. > > (I often wanted to use this function on large datasets). > > > > If anyone has any comments on the idea (good idea. bad > > idea?) I'd love > > to hear. > > > > I have some further notes and examples here: > > https://gist.github.com/ahaldane/1e673d2fe6ffe0be4f21 > > > > Allan > > > > On 02/12/2016 09:40 AM, S?rgio wrote: > > > > Hello, > > > > This is my first e-mail, I will try to make the idea > simple. > > > > Similar to masked array it would be interesting to use a > > label array to > > guide operations. > > > > Ex.: > > >>> x > > labelled_array(data = > > [[0 1 2] > > [3 4 5] > > [6 7 8]], > > label = > > [[0 1 2] > > [0 1 2] > > [0 1 2]]) > > > > >>> sum(x) > > array([9, 12, 15]) > > > > The operations would create a new axis for label > indexing. > > > > You could think of it as a collection of masks, one for > > each label. > > > > I don't know a way to make something like this > > efficiently without a > > loop. Just wondering... > > > > S?rgio. > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion(a)scipy.org > > <mailto:NumPy-Discussion@scipy.org> > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion(a)scipy.org <mailto:NumPy-Discussion@scipy.org> > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion(a)scipy.org <mailto:NumPy-Discussion@scipy.org> > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion(a)scipy.org > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > >

1 0

Re: [Numpy-discussion] NumPy 1.11.0b3 released.
by josef.pktd＠gmail.com 16 Feb '16

16 Feb '16

On Mon, Feb 15, 2016 at 10:46 PM, <josef.pktd(a)gmail.com> wrote: > > > On Fri, Feb 12, 2016 at 4:19 PM, Nathan Goldbaum <nathan12343(a)gmail.com> > wrote: > >> https://github.com/numpy/numpy/blob/master/doc/release/1.11.0-notes.rst >> >> On Fri, Feb 12, 2016 at 3:17 PM, Andreas Mueller <t3kcit(a)gmail.com> >> wrote: >> >>> Hi. >>> Where can I find the changelog? >>> It would be good for us to know which changes are done one purpos >>> without hunting through the issue tracker. >>> >>> Thanks, >>> Andy >>> >>> >>> On 02/09/2016 09:09 PM, Charles R Harris wrote: >>> >>> Hi All, >>> >>> I'm pleased to announce the release of NumPy 1.11.0b3. This beta >>> contains additional bug fixes as well as limiting the number of >>> FutureWarnings raised by assignment to masked array slices. One issue that >>> remains to be decided is whether or not to postpone raising an error for >>> floats used as indexes. Sources may be found on Sourceforge >>> <https://sourceforge.net/projects/numpy/files/NumPy/1.11.0b3/> and both >>> sources and OS X wheels are availble on pypi. Please test, hopefully this >>> will be that last beta needed. >>> >>> As a note on problems encountered, twine uploads continue to fail for >>> me, but there are still variations to try. The wheeluploader downloaded >>> wheels as it should, but could not upload them, giving the error message >>> "HTTPError: 413 Client Error: Request Entity Too Large for url: >>> <https://www.python.org/pypi>https://www.python.org/pypi". Firefox also >>> complains that http://wheels.scipy.org is incorrectly configured with >>> an invalid certificate. >>> >>> Enjoy, >>> >>> Chuck >>> >>> >>> _______________________________________________ >>> NumPy-Discussion mailing listNumPy-Discussion@scipy.orghttps://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >>> >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion(a)scipy.org >>> https://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >>> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion(a)scipy.org >> https://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > (try to send again) > > another indexing question: (not covered by unit test but showed up in > examples in statsmodels) > > > This works in numpy at least 1.9.2 and 1.6.1 (python 2.7, and python 3.4) > > >>> list(range(5))[np.array([0])] > 0 > > > > on numpy 0.11.0b2 (I'm not yet at b3) (python 3.4) > > I get the same exception as here but even if there is just one element > > > >>> list(range(5))[np.array([0, 1])] > Traceback (most recent call last): > File "<pyshell#7>", line 1, in <module> > list(range(5))[np.array([0, 1])] > TypeError: only integer arrays with one element can be converted to an > index > > > the actual code uses pop on a python list with a return from > np.where(...)[0] that returns a one element int64 array > > Josef >

3 6

Fwd: Numexpr-3.0 proposal
by Robert McLeod 16 Feb '16

16 Feb '16

On Mon, Feb 15, 2016 at 10:43 AM, Gregor Thalhammer < gregor.thalhammer(a)gmail.com> wrote: > > Dear Robert, > > thanks for your effort on improving numexpr. Indeed, vectorized math > libraries (VML) can give a large boost in performance (~5x), except for a > couple of basic operations (add, mul, div), which current compilers are > able to vectorize automatically. With recent gcc even more functions are > vectorized, see https://sourceware.org/glibc/wiki/libmvec But you need > special flags depending on the platform (SSE, AVX present?), runtime > detection of processor capabilities would be nice for distributing > binaries. Some time ago, since I lost access to Intels MKL, I patched > numexpr to use Accelerate/Veclib on os x, which is preinstalled on each > mac, see https://github.com/geggo/numexpr.git veclib_support branch. > > As you increased the opcode size, I could imagine providing a bit to > switch (during runtime) between internal functions and vectorized ones, > that would be handy for tests and benchmarks. > Dear Gregor, Your suggestion to separate the opcode signature from the library used to execute it is very clever. Based on your suggestion, I think that the natural evolution of the opcodes is to specify them by function signature and library, using a two-level dict, i.e. numexpr.interpreter.opcodes['exp_f8f8f8'][gnu] = some_enum numexpr.interpreter.opcodes['exp_f8f8f8'][msvc] = some_enum +1 numexpr.interpreter.opcodes['exp_f8f8f8'][vml] = some_enum + 2 numexpr.interpreter.opcodes['exp_f8f8f8'][yeppp] = some_enum +3 I want to procedurally generate opcodes.cpp and interpreter_body.cpp. If I do it the way you suggested funccodes.hpp and all the many #define's regarding function codes in the interpreter can hopefully be removed and hence simplify the overall codebase. One could potentially take it a step further and plan (optimize) each expression, similar to what FFTW does with regards to matrix shape. That is, the basic way to control the library would be with a singleton library argument, i.e.: result = ne.evaluate( "A*log(foo**2 / bar**2", lib=vml ) However, we could also permit a tuple to be passed in, where each element of the tuple reflects the library to use for each operation in the AST tree: result = ne.evaluate( "A*log(foo**2 / bar**2", lib=(gnu,gnu,gnu,yeppp,gnu) ) In this case the ops are (mul,mul,div,log,mul). The op-code picking is done by the Python side, and this tuple could be potentially optimized by numexpr rather than hand-optimized, by trying various permutations of the linked C math libraries. The wisdom from the planning could be pickled and saved in a wisdom file. Currently Numexpr has cacheDict in util.py but there's no reason this can't be pickled and saved to disk. I've done a similar thing by creating wrappers for PyFFTW already. Robert -- Robert McLeod, Ph.D. Center for Cellular Imaging and Nano Analytics (C-CINA) Biozentrum der Universität Basel Mattenstrasse 26, 4058 Basel Work: +41.061.387.3225 robert.mcleod(a)unibas.ch robert.mcleod(a)bsse.ethz.ch <robert.mcleod(a)ethz.ch> robbmcleod(a)gmail.com

2 1

Numexpr-3.0 proposal
by Robert McLeod 16 Feb '16

16 Feb '16

Hello everyone, I've done some work on making a new version of Numexpr that would fix some of the limitations of the original virtual machine with regards to data types and operation/function count. Basically I re-wrote the Python and C sides to use 4-byte words, instead of null-terminated strings, for operations and passing types. This means the number of operations and types isn't significantly limited anymore. Francesc Alted suggested I should come here and get some advice from the community. I wrote a short proposal on the Wiki here: https://github.com/pydata/numexpr/wiki/Numexpr-3.0-Branch-Overview One can see my branch here: https://github.com/robbmcleod/numexpr/tree/numexpr-3.0 If anyone has any comments they'd be welcome. Questions from my side for the group: 1.) Numpy casting: I downloaded the Numpy source and after browsing it seems the best approach is probably to just use numpy.core.numerictypes.find_common_type? 2.) Can anyone foresee any issues with casting build-in Python types (i.e. float and integer) to their OS dependent numpy equivalents? Numpy already seems to do this. 3.) Is anyone enabling the Intel VML library? There are a number of comments in the code that suggest it's not accelerating the code. It also seems to cause problems with bundling numexpr with cx_freeze. 4.) I took a stab at converting from distutils to setuputils but this seems challenging with numpy as a dependency. I wonder if anyone has tried monkey-patching so that setup.py build_ext uses distutils and then pass the interpreter.pyd/so as a data file, or some other such chicanery? (I was going to ask about attaching a debugger, but I just noticed: https://wiki.python.org/moin/DebuggingWithGdb ) Ciao, Robert -- Robert McLeod, Ph.D. Center for Cellular Imaging and Nano Analytics (C-CINA) Biozentrum der Universität Basel Mattenstrasse 26, 4058 Basel Work: +41.061.387.3225 robert.mcleod(a)unibas.ch robert.mcleod(a)bsse.ethz.ch <robert.mcleod(a)ethz.ch> robbmcleod(a)gmail.com

3 3

cycler v.0.10.0 released
by Thomas Caswell 16 Feb '16

16 Feb '16

Folks, I am happy to announce the next release of Cycler. This will become the minimal version for the upcoming mpl v2.0 release. http://matplotlib.org/cycler/ Feature release for `cycler`. This release includes a number of new features: - `Cycler` objecst learned to generate an `itertools.cycle` by calling them, a-la a generator. - `Cycler` objects learned to change the name of a key via the new `.change_key(old_key, new_key)` method. - `Cycler` objects learned how to compare each other and determine if they are equal or not (`==`). - `Cycler` objects learned how to join another `Cycler` to be concatenated into a singel longer `Cycler` via `concat` method of function. `A.concat(B)` or `concat(A, B)`. - The `cycler` factory function learned to construct a complex `Cycler` from iterables provided as keyword arguments. - `Cycler` objects learn do show their insides with the `by_key` method which returns a dictionary of lists (instead of an iterable of dictionaries). Tom

1 0

Subclassing ma.masked_array, code broken after version 1.9
by Gutenkunst, Ryan N - (rgutenk) 16 Feb '16

16 Feb '16

Hello all, In 2009 I developed an application that uses a subclass of masked arrays as a central data object. My subclass Spectrum possesses additional attributes along with many custom methods. It was very convenient to be able to use standard numpy functions for doing arithmetic on these objects. However, my code broke with numpy 1.10. I've finally had a chance to track down the problem, and I am hoping someone can suggest a workaround. See below for an example, which is as minimal as I could concoct. In this case, I have a Spectrum object that I'd like to take the logarithm of using numpy.ma.log, while preserving the value of the "folded" attribute. Up to numpy 1.9, this worked as expected, but in numpy 1.10 and 1.11 the attribute is not preserved. The change in behavior appears to be driven by a commit made on Jun 16th, 2015 by Marten van Kerkwijk. In particular, the commit changed _MaskedUnaryOperation.__call__ so that the result array's update_from method is no longer called with the input array as the argument, but rather the result of the numpy UnaryOperation (old line 889, new line 885). Because that UnaryOperation doesn't carry my new attribute, it's not present for update_from to access. I notice that similar changes were made to MaskedBinaryOperation, although I haven't tested those. It's not clear to me from the commit message why this particular change was made, so I don't know whether this new behavior is intentional. I know that subclassing arrays isn't widely encouraged, but it has been very convenient in my code. Is it still possible to subclass masked_array in such a way that functions like numpy.ma.log preserve additional attributes? If so, can someone point me in the right direction? Thanks! Ryan *** Begin example import numpy print 'Working with numpy {0}'.format(numpy.__version__) class Spectrum(numpy.ma.masked_array): def __new__(cls, data, mask=numpy.ma.nomask, data_folded=None): subarr = numpy.ma.masked_array(data, mask=mask, keep_mask=True, shrink=True) subarr = subarr.view(cls) subarr.folded = data_folded return subarr def __array_finalize__(self, obj): if obj is None: return numpy.ma.masked_array.__array_finalize__(self, obj) self.folded = getattr(obj, 'folded', 'unspecified') def _update_from(self, obj): print('Input to update_from: {0}'.format(repr(obj))) numpy.ma.masked_array._update_from(self, obj) self.folded = getattr(obj, 'folded', 'unspecified') def __repr__(self): return 'Spectrum(%s, folded=%s)'\ % (str(self), str(self.folded)) fs1 = Spectrum([2,3,4.], data_folded=True) fs2 = numpy.ma.log(fs1) print('fs2.folded status: {0}'.format(fs2.folded)) print('Expectation is True, achieved with numpy 1.9') *** End example -- Ryan Gutenkunst Assistant Professor Molecular and Cellular Biology University of Arizona phone: (520) 626-0569, office LSS 325 http://gutengroup.mcb.arizona.edu Latest paper: "Computationally efficient composite likelihood statistics for demographic inference" Molecular Biology and Evolution; http://dx.doi.org/10.1093/molbev/msv255

4 4

ANN: pandas v0.18.0rc1 - RELEASE CANDIDATE
by Jeff Reback 15 Feb '16

15 Feb '16

Hi, I'm pleased to announce the availability of the first release candidate of Pandas 0.18.0. Please try this RC and report any issues here: Pandas Issues <https://github.com/pydata/pandas/issues> We will be releasing officially in 1-2 weeks or so. **RELEASE CANDIDATE 1** This is a major release from 0.17.1 and includes a small number of API changes, several new features, enhancements, and performance improvements along with a large number of bug fixes. We recommend that all users upgrade to this version. Highlights include: - pandas >= 0.18.0 will no longer support compatibility with Python version 2.6 GH7718 <https://github.com/pydata/pandas/issues/7718> or version 3.3 GH11273 <https://github.com/pydata/pandas/issues/11273> - Moving and expanding window functions are now methods on Series and DataFrame similar to .groupby like objects, see here <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0180…> . - Adding support for a RangeIndex as a specialized form of the Int64Index for memory savings, see here <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0180…> . - API breaking .resample changes to make it more .groupby like, see here <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0180…> - Removal of support for positional indexing with floats, which was deprecated since 0.14.0. This will now raise a TypeError, see here <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0180…> - The .to_xarray() function has been added for compatibility with the xarray package <http://xarray.pydata.org/en/stable/> see here <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0180…> . - Addition of the .str.extractall() method <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0180…>, and API changes to the the .str.extract() method <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0180…>, and the .str.cat() method <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html#whatsnew-0180…> - pd.test() top-level nose test runner is available GH4327 <https://github.com/pydata/pandas/issues/4327> See the Whatsnew <http://pandas-docs.github.io/pandas-docs-travis/whatsnew.html> for much more information. Best way to get this is to install via conda <http://pandas-docs.github.io/pandas-docs-travis/install.html#installing-pan…> from our development channel. Builds for osx-64,linux-64,win-64 for Python 2.7 and Python 3.5 are all available. conda install pandas=v0.18.0rc1 -c pandas Thanks to all who made this release happen. It is a very large release! Jeff

2 3

Modulus (remainder) function corner cases
by Charles R Harris 14 Feb '16

14 Feb '16

Hi All, I'm curious as to what folks think about some choices in the compution of the remainder function. As an example where different choices can be made In [2]: -1e-64 % 1. Out[2]: 1.0 In [3]: float64(-1e-64) % 1. Out[3]: 0.99999999999999989 The first is Python, the second is in my branch. The first is more accurate numerically, but the modulus is of the same magnitude as the divisor. The second maintains the convention that the result must have smaller magnitude than the divisor. There are other corner cases along the same lines. So the question is, which is more desirable: maintaining numerical accuracy or enforcing mathematical convention? The differences are on the order of an ulp, but there will be a skew in the distribution of the errors if convention is maintained. The Fortran modulo function, which is the same basic function as in my branch, does not specify any bounds on the result for floating numbers, but gives only the formula, modulus(a, b) = a - b*floor(a/b), which has the advantage of being simple and well defined ;) Chuck

2 5

ANN: numpydoc 0.6.0 released
by Ralf Gommers 14 Feb '16

14 Feb '16

Hi all, I'm pleased to announce the release of numpydoc 0.6.0. The main new feature is support for the Yields section in numpy-style docstrings. This is described in https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt Numpydoc can be installed from PyPi: https://pypi.python.org/pypi/numpydoc Cheers, Ralf

2 2