Re: [Numpy-discussion] Fortran order in recarray.

On Wed, Feb 22, 2017 at 8:57 AM, Alex Rogozhnikov < alex.rogozhni...@yandex.ru> wrote: > Pandas may be nice, if you need a report, and you need get it done > tomorrow. Then you'll throw away the code. When we initially used pandas as > main data storage in yandex/rep, it looked like an good idea,

Re: [Numpy-discussion] __numpy_ufunc__

On Wed, Feb 22, 2017 at 6:31 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > It seems to me entirely logical (but then it would, I suggested it > before...) that we allow opting out by setting `__array_ufunc__` to > None; in that case, binops return NotImplemented and ufuncs raise >

Re: [Numpy-discussion] Proposal to support __format__

On Tue, Feb 14, 2017 at 5:35 PM, Gustav Larsson wrote: > 1. For object arrays, I would default to calling format on each element >> (your "map principle") rather than raising an error. >> > > I'm glad you brought this up as a possibility. It might be possible, but > there are some issues that wou

Re: [Numpy-discussion] Proposal to support __format__

On Tue, Feb 14, 2017 at 3:34 PM, Gustav Larsson wrote: > Hi everyone! > > I want to discuss adding support for __format__ in ndarray and I am > willing to > contribute code-wise once consensus has been reached. It was briefly > discussed on GitHub two years ago (https://github.com/numpy/ > numpy/

Re: [Numpy-discussion] ANN: xarray v0.9 released

On Wed, Feb 1, 2017 at 12:55 AM, Marmaduke Woodman wrote: > Looks very nice; is the API stable or are you waiting for a v1.0 release? > We are pretty close to full API stability but not quite there yet. Enough people are using xarray in production that breaking changes are made with serious caut

[Numpy-discussion] ANN: xarray v0.9 released

I'm pleased to announce the release of the latest major version of xarray, v0.9. xarray is an open source project and Python package that provides a toolkit and data structures for N-dimensional labeled arrays. Its approach combines an API inspired by pandas with the Common Data Model for self-des

Re: [Numpy-discussion] numpy vs algebra Was: Integers to negative integer powers...

On Tue, Jan 3, 2017 at 3:05 PM, Nathaniel Smith wrote: > It's possible we should back off to just issuing a deprecation warning in > 1.12? > > On Jan 3, 2017 1:47 PM, "Yaroslav Halchenko" wrote: > >> hm... testing on current master (first result is from python's pow) >> >> $> python -c "import n

Re: [Numpy-discussion] numpy vs algebra Was: Integers to negative integer powers...

On Tue, Jan 3, 2017 at 9:00 AM, Yaroslav Halchenko wrote: > Sorry for coming too late to the discussion and after PR "addressing" > the issue by issuing an error was merged [1]. I got burnt by new > behavior while trying to build fresh pandas release on Debian (we are > freezing for release way

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

I think this is a great idea! I agree that we need a new function. Because the new API is almost strictly superior, we should try to pick a more general name that we can encourage users to switch to from in1d. Pandas calls this method "isin", which I think is a perfectly good name for the multi-d

Re: [Numpy-discussion] ufunc for sum of squared difference

On Mon, Nov 14, 2016 at 5:40 PM, Matthew Harrigan < harrigan.matt...@gmail.com> wrote: > Essentially it creates a reduce for a function which isn't binary. I > think this would be generally useful. > NumPy already has a generic enough interface for creating such ufuncs. In fact, it's called a "g

Re: [Numpy-discussion] array comprehension

On Fri, Nov 4, 2016 at 10:24 AM, Nathaniel Smith wrote: > Are you sure fromiter doesn't make an intermediate list or equivalent? It > has to collect all the values before it can know the shape or dtype of the > array to put them in. > fromiter dynamically resizes a NumPy array, like a Python list

Re: [Numpy-discussion] array comprehension

On Fri, Nov 4, 2016 at 7:12 AM, Francesc Alted wrote: > Does this generalize to >1 dimensions? >> > > A reshape() is not enough? What do you want to do exactly? > np.fromiter takes scalar input and only builds a 1D array. So it actually can't combine multiple values at once unless they are flat

Re: [Numpy-discussion] __numpy_ufunc__

Recall that I think we wanted to rename this to __array_ufunc__, so we could change the function signature: https://github.com/numpy/numpy/issues/5986 I'm still a little nervous about this. Chunk -- what is your proposal for resolving the outstanding issues from https://github.com/numpy/numpy/issu

Re: [Numpy-discussion] __numpy_ufunc__

I'm happy to revisit the __numpy_ufunc__ discussion (I still want to see it happen!), but I don't recall scalars being a point of contention. The obvious thing to do with scalars would be to treat them the same as 0-dimensional arrays, though I might be missing some nuance... On Sat, Oct 29, 2016

Re: [Numpy-discussion] Combining covariance and correlation coefficient into one numpy.cov call

On Wed, Oct 26, 2016 at 11:03 AM, Mathew S. Madhavacheril < mathewsyr...@gmail.com> wrote: > On Wed, Oct 26, 2016 at 1:46 PM, Stephan Hoyer wrote: > >> I wonder if the goals of this addition could be achieved by simply adding >> an optional `cov` argument >> >

Re: [Numpy-discussion] Combining covariance and correlation coefficient into one numpy.cov call

I wonder if the goals of this addition could be achieved by simply adding an optional `cov` argument to np.corr, which would provide a pre-computed covariance. Either way, `covcorr` feels like a helper function that could exist in user code rather than numpy proper. On Wed, Oct 26, 2016 at 10:27

Re: [Numpy-discussion] Preserving NumPy views when pickling

On Tue, Oct 25, 2016 at 1:07 PM, Nathaniel Smith wrote: > Concretely, what do would you suggest should happen with: > > base = np.zeros(1) > view = base[:10] > > # case 1 > pickle.dump(view, file) > > # case 2 > pickle.dump(base, file) > pickle.dump(view, file) > > # case 3 > pickle.dump(

[Numpy-discussion] Preserving NumPy views when pickling

With a custom wrapper class, it's possible to preserve NumPy views when pickling: https://stackoverflow.com/questions/13746601/preserving-numpy-view-when-pickling This can result in significant time/space savings with pickling views along with base arrays and brings the behavior of NumPy more in l

Re: [Numpy-discussion] Numpy integers to integer powers again again

I am also concerned about adding more special cases for NumPy scalars vs arrays. These cases are already confusing (e.g., making no distinction between 0d arrays and scalars) and poorly documented. On Mon, Oct 24, 2016 at 4:30 PM, Nathaniel Smith wrote: > On Mon, Oct 24, 2016 at 3:41 PM, Charles

Re: [Numpy-discussion] padding options for diff

This looks like a welcome addition in functionality! It will be nice to be able to finally (soft) deprecate ediff1d. On Mon, Oct 24, 2016 at 5:44 AM, Matthew Harrigan < harrigan.matt...@gmail.com> wrote: > I posted a pull request which > adds optional pa

Re: [Numpy-discussion] how to name "contagious" keyword in np.ma.convolve

On Tue, Oct 18, 2016 at 4:18 PM, Allan Haldane wrote: > As for whether it should default to "True" or "False", the arguments I > see are: > > * False, because that is the way most functions like `np.ma.sum` >already work, as well as matlab and octave's similar "nanconv". > > * True, because

Re: [Numpy-discussion] Integers to negative integer powers, time for a decision.

On Sun, Oct 9, 2016 at 6:25 AM, Sebastian Berg wrote: > For what its worth, I still feel it is probably the only real option to > go with error, changing to float may have weird effects. Which does not > mean it is impossible, I admit, though I would like some data on how > downstream would handl

Re: [Numpy-discussion] Vendorize tempita

One way to do this is to move to vendorized dependencies into an submodule of numpy itself (e.g., sklearn.externals.joblib, though maybe even a little more indirection than that would be valuable to make it clear that it isn't part of NumPy public API). This would avoid further enlarging the set of

Re: [Numpy-discussion] PR 8053 np.random.multinomial tolerance param

I would actually be just as happy to relax the tolerance here to 1e-8 always. I doubt this would catch any fewer bugs than the current default. In contrast, adding new parameters adds cognitive overload for everyone encountering the function. Also, for your use case note that tensorflow has it's o

Re: [Numpy-discussion] guvectorize, a helper for writing generalized ufuncs

e that doesn't compile for testing and flexibility. > > Having this be inside NumPy itself seems ideal. > > -Travis > > > On Tue, Sep 13, 2016 at 12:59 PM, Stephan Hoyer wrote: > >> On Tue, Sep 13, 2016 at 10:39 AM, Nathan Goldbaum >> wrote: >> >>&g

Re: [Numpy-discussion] String & unicode arrays vs text loading in python 3

On Tue, Sep 13, 2016 at 11:05 AM, Lluís Vilanova wrote: > Whenever we repr an array using 'S', we can instead show a unicode in py3. > That > keeps the binary representation, but will always show the expected result > to > users, and it's only a handful of lines added to dump_data(). > > If neede

Re: [Numpy-discussion] guvectorize, a helper for writing generalized ufuncs

On Tue, Sep 13, 2016 at 10:39 AM, Nathan Goldbaum wrote: > I'm curious whether you have a plan to deal with the python functional > call overhead. Numba gets around this by JIT-compiling python functions - > is there something analogous you can do in NumPy or will this always be > limited by the

[Numpy-discussion] guvectorize, a helper for writing generalized ufuncs

NumPy has the handy np.vectorize for turning Python code that operates on scalars into a function that vectorizes works like a ufunc, but no helper function for creating generalized ufuncs ( http://docs.scipy.org/doc/numpy/reference/c-api.generalized-ufuncs.html). np.apply_along_axis accomplishes

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mon, Sep 5, 2016 at 6:02 PM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > p.s. Just to be clear: personally, I think we should have neither > `__numpy_getitem__` nor a mixin; we should just get the quite > wonderful new indexing methods! +1 I don't maintain ndarray subclasses (I

Re: [Numpy-discussion] Views and Increments

On Mon, Aug 8, 2016 at 6:11 AM, Anakim Border wrote: > Alternative version: > > >>> a = np.arange(10) > >>> a[np.array([1,6,5])] += 1 > >>> a > array([0, 2, 2, 3, 4, 6, 7, 7, 8, 9]) > I haven't checked, but a likely explanation is that Python itself interprets a[b] += c as a[b] = a[b] + c. Pyth

Re: [Numpy-discussion] ufunc reduceat behavior on empty slices

Jaime brought up the same issue recently, along with some other issues for ufunc.reduceat: https://mail.scipy.org/pipermail/numpy-discussion/2016-March/075199.html I completely agree with both of you that the current behavior for empty slices is very strange and should be changed to remove the spe

Re: [Numpy-discussion] Is there any official position on PEP484/mypy?

I'm a big fan of type annotations and would support moving your repo over to the official typeshed repo or the NumPy GitHub organization to indicate it's official status. This is excellent work -- thank you for putting in the effort! Like Ben, I have also wished for type annotation support for dim

Re: [Numpy-discussion] isnan() equivalent for np.NaT?

Agreed -- this would be really nice to have. For now, the best you can do is something like the following: def is_na(x): x = np.asarray(x) if np.issubdtype(x.dtype, (np.datetime64, np.timedelta64)): # ugh int_min = np.iinfo(np.int64).min return x.view('int64') == int_min

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

On Tue, Jul 5, 2016 at 10:06 PM, Nathaniel Smith wrote: > I don't know how typical I am in this. But it does make me wonder if the > atleast_* functions act as an attractive nuisance, where new users take > their presence as an implicit recommendation that they are actually a > useful thing to re

Re: [Numpy-discussion] Datarray 0.1.0 release

On Fri, Jun 10, 2016 at 12:51 PM, Matthew Brett wrote: > If you like the general idea, and you don't mind the pandas > dependency, `xray` is a much better choice for production code right > now, and will do the same stuff and more: > > https://pypi.python.org/pypi/xray/0.4.1 > > Hi Matthew, Con

Re: [Numpy-discussion] ENH: compute many inner products quickly

On Mon, Jun 6, 2016 at 3:32 PM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > Since we are at it, should quadratic/bilinear forms get their own function > too? That is, after all, what the OP was asking for. > If we have matvecmul and vecmul, then how to implement bilinear forms effic

Re: [Numpy-discussion] ENH: compute many inner products quickly

On Sun, Jun 5, 2016 at 5:08 PM, Mark Daoust wrote: > Here's the einsum version: > > `es = np.einsum('Na,ab,Nb->N',X,A,X)` > > But that's running ~45x slower than your version. > > OT: anyone know why einsum is so bad for this one? > I think einsum can create some large intermediate arrays. It c

Re: [Numpy-discussion] ENH: compute many inner products quickly

If possible, I'd love to add new functions for "generalized ufunc" linear algebra, and then deprecate (or at least discourage) using the older versions with inferior broadcasting rules. Adding a new keyword arg means we'll be stuck with an awkward API for a long time to come. There are three types

Re: [Numpy-discussion] NumPy 1.11 docs

Awesome, thanks Ralf! On Sun, May 29, 2016 at 1:13 AM Ralf Gommers wrote: > On Sun, May 29, 2016 at 4:35 AM, Stephan Hoyer wrote: > >> These still are missing from the SciPy.org page, several months after the >> release. >> > > Thanks Stephan, that needs fixing. &

[Numpy-discussion] NumPy 1.11 docs

These still are missing from the SciPy.org page, several months after the release. What do we need to do to keep these updated? Is there someone at Enthought we should ping? Or do we really just need to transition to different infrastructure? ___ NumPy-D

Re: [Numpy-discussion] Integers to integer powers

On Tue, May 24, 2016 at 10:31 AM, Alan Isaac wrote: > Yes, but that one case is trivial: a*a an_explicit_name ** 2 is much better than an_explicit_name * an_explicit_name, though. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://ma

Re: [Numpy-discussion] Integers to integer powers

On Tue, May 24, 2016 at 9:41 AM, Alan Isaac wrote: > What exactly is the argument against *always* returning float > (even for positive integer exponents)? > If we were starting over from scratch, I would agree with you, but the int ** 2 example feels quite compelling to me. I would guess there

Re: [Numpy-discussion] Proposal: numpy.random.random_seed

On Tue, May 17, 2016 at 12:18 AM, Robert Kern wrote: > On Tue, May 17, 2016 at 4:54 AM, Stephan Hoyer wrote: > > 1. When writing a library of stochastic functions that take a seed as an > input argument, and some of these functions call multiple other such > stochastic functio

Re: [Numpy-discussion] Proposal: numpy.random.random_seed

) offset = np.arange(size) return (base + offset) % (2 ** 32) In principle, I believe this could generate the full 2 ** 32 unique seeds without any collisions. Cryptography experts, please speak up if I'm mistaken here. On Mon, May 16, 2016 at 8:54 PM, Stephan Hoyer wrote: >

[Numpy-discussion] Proposal: numpy.random.random_seed

I have recently encountered several use cases for randomly generate random number seeds: 1. When writing a library of stochastic functions that take a seed as an input argument, and some of these functions call multiple other such stochastic functions. Dask is one such example [1]. 2. When a libr

Re: [Numpy-discussion] Changing the behavior of (builtins.)round (via the __round__ dunder) to return an integer

On Wed, Apr 13, 2016 at 8:06 AM, wrote: > > The difference is that Python 3 has long ints, (and doesn't have to > overflow, AFAICS) > This is a good point. But if your float is so big that rounding it to an integer would overflow int64, rounding is already a no-op. I'm sure this has been done

Re: [Numpy-discussion] Changing the behavior of (builtins.)round (via the __round__ dunder) to return an integer

On Wed, Apr 13, 2016 at 12:42 AM, Antony Lee wrote: > (Note that I am suggesting to switch to the new behavior regardless of the > version of Python.) > I would lean towards making this change only for Python 3. This is arguably more consistent with Python than changing the behavior on Python 2.

Re: [Numpy-discussion] Numpy arrays shareable among related processes (PR #7533)

On Mon, Apr 11, 2016 at 5:39 AM, Matěj Týč wrote: > * ... I do see some value in providing a canonical right way to > construct shared memory arrays in NumPy, but I'm not very happy with > this solution, ... terrible code organization (with the global > variables): > * I understand that, however

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

On Thu, Mar 17, 2016 at 3:28 PM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > Would the logic for such a thing be consistent? E.g. how do you decide if > the user is requesting (k),(k)->(), or (k),()->() with broadcasting over a > non-core dimension of size k in the second argument? Wh

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

On Thu, Mar 17, 2016 at 2:49 PM, Travis Oliphant wrote: > That's a great idea! > > Adding multiple-dispatch capability for this case could also solve a lot > of issues that right now prevent generalized ufuncs from being the > mechanism of implementation of *all* NumPy functions. > > -Travis > F

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

On Thu, Mar 17, 2016 at 1:04 AM, Travis Oliphant wrote: > I think that is a good idea.Let the user decide if scalar broadcasting > is acceptable for their function. > > Here is a simple concrete example where scalar broadcasting makes sense: > > A 1-d dot product (the core of np.inner) (k),

Re: [Numpy-discussion] fromnumeric.py internal calls

I think this is an improvement, but I do wonder if there are libraries out there that use *args instead of **kwargs to handle these extra arguments. Perhaps it's worth testing this change against third party array libraries that implement their own array like classes? Off the top of my head, maybe

Re: [Numpy-discussion] Generalized flip function

I also think this is a good idea -- the generalized flip is much more numpythonic than the specialized 2d versions. On Fri, Feb 26, 2016 at 11:36 AM Joseph Fox-Rabinovitz < jfoxrabinov...@gmail.com> wrote: > If nothing else, this is a nice complement to the generalized `stack` > function. > >

Re: [Numpy-discussion] GSoC?

On Wed, Feb 10, 2016 at 4:22 PM, Chris Barker wrote: > We might consider adding "improve duck typing for numpy arrays" >> > > care to elaborate on that one? > > I know it come up on here that it would be good to have some code in numpy > itself that made it easier to make array-like objects (I.e.

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

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 < jfoxrabinov...@gmail.com> wrote: > I have created a PR to deprecate `np.iterable` > (http

Re: [Numpy-discussion] GSoC?

On Wed, Feb 10, 2016 at 3:02 PM, Ralf Gommers wrote: > OK first version: > https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas > I kept some of the ideas from last year, but removed all potential mentors > as the same people may not be available this year - please re-add > yourselves wher

[Numpy-discussion] ANN: xarray (formerly xray) v0.7.0 released

ort for reading GRIB, HDF4 and other file formats via PyNIO For more details, read the full release notes: http://xarray.pydata.org/en/stable/whats-new.html Contributors to this release: Antony Lee Fabien Maussion Joe Hamman Maximilian Roos Stephan Hoyer Takeshi Kanmae femtotrader I'd a

Re: [Numpy-discussion] Software Capabilities of NumPy in Our Tensor Survey Paper

Robert beat me to it on einsum, but also check tensordot for general tensor contraction. On Fri, Jan 15, 2016 at 9:30 AM, Nathaniel Smith wrote: > On Jan 15, 2016 8:36 AM, "Li Jiajia" wrote: >> >> Hi all, >> I’m a PhD student in Georgia Tech. Recently, we’re working on a survey > paper about t

Re: [Numpy-discussion] Fast Access to Container of Numpy Arrays on Disk?

On Thu, Jan 14, 2016 at 2:30 PM, Nathaniel Smith wrote: > The reason I didn't suggest dask is that I had the impression that > dask's model is better suited to bulk/streaming computations with > vectorized semantics ("do the same thing to lots of data" kinds of > problems, basically), whereas it

Re: [Numpy-discussion] Fast Access to Container of Numpy Arrays on Disk?

On Thu, Jan 14, 2016 at 8:26 AM, Travis Oliphant wrote: > I don't know enough about xray to know whether it supports this kind of > general labeling to be able to build your entire data-structure as an x-ray > object. Dask could definitely be used to process your data in an easy to > describe m

Re: [Numpy-discussion] Dynamic array list implementation

We have a type similar to this (a typed list) internally in pandas, although it is restricted to a single dimension and far from feature complete -- it only has .append and a .to_array() method for converting to a 1d numpy array. Our version is written in Cython, and we use it for performance re

Re: [Numpy-discussion] array of random numbers fails to construct

On Sun, Dec 6, 2015 at 3:55 PM, Allan Haldane wrote: > > I've also often wanted to generate large datasets of random uint8 and > uint16. As a workaround, this is something I have used: > > np.ndarray(100, 'u1', np.random.bytes(100)) > > It has also crossed my mind that np.random.randint and np.r

[Numpy-discussion] Proposal for a new function: np.moveaxis

I've put up a pull request implementing a new function, np.moveaxis, as an alternative to np.transpose and np.rollaxis: https://github.com/numpy/numpy/pull/6630 This functionality has been discussed (even the exact function name) several times over the years, but it never made it into a pull reque

Re: [Numpy-discussion] Nansum function behavior

Hi Charles, You should read the previous discussion about this issue on GitHub: https://github.com/numpy/numpy/issues/1721 For what it's worth, I do think the new definition of nansum is more consistent. If you want to preserve NaN if there are no non-NaN values, you can often calculate this des

Re: [Numpy-discussion] Making datetime64 timezone naive

On Mon, Oct 19, 2015 at 12:34 PM, Chris Barker wrote: > Also -- I think we are at phase one of a (at least) two step process: > > 1) clean up datetime64 just enough that it is useful, and less error-prone > -- i.e. have it not pretend to support anything other than naive datetimes. > > 2) Do it r

Re: [Numpy-discussion] when did column_stack become C-contiguous?

Looking at the git logs, column_stack appears to have been that way (creating a new array with concatenate) since at least NumPy 0.9.2, way back in January 2006: https://github.com/numpy/numpy/blob/v0.9.2/numpy/lib/shape_base.py#L271 Stephan ___ NumPy-Di

[Numpy-discussion] Deprecating unitless timedelta64 and "safe" casting of integers to timedelta64

As part of the datetime64 cleanup I've been working on over the past few days, I noticed that NumPy's casting rules for np.datetime64('NaT') were not working properly: https://github.com/numpy/numpy/pull/6465 This led to my discovery that NumPy currently supports unit-less timedeltas (e.g., "np.ti

Re: [Numpy-discussion] Making datetime64 timezone naive

On Mon, Oct 12, 2015 at 12:38 AM, Nathaniel Smith wrote: > > One possible strategy here would be to do some corpus analysis to find > out whether anyone is actually using it, like I did for the ufunc ABI > stuff: > https://github.com/njsmith/codetrawl > https://github.com/njsmith/ufunc-abi-an

[Numpy-discussion] Making datetime64 timezone naive

As has come up repeatedly over the past few years, nobody seems to be very happy with the way that NumPy's datetime64 type parses and prints datetimes in local timezones. The tentative consensus from last year's discussion was that we should make datetime64 timezone naive, like the standard librar

[Numpy-discussion] Make all comparisons with NaT false?

Currently, NaT (not a time) does not have any special treatment when used in comparison with datetime64/timedelta64 objects. This means that it's equal to itself, and treated as the smallest possible value in comparisons, e.g., NaT == NaT and NaT < any_other_time. To me, this seems a little crazy

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

On Tue, Oct 6, 2015 at 1:14 AM, Daπid wrote: > One idea: what about creating a "parallel numpy"? There are a few > algorithms that can benefit from parallelisation. This library would mimic > Numpy's signature, and the user would be responsible for choosing the > single threaded or the parallel o

Re: [Numpy-discussion] Sign of NaN

On Tue, Sep 29, 2015 at 8:13 AM, Charles R Harris wrote: > Due to a recent commit, Numpy master now raises an error when applying the > sign function to an object array containing NaN. Other options may be > preferable, returning NaN for instance, so I would like to open the topic > for discussio

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

Travis -- have you included all your email addresses in your GitHub profile? When I type git shortlog -ne, I see 2063 commits from your Continuum address that seem to be missing from the contributors page on github. Generally speaking, the git logs tend to be more reliable for these counts. On

Re: [Numpy-discussion] Governance model request

On Tue, Sep 22, 2015 at 2:33 AM, Travis Oliphant wrote: > The FUD I'm talking about is the anti-company FUD that has influenced > discussions in the past.I really hope that we can move past this. > I have mostly stayed out of the governance discussion, in deference to how new I am in this co

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

>From my perspective, a major advantage to dtypes is composability. For example, it's hard to write a library like dask.array (out of core arrays) that can suppose holding any conceivable ndarray subclass (like MaskedArray or quantity), but handling arbitrary dtypes is quite straightforward -- and

Re: [Numpy-discussion] np.sign and object comparisons

On Mon, Aug 31, 2015 at 1:23 AM, Sebastian Berg wrote: > That would be my gut feeling as well. Returning `NaN` could also make > sense, but I guess we run into problems since we do not know the input > type. So `None` seems like the only option here I can think of right > now. > My inclination i

Re: [Numpy-discussion] Numpy helper function for __getitem__?

Indeed, the helper function I wrote for xray was not designed to handle None/np.newaxis or non-1d Boolean indexers, because those are not valid indexers for xray objects. I think it could be straightforwardly extended to handle None simply by not counting them towards the total number of dimensions

Re: [Numpy-discussion] Numpy helper function for __getitem__?

I don't think NumPy has a function like this (at least, not exposed to Python), but I wrote one for xray, "expanded_indexer", that you are welcome to borrow: https://github.com/xray/xray/blob/v0.6.0/xray/core/indexing.py#L10 ​Stephan On Sunday, Aug 23, 2015 at 7:54 PM, Fabien , wrote:

Re: [Numpy-discussion] Flag for np.tile to use as_strided to reduce memory

On Fri, Jun 19, 2015 at 10:39 AM, Sebastian Berg wrote: > No, what tile does cannot be represented that way. If it was possible > you can achieve the same using `np.broadcast_to` basically, which was > just added though. There are some other things you can do, like rolling > window (adding dimens

[Numpy-discussion] ANN: xray v0.5

I'm pleased to announce version 0.5 of xray, N-D labeled arrays and datasets in Python. xray is an open source project and Python package that aims to bring the labeled data power of pandas to the physical sciences, by providing N-dimensional variants of the core pandas data structures. These data

Re: [Numpy-discussion] matmul needs some clarification.

On Sat, May 30, 2015 at 3:23 PM, Charles R Harris wrote: > The problem arises when multiplying a stack of matrices times a vector. > PEP465 defines this as appending a '1' to the dimensions of the vector and > doing the defined stacked matrix multiply, then removing the last dimension > from the

Re: [Numpy-discussion] Proposed deprecations for 1.10: dot corner cases

On Mon, May 11, 2015 at 2:53 PM, Alan G Isaac wrote: > I agree that where `@` and `dot` differ in behavior, this should be > clearly documented. > I would hope that the behavior of `dot` would not change. Even if np.dot never changes (and indeed, perhaps it should not), issuing these warnings s

Re: [Numpy-discussion] Proposed deprecations for 1.10: dot corner cases

On Sat, May 9, 2015 at 1:26 PM, Nathaniel Smith wrote: > I'd like to suggest that we go ahead and add deprecation warnings to > the following operations. This doesn't commit us to changing anything > on any particular time scale, but it gives us more options later. > These both get a strong +1 f

Re: [Numpy-discussion] Bug in np.nonzero / Should index returning functions return ndarray subclasses?

With regards to np.where -- shouldn't where be a ufunc, so subclasses or other array-likes can be control its behavior with __numpy_ufunc__? As for the other indexing functions, I don't have a strong opinion about how they should handle subclasses. But it is certainly tricky to attempt to handl

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Fri, Apr 3, 2015 at 4:54 PM, Nathaniel Smith wrote: > Unfortunately, AFAICT this means our only options here are to have > some kind of backcompat break in numpy, some kind of backcompat break > in pandas, or to do nothing and continue indefinitely with the status > quo where the same indexing

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Fri, Apr 3, 2015 at 10:59 AM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > I have an all-Pyhton implementation of an OrthogonalIndexer class, loosely > based on Stephan's code plus some axis remapping, that provides all the > needed functionality for getting and setting with orthogo

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Thu, Apr 2, 2015 at 11:03 AM, Eric Firing wrote: > Fancy indexing is a horrible design mistake--a case of cleverness run > amok. As you can read in the Numpy documentation, it is hard to > explain, hard to understand, hard to remember. Well put! I also failed to correct predict your exampl

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Wed, Apr 1, 2015 at 7:06 AM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > Is there any other package implementing non-orthogonal indexing aside from > numpy? > I think we can safely say that NumPy's implementation of broadcasting indexing is unique :). The issue is that many other

Re: [Numpy-discussion] Improve Numpy Datetime Functionality for Gsoc

The most recent discussion about datetime64 was back in March and April of last year: http://mail.scipy.org/pipermail/numpy-discussion/2014-March/thread.html#69554 http://mail.scipy.org/pipermail/numpy-discussion/2014-April/thread.html#69774 In addition to unfortunate timezone handling, datetime64

Re: [Numpy-discussion] GSoC students: please read

On Mon, Mar 23, 2015 at 2:21 PM, Ralf Gommers wrote: > It's great to see that this year there are a lot of students interested in > doing a GSoC project with Numpy or Scipy. So far five proposals have been > submitted, and it looks like several more are being prepared now. > Hi Ralf, Is there a

Re: [Numpy-discussion] numpy.stack -- which function, if any, deserves the name?

On Mon, Mar 16, 2015 at 1:50 AM, Stefan Otte wrote: > Summarizing, my proposal is mostly concerned how to create block > arrays from given arrays. I don't care about the name "stack". I just > used "stack" because it replaced hstack/vstack for me. Maybe "bstack" > for block stack, or "barray" for

[Numpy-discussion] numpy.stack -- which function, if any, deserves the name?

In the past months there have been two proposals for new numpy functions using the name "stack": 1. np.stack for stacking like np.asarray(np.bmat(...)) http://thread.gmane.org/gmane.comp.python.numeric.general/58748/ https://github.com/numpy/numpy/pull/5057 2. np.stack for stacking along an arbit

Re: [Numpy-discussion] Custom __array_interface__ error

In my experience writing ndarray-like objects, you likely want to implement __array__ instead of __array_interface__. The former gives you full control to create the ndarray yourself. On Fri, Mar 13, 2015 at 7:22 AM, Daniel Smith wrote: > Greetings everyone, > I have a new project that deals wit

[Numpy-discussion] ANN: xray v0.4 released

I'm pleased to announce a major release of xray, v0.4. xray is an open source project and Python package that aims to bring the labeled data power of pandas to the physical sciences, by providing N-dimensional variants of the core pandas data structures. Our goal is to provide a pandas-like and p

Re: [Numpy-discussion] [SciPy-User] Congratulations to Chris Barker...

Indeed, congratulations Chris! Are there plans to write a vectorized version for NumPy? :) On Mon, Mar 2, 2015 at 2:28 PM, Nathaniel Smith wrote: > ...on the acceptance of his PEP! PEP 485 adds a math.isclose function > to the standard library, encouraging people to do numerically more > reason

Re: [Numpy-discussion] Objects exposing the array interface

On Wed, Feb 25, 2015 at 2:48 PM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > I am not really sure what the behavior of __array__ should be. The link > to the subclassing docs I gave before indicates that it should be possible > to write to it if it is writeable (and probably pandas sh

Re: [Numpy-discussion] Objects exposing the array interface

On Wed, Feb 25, 2015 at 1:24 PM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > 1. When converting these objects to arrays using PyArray_Converter, if > the arrays returned by any of the array interfaces is not C contiguous, > aligned, and writeable, a copy that is will be made. Proper a

Re: [Numpy-discussion] Matrix Class

On Wed, Feb 11, 2015 at 9:19 AM, Sebastian Berg wrote: > On Mi, 2015-02-11 at 11:38 -0500, cjw wrote: > No, I just mean the fact that a matrix is always 2D. This makes some > things like some indexing operations awkward and some functions that > expect a numpy array (but think they can handle sub

Re: [Numpy-discussion] converting a list of tuples into an array of tuples?

It appears that the only reliable way to do this may be to use a loop to modify an object arrays in-place. Pandas has a version of this written in Cython: https://github.com/pydata/pandas/blob/c1a0dbc4c0dd79d77b2a34be5bc35493279013ab/pandas/lib.pyx#L342 To quote Wes McKinney "Seriously can't belie

[Numpy-discussion] New function: np.stack?

There are two usual ways to combine a sequence of arrays into a new array: 1. concatenated along an existing axis 2. stacked along a new axis For 1, we have np.concatenate. For 2, we have np.vstack, np.hstack, np.dstack and np.column_stack. For arrays with arbitrary dimensions, there is the np.arr

  1   2   >