Re: [Numpy-discussion] Deprecating `numpy.iterable`

t; We certainly can (and probably should) deprecate this, but we can't >> > remove >> > it for a very long time. >> > >> > np.iterable is used in a lot of third party code. >> > >> > On Wed, Feb 10, 2016 at 7:09 PM, Joseph Fox-Rabinovitz >> > <jfoxrabi

[Numpy-discussion] Proposal for IQR function

I have created an IQR function to add to the other dispersion metrics such as standard deviation. I have described the purpose and nature of the proposal in PR#7137, so I am pasting the text here as well: Motivation -- This function is used in one place in numpy already (to compute the

[Numpy-discussion] ENH: `scale` parameter for `sinc`

I have created PR #7322 (https://github.com/numpy/numpy/pull/7322) to add a scale parameter to `sinc`. What this allows is to compute `sinc` as `sin(x)/x` or really `sin(n*x)/(n*x)` for arbitrary `n` instead of just `sin(pi*x)/(pi*x)` as is being done now. The parameter accepts two string

Re: [Numpy-discussion] Generalized flip function

If nothing else, this is a nice complement to the generalized `stack` function. -Joe On Fri, Feb 26, 2016 at 11:32 AM, Eren Sezener wrote: > Hi, > > In PR #7346 we add a flip function that generalizes fliplr and flipud for > arbitrary axes. > > flipud and fliplr

Re: [Numpy-discussion] PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogram

] PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogramThe tests are not passing, seems like you are taking the sqrt of a negative number, may want to check the inputs and raise a more informative error (and add a test for it). Jaime On Thu, Jan 21, 2016 at 7:51 AM, Joseph Fox

[Numpy-discussion] PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogram

Please let me know if there is anything wrong or missing. I have added a couple of estimators that I find useful sometimes. -Joe ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogram

not passing, seems like you are taking the sqrt of a negative > number, may want to check the inputs and raise a more informative error (and > add a test for it). > > Jaime > > On Thu, Jan 21, 2016 at 7:51 AM, Joseph Fox-Rabinovitz > <jfoxrabinov...@gmail.

Re: [Numpy-discussion] PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogram

Due to a mistake I made in my branch structure, I have replaced this PR with #7090: https://github.com/numpy/numpy/pull/7090. All of the changes and fixes so far are squashed into the new request. -Joe On Thu, Jan 21, 2016 at 1:51 AM, Joseph Fox-Rabinovitz <jfoxrabinov...@gmail.com>

[Numpy-discussion] PR #7090: ENH: Added 'doane' and 'sqrt' estimators to np.histogram

on is http://docs.scipy.org/doc/numpy-1.10.1/dev/gitwash/development_workflow.html#asking-for-your-changes-to-be-merged-with-the-main-repo, but that does not go into detail about what happens after the point I have already reached. Regards, -Joe On Thu, Jan 21, 2016 at 3:37 PM, Joseph Fox-Rabinovitz

Re: [Numpy-discussion] PR #7090: ENH: Added 'doane' and 'sqrt' estimators to np.histogram

2016 at 8:30 PM, Joseph Fox-Rabinovitz > <jfoxrabinov...@gmail.com> wrote: >> >> As someone very new to relatively large projects such as numpy, I was >> wondering how the process works. I have announced my PR with some >> small enhancements to the histogram functi

[Numpy-discussion] Proposal to add `weights` to `np.percentile` and `np.median`

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

Re: [Numpy-discussion] Proposal to add `weights` to `np.percentile` and `np.median`

vely sorting may be faster than a not-so-optimized version of > quickselect. > > Antony > > 2016-02-15 21:49 GMT-08:00 Joseph Fox-Rabinovitz <jfoxrabinov...@gmail.com>: >> >> I would like to add a `weights` keyword to `np.partition`, >> `np.percentile` and

Re: [Numpy-discussion] Proposal to add `weights` to `np.percentile` and `np.median`

partitioning scheme. - Joe On Tue, Feb 16, 2016 at 2:39 PM, <josef.p...@gmail.com> wrote: > > > On Tue, Feb 16, 2016 at 1:41 PM, Joseph Fox-Rabinovitz > <jfoxrabinov...@gmail.com> wrote: >> >> Thanks for pointing me to that. I had something a bit different in &g

Re: [Numpy-discussion] making "low" optional in numpy.randint

On Wed, Feb 17, 2016 at 1:37 PM, wrote: > > > On Wed, Feb 17, 2016 at 10:01 AM, G Young wrote: >> >> Hello all, >> >> I have a PR open here that makes "low" an optional parameter in >> numpy.randint and introduces new behavior into the API as follows:

Re: [Numpy-discussion] making "low" optional in numpy.randint

at do you mean by making the functions > "consistent" (i.e. outline the behavior exactly depending on the inputs)? > As I've explained before, and I will state it again, the different behavior > for the high=None and low != None case is due to backwards compatibility. &

Re: [Numpy-discussion] proposal: new logspace without the log in the argument

I like the idea, as long as we all remain aware of the irony of having a "log" spacing for a function named "lin"space. -Joe On Thu, Feb 18, 2016 at 2:44 PM, Robert Kern wrote: > On Thu, Feb 18, 2016 at 7:38 PM, Nathaniel Smith wrote: >> >> Some

Re: [Numpy-discussion] proposal: new logspace without the log in the argument

If the author is willing, I'd say both functions are useful. The "geom" prefix is very fitting. - Joe -- Original message--From: Robert KernDate: Fri, Feb 19, 2016 08:00To: Discussion of Numerical Python;Subject:Re: [Numpy-discussion] proposal: new logspace without the

[Numpy-discussion] Deprecating `numpy.iterable`

I have created a PR to deprecate `np.iterable` (https://github.com/numpy/numpy/pull/7202). It is a very old function, introduced as a utility in 2005 (https://github.com/numpy/numpy/commit/052a7b2e3276a303be1083022fc24d43084d2e14), and there is no good reason for it to be part of the public API.

Re: [Numpy-discussion] Changes to generalized ufunc core dimension checking

On Thu, Mar 17, 2016 at 10:03 AM, Nathaniel Smith wrote: > On Mar 17, 2016 1:22 AM, "Feng Yu" wrote: >> >> Hi, >> >> Here is another example. >> >> To write pix2ang (and similar functions) to a ufunc, one may want to have >> implicit scalar broadcast on

Re: [Numpy-discussion] Multi-dimensional array of splitted array

On Wed, Mar 23, 2016 at 9:37 AM, Ibrahim EL MEREHBI wrote: > Thanks Eric. I already checked that. It's not what I want. I think I wasn't > clear about what I wanted. > > I want to split each column but I want to do it for each column and end up > with an array. Here's the

Re: [Numpy-discussion] Make np.bincount output same dtype as weights

Would it make sense to just make the output type large enough to hold the cumulative sum of the weights? - Joseph Fox-Rabinovitz -- Original message--From: Jaime Fernández del RíoDate: Sat, Mar 26, 2016 16:16To: Discussion of Numerical Python;Subject:[Numpy-discussion

Re: [Numpy-discussion] Weighted percentile / quantile

Alex, At the moment, there does not appear to be anything in numpy. However, I am working (slowly) on upgrading the C code for partitioning with arbitrary arrays of real weights. That will get `partition`, `median`, `percentile` to work with weights, as well as enabling weights for the automated

Re: [Numpy-discussion] Reflect array?

e concatenation steps. > > Cheers! > > Ben Root > > On Tue, Mar 29, 2016 at 1:58 PM, Joseph Fox-Rabinovitz > <jfoxrabinov...@gmail.com> wrote: >> >> On Tue, Mar 29, 2016 at 1:46 PM, Benjamin Root <ben.v.r...@gmail.com> >> wrote: >> > Is ther

Re: [Numpy-discussion] Reflect array?

On Tue, Mar 29, 2016 at 1:46 PM, Benjamin Root wrote: > Is there a quick-n-easy way to reflect a NxM array that represents a > quadrant into a 2Nx2M array? Essentially, I am trying to reduce the size of > an expensive calculation by taking advantage of the fact that the

Re: [Numpy-discussion] Starting work on ufunc rewrite

There is certainly good precedent for the approach you suggest. Shortly after Nathaniel mentioned the rewrite to me, I looked up d-pointers as a possible technique: https://wiki.qt.io/D-Pointer. If we allow arbitrary kwargs for the new functions, is that something you would want to note in the

Re: [Numpy-discussion] Python 3 dict support (issue #5718)

Jaime, This is a great intro for people looking to jump into the C side of things. I have been trying to figure out which bits are the important ones from looking at the code and the docs. Your post cut out most of the confusion. Is there some way you would consider adding something like this

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

2016 at 3:29 AM, <josef.p...@gmail.com> wrote: >> >> >> >> On Wed, Jul 6, 2016 at 2:21 AM, Ralf Gommers <ralf.gomm...@gmail.com> >> wrote: >>> >>> >>> >>> On Wed, Jul 6, 2016 at 7:06 AM, Nathaniel Smith <n...@pobox.com> wr

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

le >> rules such as 'left' or 'right' or maybe something akin to what >> at_least3d() implements. >> >> On Wed, Jul 6, 2016 at 3:20 PM, Joseph Fox-Rabinovitz > @gmail.com> wrote: >> > On Wed, Jul 6, 2016 at 2:57 PM, Eric Firing <efir...@hawaii.edu> &g

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

t 12:35 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Jul 6, 2016 6:12 AM, "Joseph Fox-Rabinovitz" <jfoxrabinov...@gmail.com> > wrote: >> >> I can add a keyword-only argument that lets you put the new dims >> before or after the existing ones. I am n

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

I still think this function is useful. I have made a change so that it only accepts one array, as Marten suggested, making the API much cleaner than that of its siblings. The side on which the new dimensions will be added is configurable via the `where` parameter, which currently accepts 'before'

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

; I wouldn't have the keyword be "where", as that collides with the notion of > "where" elsewhere in numpy. > > On Wed, Jul 6, 2016 at 2:21 PM, Joseph Fox-Rabinovitz > <jfoxrabinov...@gmail.com> wrote: >> >> I still think this function is useful.

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

On Wed, Jul 6, 2016 at 3:01 PM, Juan Nunez-Iglesias wrote: > at_leastnd would be useful for nd image processing in a very analogous way > to how at_least2d is used by scikit-image, assuming it prepends. The > at_least3d choice is baffling, seems analogous to the 0.5-based

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

On Wed, Jul 6, 2016 at 2:57 PM, Eric Firing wrote: > On 2016/07/06 8:25 AM, Benjamin Root wrote: >> >> I wouldn't have the keyword be "where", as that collides with the notion >> of "where" elsewhere in numpy. > > > Agreed. Maybe "side"? I have tentatively changed it to

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

gt;> > >> > >> > On Wed, Jul 6, 2016 at 7:06 AM, Nathaniel Smith <n...@pobox.com> wrote: >> > >> >> On Jul 5, 2016 9:09 PM, "Joseph Fox-Rabinovitz" >> >> <jfoxrabinov...@gmail.com> wrote: >> >> > >> >&g

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

>>> don't know how many dimensions are going to be added. If you knew, >>> then you wouldn't be calling this function. I can only imagine simple >>> rules such as 'left' or 'right' or maybe something akin to what >>> at_least3d() implements. >>> >

[Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

Hi, I have generalized np.atleast_1d, np.atleast_2d, np.atleast_3d with a function np.atleast_nd in PR#7804 (https://github.com/numpy/numpy/pull/7804). As a result of this PR, I have a couple of questions about `np.atleast_3d`. `np.atleast_3d` appears to do something weird with the dimensions:

Re: [Numpy-discussion] Python 3 dict support (issue #5718)

I will do my best. I am not that familiar with rst or numpy docs, but that's what PRs are for after all. -Joe On Thu, Jul 21, 2016 at 12:09 PM, Marten van Kerkwijk wrote: > Yes, indeed, where should this be!? > > The logical place would be in the developer

Re: [Numpy-discussion] composing Euler rotation matrices

Could you show what you are doing to get the statement "However, I cannot reproduce this matrix via composition; i.e. by multiplying the underlying rotation matrices.". I would guess something involving the `*` operator instead of `@`, but guessing probably won't help you solve your issue.

Re: [Numpy-discussion] Numpy Overhead

It would really help to see the code you are using in both cases as well as some heap usage numbers... -Joe On Tue, Feb 28, 2017 at 5:12 PM, Sebastian K wrote: > Thank you for your answer. > For example a very simple algorithm is a matrix multiplication. I

Re: [Numpy-discussion] Numpy Overhead

For one thing, `C = np.empty(shape=(n,n), dtype='float64')` allocates 10^4 extra elements before being immediately discarded. -Joe On Tue, Feb 28, 2017 at 5:57 PM, Sebastian K wrote: > Yes it is true the execution time is much faster with the numpy

[Numpy-discussion] Indexing issue with ndarrays

This issue recently came up on Stack Overflow: http://stackoverflow.com/questions/39145795/masking-a-series-with-a-boolean-array. The poster attempted to index an ndarray with a pandas boolean Series object (all False), but the result was as if he had indexed with an array of integer zeros. Can

Re: [Numpy-discussion] Indexing issue with ndarrays

On Thu, Aug 25, 2016 at 4:37 PM, Sebastian Berg <sebast...@sipsolutions.net> wrote: > On Do, 2016-08-25 at 10:36 -0400, Joseph Fox-Rabinovitz wrote: > > This issue recently came up on Stack Overflow: http://stackoverflow.c > > om/questions/39145795/masking-a-series

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

, -Joe On Mon, Jul 11, 2016 at 10:41 AM, Joseph Fox-Rabinovitz < jfoxrabinov...@gmail.com> wrote: > I would like to follow up on my original PR (7804). While there > appears to be some debate as to whether the PR is numpy material to > begin with, there do not appear to be any t

Re: [Numpy-discussion] in1d, but preserve shape of ar1

Perhaps you could move the code from in1d to your new function and redefine in1d in terms of it? That may help encourage migration and also make deprecation easier down the line. -Joe On Mon, Dec 19, 2016 at 8:43 PM, Stephan Hoyer wrote: > I think this is a great idea! >