Re: [Numpy-discussion] PyData Barcelona this May

On Thu, 2017-03-09 at 15:45 +0100, Jaime Fernández del Río wrote: > There will be a PyData conference in Barcelona this May: > > http://pydata.org/barcelona2017/ > > I am planning on attending, and was thinking of maybe proposing to > organize a numpy-themed workshop or tutorial. > > My

Re: [Numpy-discussion] vectorization vs. numpy.linalg (shape (3, 3, 777) vs shape (777, 3, 3))

ome cases were you can out-smart numpy, and of course in general choosing the right memory order can have a huge impact on your performance. But again, trying to out-smart also comes at a cost and I would be very reluctant to do it, and typically there are probably lower hanging fruits to get first

Re: [Numpy-discussion] vectorization vs. numpy.linalg (shape (3, 3, 777) vs shape (777, 3, 3))

use-case, but if you have an operation on many 3x3 arrays the way numpy does it is the more natural way. If you do other things that are faster the other way around, you will have to decide which operation is the more important one overall. - Sebastian > (I came across this when having to rearr

Re: [Numpy-discussion] Numpy Overhead

Thank you! That is the information I needed. 2017-03-01 0:18 GMT+01:00 Matthew Brett <matthew.br...@gmail.com>: > Hi, > > On Tue, Feb 28, 2017 at 3:04 PM, Sebastian K > <sebastiankas...@googlemail.com> wrote: > > Yes you are right. There is no ne

Re: [Numpy-discussion] Numpy Overhead

before being immediately discarded. > > -Joe > > On Tue, Feb 28, 2017 at 5:57 PM, Sebastian K <sebastiankaster@googlemail. > com> wrote: > >> Yes it is true the execution time is much faster with the numpy function. >> >> The Code for numpy version: &g

Re: [Numpy-discussion] Numpy Overhead

eap peak pure python3: 1060565 heap peakt numpy function: 4917180 2017-02-28 23:17 GMT+01:00 Matthew Brett <matthew.br...@gmail.com>: > Hi, > > On Tue, Feb 28, 2017 at 2:12 PM, Sebastian K > <sebastiankas...@googlemail.com> wrote: > > Thank you for your answer. > &

Re: [Numpy-discussion] Numpy Overhead

7.org/linux/man-pages/man3/realloc.3.html>, *length* arguments of mmap(2) <http://man7.org/linux/man-pages/man2/mmap.2.html>, and *new_size* arguments of mremap(2) <http://man7.org/linux/man-pages/man2/mremap.2.html>. Regards Sebastian On 28 Feb 2017 11:03

[Numpy-discussion] Numpy Overhead

Hello everyone, I'm interested in the numpy project and tried a lot with the numpy array. I'm wondering what is actually done that there is so much overhead when I call a function in Numpy. What is the reason? Thanks in advance. Regards Sebastian Kaster

Re: [Numpy-discussion] Default type for functions that accumulate integers

by Julian, so maybe it is time to give it a shot It would be interesting to see if anyone knows projects that may be affected (for example because they are designed to only run on windows or limited hardware), and if avoiding to change anything in python 2 might mitigate problems here a

Re: [Numpy-discussion] Casting to np.byte before clearing values

, but I guess it is not too surprising and may depend on other things as well. - Sebastian > > # Native float > Z_float = np.ones(100, float) > Z_int   = np.ones(100, int) > > %timeit Z_float[...] = 0 > 1000 loops, best of 3: 361 µs per loop > > %timeit Z

Re: [Numpy-discussion] Does numpy.bincount support numpy.float128 type weights?

) np.add.at(res, b, a) ``` will work, but do not expect it to be fast. - Sebastian On Do, 2016-12-01 at 05:54 +0800, Wei, Huayi wrote: > Hi, There, > > Here is a sample code using `numpy.bincount` > >  import numpy as np >  a = np.array([1.0, 2.0, 3.0], dtype=np.float128) &

Re: [Numpy-discussion] Numpy 1.12.x branched

beta > release in a couple of days. > Very cool, thanks for all the hard work! - Sebastian > Chuck > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion signature.

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

perations look identical and I thought np.sum just calls > np.add.reduce, so the reduction step uses the same code and would > therefore have the same accuracy. > Sorry, did not read it carefully, I guess `c` is the mean, so you are doing the two pass method. - Sebastian > Thanks >

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

ht be mixing up things, however, IIRC the single pass approach has a bad numerical accuracy, so that I doubt that it is a good default algorithm. - Sebastian > Thank you, > Matt > ___ > NumPy-Discussion mailing list > NumPy-Discuss

Re: [Numpy-discussion] Intel random number package

t feeling would be that a backend change (if the default stream changes, an explicit one, though maybe one could make a "fastest") would be the only reasonable way to provide such a thing in numpy itself. - Sebastian > -- > Robert Kern > _

Re: [Numpy-discussion] fpower ufunc

On Fr, 2016-10-21 at 09:45 +0200, Sebastian Berg wrote: > On Do, 2016-10-20 at 21:38 -0600, Charles R Harris wrote: > > > > > > > > On Thu, Oct 20, 2016 at 9:11 PM, Nathaniel Smith <n...@pobox.com> > > wrote: > > > > > > On Thu, Oct

Re: [Numpy-discussion] fpower ufunc

flow and such. My thought > was that float32 is something of a "specialized" type these days, > while float64 is the standard floating point precision for everyday > computation. > Isn't the behaviour we already have (e.g. such as mean). ints -> float64 inexacts do not ge

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

ly odd to me to be honest. Just brain storming, you could think/name it the other way around maybe? Should the masked values be considered as zero/ignored? - Sebastian > Cheers, > Allan > > ___ > NumPy-Discussion mailing list >

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

how downstream would handle it. Also would we need an int power? The fpower seems more straight forward/common pattern. If errors turned out annoying in some cases, a seterr might be plausible too (as well as a deprecation). - Sebastian > Pluses > Backward compatible > Allows common powe

Re: [Numpy-discussion] [7949] How to handle these deprecation Warning errors

those slots. The threading warnings seem also quite noisy (and useless), but not sure right away what the best approach for that would be. - Sebastian > But now these errors must be either fixed or skipped. This is where I > am facing problem. Pls suggest: > > 1. Identify that pytho

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

can maybe default to unicode in more cases in python 3, but you cannot make them identical internally. What about giving `np.loadtxt` an encoding kwarg or something along that line? - Sebastian > > Is it acceptable to internally just translate all appearances of 'S' > (NPY_STRING) to '

Re: [Numpy-discussion] New iterator APIs (nditer / MapIter): Overlap detection in NumPy

On Mo, 2016-09-12 at 20:22 +, Pauli Virtanen wrote: > Mon, 12 Sep 2016 11:31:07 +0200, Sebastian Berg kirjoitti: > > > > > > > > * NPY_ITER_COPY_IF_OVERLAP, NPY_ITER_OVERLAP_NOT_SAME > > >   flags for NpyIter_New. > > > > > >

Re: [Numpy-discussion] New iterator APIs (nditer / MapIter): Overlap detection in NumPy

the worst API clutter in history. > > Continuation here: https://github.com/numpy/numpy/pull/8043 > > > > Wed, 07 Sep 2016 18:02:59 +0200, Sebastian Berg kirjoitti: > > > > > Hi all, > > > > Pauli just opened a nice pull request [1] to add overla

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

On So, 2016-09-11 at 11:19 -0400, Marten van Kerkwijk wrote: > There remains the option to just let subclasses deal with new ndarray > features...  Certainly, for `Quantity`, I'll quite happily do that. > And if it alllows the ndarray code to remain simple and efficient, it > is probably the best

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

e tests for things like masked array correctly calling the `_data` subclass, but if the `_data` subclass does not implement the new method, numpy would have to run in circles (or something) - Sebastian > In the end, though, probably also too complicated. It may remain best > to simply

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

On Sa, 2016-09-10 at 12:01 +0200, Sebastian Berg wrote: > Hi all, > > from the discussion, I was thinking maybe something like this: > > class B(): >    def __numpy_getitem__(self, index, indexing_method="plain"): >        # do magic. >        return super().__n

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

r a normal method. Can anyone think of a nicer way to do this trick that does not require quite as much hackery. Or is there an easy way to do the overloading check? - Sebastian signature.asc Description: This is a digitally signed message part ___ NumPy-

Re: [Numpy-discussion] New iterator API (nditer): Overlap detection in NumPy

On Mi, 2016-09-07 at 09:22 -0700, Nathaniel Smith wrote: > On Sep 7, 2016 9:03 AM, "Sebastian Berg" <sebast...@sipsolutions.net> > wrote: > > > > Hi all, > > > > Pauli just opened a nice pull request [1] to add overlap detection > to > >

[Numpy-discussion] New iterator API (nditer): Overlap detection in NumPy

. If there are no comments, I will probably merge it very soon, so we can look at the follow up things. - Sebastian [1] https://github.com/numpy/numpy/pull/8026 signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list

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

up. Sure, it would be a solution, but not sure it is any better implementation wise then just passing an extra argument. As for the syntax for plain arrays, I am not convinced to be honest. - Sebastian > In the end, though, probably also too complicated. It may remain best > to simply imp

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

On Di, 2016-09-06 at 10:10 -0700, Stephan Hoyer wrote: > On Mon, Sep 5, 2016 at 6:02 PM, Marten van Kerkwijk 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

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

On Di, 2016-09-06 at 10:57 +0100, Robert Kern wrote: > On Tue, Sep 6, 2016 at 8:46 AM, Sebastian Berg <sebastian@sipsolution > s.net> wrote: > > > > On Di, 2016-09-06 at 09:37 +0200, Sebastian Berg wrote: > > > On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwij

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

On Di, 2016-09-06 at 09:37 +0200, Sebastian Berg wrote: > On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > > > > Actually, on those names: an alternative to your proposal would be > > to > > introduce only one new method which can do all types of indexing,

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

On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > Actually, on those names: an alternative to your proposal would be to > introduce only one new method which can do all types of indexing, > depending on a keyword argument, i.e., something like > ``` > def getitem(self, item,

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

On Mo, 2016-09-05 at 21:02 -0400, Marten van Kerkwijk 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! Hehe, yes but see MaskedArrays. They need logic to also index the

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

On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > Actually, on those names: an alternative to your proposal would be to > introduce only one new method which can do all types of indexing, > depending on a keyword argument, i.e., something like > ``` > def getitem(self, item,

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

On Mo, 2016-09-05 at 18:19 -0500, Nathan Goldbaum wrote: > > > On Monday, September 5, 2016, Marten van Kerkwijk <m.h.vankerkwijk@gm > ail.com> wrote: > > Hi Sebastian, > > > > It would seem to me that any subclass has to keep up to date with > > new

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

On Mo, 2016-09-05 at 18:24 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > It would seem to me that any subclass has to keep up to date with new > features in ndarray, and while I think ndarray has a responsibility > not to break backward compatibility, I do not think it

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

On Mo, 2016-09-05 at 14:54 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > Indeed, having the scalar pass through `__array_wrap__` would have > been useful (_finalize__ is too late, since one cannot change the > class any more, just set attributes).  But that is water und

Re: [Numpy-discussion] Correct error of invalid axis arguments.

ut arrays all in one go). Putting explicit guards to every single python side function is of course possible too, but I am not quite convinced its worth the trouble. - Sebastian > Chuck > ___ > NumPy-Discussion mailing list > NumPy-Discussi

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

On So, 2016-09-04 at 11:20 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > I haven't given this as much thought as it deserves, but thought I > would comment from the astropy perspective, where we both have direct > subclasses of `ndarray` (`Quantity`, `Column`

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

On So, 2016-09-04 at 14:10 +0200, Sebastian Berg wrote: > On Sa, 2016-09-03 at 21:08 +0200, Sebastian Berg wrote: > > > > Hi all, > > > > not that I am planning to spend much time on this right now, > > however, > > I > > did a small rebase of

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

On Sa, 2016-09-03 at 21:08 +0200, Sebastian Berg wrote: > Hi all, > > not that I am planning to spend much time on this right now, however, > I > did a small rebase of the stuff I had (did not push yet) on oindex > and > remembered the old problem ;). > > The

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

think of things, but nothing too great yet so maybe you guys got an elegant idea. - Sebastian signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

How do these two relate to each other !? - Sebastian On Fri, Sep 2, 2016 at 12:33 PM, Carl Kleffner <cmkleff...@gmail.com> wrote: > maybe https://bitbucket.org/memotype/cffiwrap or https://github.com/ > andrewleech/cfficloak helps? > > C. > > > 2016-09-02 11:16 G

Re: [Numpy-discussion] Which NumPy/Numpy/numpy spelling?

g how to use NumPy, see also NumPy User Guide." > That's technically a bug: the official spelling is NumPy.  But, no > one > really cares :) > I like the fact that this is all posted in: [Numpy-discussion] ;). - Sebastian > Stéfan > > _

Re: [Numpy-discussion] Indexing issue with ndarrays

On Fr, 2016-08-26 at 09:57 -0400, Joseph Fox-Rabinovitz wrote: > > > On Thu, Aug 25, 2016 at 4:37 PM, Sebastian Berg <sebastian@sipsolutio > ns.net> wrote: > > On Do, 2016-08-25 at 10:36 -0400, Joseph Fox-Rabinovitz wrote: > > > This issue recently came up on S

Re: [Numpy-discussion] Indexing issue with ndarrays

caught earlier) -> convert to `intp` array and do integer indexing. Now you might wonder why, but probably it is quite simply because boolean indexing was tagged on later. - Sebastian > In my attempt to reproduce the poster's results, I got the following > warning: > Futu

Re: [Numpy-discussion] How to trigger warnings for integer division in python 2

e effort (I suppose it is likely only a few places). I am not sure how easy they are on the C side, but probably not difficult at all. - Sebastian > Thanks, > Stuart > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scip

Re: [Numpy-discussion] Views and Increments

[1,6,5])] + 1 a[np.array([1,6,5])] = tmp this is done by python, without any interplay of numpy at all. Which is different from `arr += 1`, which is specifically defined and translates to `np.add(arr, 1, out=arr)`. - Sebastian > Best, >   ab >

[Numpy-discussion] Euroscipy

Hi all, I am still pondering whether or not (and if which days) to go to EuroScipy. Who else is there and would like to discuss a bit or whatever else? - Sebastian signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion

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

py can be easily put into it. Anyway, it seems like a great project to have as much support for type annotations as possible. I have never used them, but with editors picking up on these things it sounds like it could be very useful in the future. - Sebastian > We're doing the work anywa

Re: [Numpy-discussion] Custom Dtype/Units discussion

n send a few notes. Have some nice last days at SciPy! - Sebastian > On Thursday, July 14, 2016, Nathan Goldbaum <nathan12...@gmail.com> > wrote: > > > > > > On Thu, Jul 14, 2016 at 11:05 AM, Nathaniel Smith <n...@pobox.com> > > wrote: > > >

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

1D, fill in `1` and `2`, if 2D, fill in only `2` (0D, add everything of course). However, I have my doubts that it is actually easier to understand then to write yourself ;). - Sebastian   > don't know how many dimensions are going to be added. If you knew, > then you wouldn't be calling t

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

D case, but then it is likely more trouble then gain. - Sebastian > ``` > np.array(a, copy=False, ndim=n) > ``` > or, for a list of inputs, > ``` > [np.array(a, copy=False, ndim=n) for a in input_list] > ``` > > All the best, > > Marten >

Re: [Numpy-discussion] Is numpy.test() supposed to be multithreaded?

more sense would be to compare some of the benchmarks `python runtests.py --bench` if you have airspeed velocity installed. While not extensive, a lot of those things at least do test more typical use cases. Though in any case I think the user should probably just test some other thing. - Seba

Re: [Numpy-discussion] Support of '@='?

rious why it is an error at the moment. We can't have it be filled in by python to be not in-place (`M = M @ P` meaning), but copying over the result is a bit annoying and nobody was quite sure about it, so it was delayed. - Sebastian signature.asc Description: This is a digitally signed mes

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

2.0**53). Obviously even this is not 100% > true, but I think it is the original intent. > Except for int types, which force a result type large enough to hold the input value. > My suspicion is that a better rule would be: *Python* types (int, > float, bool) are treated as having a

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

integers on 64 bit windows is a bit odd. > Anyway, hopefully that's not too off-topic. > Best, I agree, at least on python3 (the reason is that python 3, the subclass thingy goes away, so it is less likely to break anything). I think we could have a shot at this, it is quirky, but the current i

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

On Di, 2016-06-07 at 00:32 +0200, Jaime Fernández del Río wrote: > On Mon, Jun 6, 2016 at 9:35 AM, Sebastian Berg <sebastian@sipsolution > s.net> wrote: > > On So, 2016-06-05 at 19:20 -0600, Charles R Harris wrote: > > > > > > > > > On Sun, Jun 5, 201

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

ge it to x and put it in the middle: matxvec, vecxmat, vecxvec. > Were not some of this part of the gufunc linalg functions and we just removed it because we were not sure about the API? Not sure anymore, but might be worth to have a look. - Sebastian > Chuck   &

[Numpy-discussion] Developer Meeting at EuroScipy?

difficulties with this? Regards, Sebastian signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Changing FFT cache to a bounded LRU cache

ieves everything that the fftcache was designed for and we could even just disable it as default? The complexity addition is a bit annoying I must admit, on python 3 functools.lru_cache could be another option, but only there. - Sebastian > > Cheers! > > Lion > __

Re: [Numpy-discussion] (no subject)

"easy" but I would not guarantee all of them are, sometimes there are unexpected difficulties or it is easy if you already know where to look). - Sebastian > Regards, > Saumyajit > > Saumyajit Dey > Junior Undergraduate Student: > Department of Computer Science

Re: [Numpy-discussion] Do getitem/setitem already have GIL?

am just poking at it here, could be all wrong. - Sebastian On Mi, 2016-04-20 at 19:22 +, Steve Mitchell wrote: > When writing custom PyArray_ArrFuncs getitem() and setitem(), do I > need to acquire the GIL, or has it been done for me already by the > caller? > > --S

Re: [Numpy-discussion] f2py: ram usage

be to create your array in python with the `order="F"` flag. NumPy will have a tendency to prefer C-order and uses it as default though when doing something with an "F" ordered array. That said, I have never used f2py, so these are just well founded guesses. - Sebastian > Is

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Do, 2016-04-07 at 13:29 -0400, josef.p...@gmail.com wrote: > > > On Thu, Apr 7, 2016 at 1:20 PM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > On Do, 2016-04-07 at 11:56 -0400, josef.p...@gmail.com wrote: > > > > > > > > > >

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

sly looks easier then before? With the `@` operator that was the case, with the "dimension adding logic" I am not so sure, plus it seems it may add other pitfalls. - Sebastian > >>> np.concatenate(([[1,2,3]], [4,5,6])) > Traceback (most recent call last):

Re: [Numpy-discussion] Multidimension array access in C via Python API

On Di, 2016-04-05 at 20:19 +0200, Sebastian Berg wrote: > On Di, 2016-04-05 at 09:48 -0700, mpc wrote: > > The idea is that I want to thin a large 2D buffer of x,y,z points > > to > > a given > > resolution by dividing the data into equal sized "cubes" (i.e.

Re: [Numpy-discussion] Multidimension array access in C via Python API

ases). And if you search for what you want to do first, you may find faster solutions easily, batteries included and all, there are a lot of tools out there. The other point is, don't optimize much if you don't know exactly what you need to optimize. - Sebastian > > *# Fill u

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

On Mi, 2016-03-23 at 10:02 -0400, Joseph Fox-Rabinovitz wrote: > 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

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

> >[[20], [21, 21, 23, 24], [25, 26, 27], [28, 29]]], > > dtype=object) > > > > Apply [`np.stack`](http://docs.scipy.org/doc/numpy-1.10.0/reference/g > enerated/numpy.stack.html#numpy.stack) > to the result. It will merge the arrays the way you want. &

Re: [Numpy-discussion] GSoC?

ere a simplest available algorithm for detecting > if arrays overlap was added. However, this is not yet > utilized in ufuncs. An initial attempt to sketch what > should be done is at https://github.com/numpy/numpy/issues/6272 > and issues referenced therein. > Since I like the idea, I

Re: [Numpy-discussion] How to check for memory leaks?

maybe it shows something. Unfortunately, I got the error below midway, I ran it before successfully (with only minor obvious leaks due to things like module wide strings) I think. My guess is, the error does not say much at all, but I have no clue :) (running without track-origins now, maybe it helps

Re: [Numpy-discussion] reshaping empty array bug?

On Di, 2016-02-23 at 21:06 +0100, Sebastian Berg wrote: > On Di, 2016-02-23 at 14:57 -0500, Benjamin Root wrote: > > I'd be more than happy to write up the patch. I don't think it > > would > > be quite like make zeros be ones, but it would be along those > > lines. >

Re: [Numpy-discussion] reshaping empty array bug?

1 and the shape is 0 convert the 1 back to 0. But it is starting to sound a bit tricky, though I think it might be straight forward (i.e. no real traps and when it works it always is what you expect). The main point is, whether you can design cases where the conversion back to 0 hides

Re: [Numpy-discussion] reshaping empty array bug?

1 for all zeros in both input and output shape for the -1 calculation), maybe we could do it. I would like someone to think about it carefully that it would not also allow some unexpected generalizations. And at least I am getting a BrainOutOfResourcesError right now trying to figure that out :). -

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

stuff, and I guess the idea is likely a bit too fancy for wide application. - Sebastian > On Wed, Feb 17, 2016 at 9:27 PM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > On Mi, 2016-02-17 at 22:10 +0100, Sebastian Berg wrote: > > > On Mi, 2016-02-17 at 20:48 +0

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

On Mi, 2016-02-17 at 22:10 +0100, Sebastian Berg wrote: > On Mi, 2016-02-17 at 20:48 +, Robert Kern wrote: > > On Wed, Feb 17, 2016 at 8:43 PM, G Young <gfyoun...@gmail.com> > > wrote: > > > > > Josef: I don't think we are making people think more. They're

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

huge numbers because you happened to have a `low=0` in there. Especially your point 2) seems confusing. As for 3) if I see `np.random.randint(high=3)` I think I would assume [0, 3) Additionally, I am not sure the maximum int range is such a common need anyway? - Sebastian > -- > Ro

Re: [Numpy-discussion] PyData Madrid

nk of right now). That NEP and code is sitting there after all with a decent chunk done and pretty much working (though relatively far from finished with testing and subclasses). Plus we have to make sure we get the details right, and there a talk may really help too :). - Sebastian

Re: [Numpy-discussion] NumPy 1.11.0b3 released.

for lists. We had open bug reports about it. Of course I dislike it in any case ;), but that is the reasoning behind being a bit more restrictive for `__index__`. - Sebastian > > (In the current case a cryptic exception would be raised if the >

Re: [Numpy-discussion] Subclassing ma.masked_array, code broken after version 1.9

is hard to make good calls. It is a not the easiest code base and any feedback or nudging is important. A new release is about to come out, and if you feel it there is a serious regression, we may want to push for fixing it (or even better, you may have time to suggest a fix yourself). - Sebas

Re: [Numpy-discussion] Suggestion: special-case np.array(range(...)) to be faster

the old iteration protocol > Numpy currently uses PySequence_Fast, but it has to do a two pass algorithm (find dtype+dims), and the range is converted twice to list by this call. That explains the speed advantage of converting to list manually. - Sebastian > np.array(C()) > ===>

Re: [Numpy-discussion] resizeable arrays using shared memory?

ing the same data that is just larger? Since you have the mmap, that would be creating a new view into it. I.e. your "array" would be the memmap, and to use it, you always rewrap it into a new numpy array. Other then that, you would have to mess with the internal ndarray structure,

Re: [Numpy-discussion] Numpy 1.11.0b1 is out

On Sa, 2016-01-30 at 20:27 +0100, Derek Homeier wrote: > On 27 Jan 2016, at 1:10 pm, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > > > On Mi, 2016-01-27 at 11:19 +, Nadav Horesh wrote: > > > Why the dot function/method is slower than @ on pyth

Re: [Numpy-discussion] Bump warning stacklevel

are already correct in this regard automatically. Anyway, I still think it is worth it, even if in practice a lot of warnings are such things as ufunc warnings from inside a python func. And there is no real way to change that, that I am aware of, unless maybe we add a warning_stacklevel argument to

[Numpy-discussion] Bump warning stacklevel

dard about this, but I would expect that for a library such as numpy, it makes sense to change. But, if downstream uses warning filters with modules, we might want to reconsider for example. - Sebastian signature.asc Description: This is a digitally signed me

Re: [Numpy-discussion] Bump warning stacklevel

On 2016-01-27 21:01, Ralf Gommers wrote: On Wed, Jan 27, 2016 at 7:26 PM, Sebastian Berg <sebast...@sipsolutions.net> wrote: Hi all, in my PR about warnings suppression, I currently also have a commit which bumps the warning stacklevel to two (or three), i.e. use: warning

Re: [Numpy-discussion] Numpy 1.11.0b1 is out

ly faster in the @ case (since it has SSE2 optimization by using einsum, while np.dot does not do that). Btw. thanks for all the work getting this done Chuck! - Sebastian > > > np.__version__ > Out[39]: '1.11.0.dev0+Unknown' > > > %timeit A @ c > 1 loops, best of 3: 185

Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy v1.10.X

d far more, and the fact that it is hidden away with an underscore, I am not sure we should prioritize that it would keep working, considering that I am unsure that it ever did something very elegantly. - Sebastian > Jeremy > > From: NumPy-Discussion <numpy-discussion-boun...@scipy.org> on beh

[Numpy-discussion] Testing warnings

gs filters in tests. The current state makes finding warnings given in our own tests almost impossible, in the best case they will have to be fixed much much later when the change actually occurs, in the worst case we never find our own real bugs. So where to go? :) - Sebastian [1] I need to fix

Re: [Numpy-discussion] Make as_strided result writeonly

On Mo, 2016-01-25 at 16:11 +0100, Sturla Molden wrote: > On 23/01/16 22:25, Sebastian Berg wrote: > > > Do you agree with this, or would it be a major inconvenience? > > I think any user of as_strided should be considered a power user. > This > is an inherently dang

Re: [Numpy-discussion] Make as_strided result writeonly

have experience of beeing badly bitten, myself. Would you think it is fine if setting the flag to true would work in your case? > On Sun, Jan 24, 2016 at 8:17 PM, Sebastian Berg <sebast...@sipsolutions.net> > wrote: > > > On So, 2016-01-24 at 13:00 +1100, Juan Nunez-Iglesi

Re: [Numpy-discussion] Make as_strided result writeonly

y there is one more thing I might do. And that is issue a UserWarning when new array quite likely points to invalid memory. - Sebastian [1] as_strided does not currently support arr.flags.writable = True for its result array. > On Sun, Jan 24, 2016 at 9:20 AM, Nathaniel Smith <n...@pobox.c

[Numpy-discussion] Make as_strided result writeonly

you agree with this, or would it be a major inconvenience? - Sebastian signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

On Do, 2016-01-21 at 09:38 +, Robert Kern wrote: > On Tue, Jan 19, 2016 at 5:35 PM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > > > On Di, 2016-01-19 at 16:28 +, G Young wrote: > > > In rand range, it raises an exception if low >=

[Numpy-discussion] Set FutureWarnings to error in (dev) tests?

]. Anyway, should we attempt to do this? I admit that trying to make it work, even *with* the change FutureWarnings suddenly pop up when you make the warnings being given less often (I will guess that warning was already issued at import time somewhere). - Sebastian [1] And at that a brand new future

Re: [Numpy-discussion] Set FutureWarnings to error in (dev) tests?

On Do, 2016-01-21 at 16:15 -0800, Nathaniel Smith wrote: > On Thu, Jan 21, 2016 at 4:05 PM, Sebastian Berg > <sebast...@sipsolutions.net> wrote: > > Hi all, > > > > should we try to set FutureWarnings to errors in dev tests? I am > > seriously annoyed by

Re: [Numpy-discussion] Set FutureWarnings to error in (dev) tests?

oh noe not ignore! which also still prints other warnings. - sebastian > On Jan 21, 2016 5:00 PM, "Sebastian Berg" <sebast...@sipsolutions.net > > wrote: > > On Do, 2016-01-21 at 16:51 -0800, Nathaniel Smith wrote: > > > On Thu, Jan 21, 2016 at 4:44 PM, Sebasti

  1   2   3   4   5   6   7   8   9   >