[Numpy-discussion] Advanced numpy tutorial for SciPy?

so it would be good as part of an advanced numpy tutorial. I don't have the bandwidth to put together an entire tutorial, but maybe someone would like to join forces? Or if someone is already planning an advanced numpy tutorial, perhaps I could contribute. Not much time left to g

Re: [Numpy-discussion] PyData Barcelona this May

techniques to write faster, more efficient code. > I'd go! And nice title :-) Any thoughts on a similar one for SciPy in Austin? -CHB > Let's see what the organizers think of it... > > Jaime > > > On Fri, Mar 17, 2017 at 10:59 PM, Ralf Gommers > wrote: >

Re: [Numpy-discussion] PyData Barcelona this May

On Fri, Mar 17, 2017 at 4:37 AM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > >- many people that use numpy in their daily work don't know what >strides are, this was a BIG surprise for me. > > Based on that experience, I was thinking that maybe a good topic for a > workshop wo

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

On Tue, Feb 21, 2017 at 3:05 PM, Alex Rogozhnikov < alex.rogozhni...@yandex.ru> wrote: > a question about numpy.recarray: > There is a parameter order in constructor https://docs.scipy.org/doc/ > numpy-1.10.1/reference/generated/numpy.recarray.html, but it seems to > have no effect: > x = numpy.re

Re: [Numpy-discussion] From Python to Numpy

> It seems a generalized ufunc "all_equal" with signature (i),(i)->() and short > circuit logic once the first non equal element is encountered would be an > important performance improvement. How does array_equal() perform? -CHB ___ NumPy-Discussion

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

On Mon, Dec 26, 2016 at 1:34 AM, Nicolas P. Rougier < nicolas.roug...@inria.fr> wrote: > > I'm trying to understand why viewing an array as bytes before clearing > makes the whole operation faster. > I imagine there is some kind of special treatment for byte arrays but I've > no clue. > I notice

Re: [Numpy-discussion] From Python to Numpy

Nicolas, >From a quick glance, this looks really wonderful! I intend to point my students that are interested in numpy to it. -CHB On Thu, Dec 22, 2016 at 8:44 AM, Nicolas P. Rougier < nicolas.roug...@inria.fr> wrote: > > Dear all, > > I've just put online a (kind of) book on Numpy and more sp

Re: [Numpy-discussion] Ensuring one can operate on array-like argument in place

I tend to use ndarray.copy() in python code -- no reason you couldn't do the same in Cython. If you want to take any array-like object that may not have a copy() method, you could call asanyarray() first: -CHB On Sat, Nov 12, 2016 at 9:00 AM, Pavlyk, Oleksandr < oleksandr.pav...@intel.com> w

Re: [Numpy-discussion] array comprehension

On Fri, Nov 4, 2016 at 10:36 AM, Nathaniel Smith wrote: > On Nov 4, 2016 10:32 AM, "Stephan Hoyer" wrote: > > fromiter dynamically resizes a NumPy array, like a Python list, except > with a growth factor of 1.5 > > Oh, right, and the dtype argument is mandatory, which is what makes this > poss

Re: [Numpy-discussion] NumPy 1.11.2 released

I'm pleased to announce the release of Numpy 1.11.2. This release supports > Python 2.6 - 2.7, and 3.2 - 3.5 and fixes bugs and regressions found in > Numpy 1.11.1. Wheels for Linux, Windows, and OSX can be found on PyPI. > Sources are available on both PyPI and Sourceforge >

Re: [Numpy-discussion] automatically avoiding temporary arrays

On Mon, Oct 3, 2016 at 3:16 AM, Julian Taylor wrote: > the problem with this approach is that we don't really want numpy > hogging on to hundreds of megabytes of memory by default so it would > need to be a user option. > indeed -- but one could set an LRU cache to be very small (few items, not

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: > Great, that's the type of info I wanted to get before going forward. I > guess > there's code relying on the binary representation of 'S' to do mmap's or > access > the array's raw contents. Is that right? yes, there is a LOT of code, mo

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

We had a big long discussion about this on this list a while back (maybe 2 yrs ago???) please search the archives to find it. Though I'm pretty sure that we never did come to a conclusion. I think it stared with wanting better support ofr unicode in loadtxt and the like, and ended up delving into o

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

it may do a scalar computation, and you want to apply it to an entire numpy array, at C speed. Either would work in this case, But I like Cyton better, as long as I don't have compilation issues. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/N

Re: [Numpy-discussion] NumPy in PyPy

> > On Fri, Aug 5, 2016 at 3:42 AM, Papa, Florin >> wrote: >> >>> Does anyone have knowledge of real life workloads that use NumPy and >>> cannot be run using PyPy? >>> >>> >>> >>> We are also interested in creating a repository with relevant benchmarks >>> for real world usage of NumPy, >>> >> W

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

On Sun, Jul 10, 2016 at 8:12 PM, Nathan Goldbaum wrote: > > Maybe this can be an informal BOF session? > or maybe a formal BoF? after all, how formal do they get? Anyway, it was my understanding that we really needed to do some significant refactoring of how numpy deals with dtypes in order to

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

> Now the user is writing back to say, "my test code is fast now, but > numpy.test() is still about three times slower than don't manage>". When I watch htop as numpy.test() executes, sure enough, > it's using one core > * if numpy.test() is supposed to be using multiple cores, why isn't it, > w

Re: [Numpy-discussion] Accelerate or OpenBLAS for numpy / scipy wheels?

On Tue, Jun 28, 2016 at 8:15 AM, Matthew Brett wrote: > > dropping the dual arch stuff is probably the way to go - the 32-bit > builds > > make very little sense these days. > > Yes, that's true, but as you know, the OSX system and Python.org > Pythons are still dual arch, so technically a matchi

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

On Sun, May 22, 2016 at 2:35 AM, Robert Kern wrote: > > Well, I mean, engineers want lots of things. I suspect that most engineers > *really* just want to call `numpy.random.seed(8675309)` at the start and > never explicitly pass around separate streams. There's an upside to that in > terms of cod

Re: [Numpy-discussion] Scipy 2016 attending

I'll be there. -CHB On Wed, May 18, 2016 at 2:09 PM, Charles R Harris wrote: > Hi All, > > Out of curiosity, who all here intends to be at Scipy 2016? > > Chuck > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy

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

> > > ...anyway, the real reason I'm a bit grumpy is because there are solid > > engineering reasons why users *want* this API, > Honestly, I am lost in the math -- but like any good engineer, I want to accomplish something anyway :-) I trust you guys to get this right -- or at least document what

Re: [Numpy-discussion] nan version of einsum

to making numpy/python fast, and coming from MATLAB am very impressed, though there are a bewlidering number of options when it comes to trying to optimize. Thanks, Chris On Tue, Apr 19, 2016 at 11:12 AM, Chris Barber wrote: > Is there any interest in a nan-ignoring version of einsum a la nans

[Numpy-discussion] nan version of einsum

Is there any interest in a nan-ignoring version of einsum a la nansum, nanprod, etc? Any idea how difficult it would be to implement? - Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy

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

On Fri, Apr 8, 2016 at 4:37 PM, Ian Henriksen < insertinterestingnameh...@gmail.com> wrote: > If we introduced the T2 syntax, this would be valid: > > a @ b.T2 > > It makes the intent much clearer. > would: a @ colvector(b) work too? or is T2 generalized to more than one column? (though I sup

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

On Fri, Apr 8, 2016 at 9:59 AM, Charles R Harris wrote: > Apropos column/row vectors, I've toyed a bit with the idea of adding a > flag to numpy arrays to indicate that the last index is one or the other, > and maybe neither. > I don't follow this. wouldn't it ony be an issue for 1D arrays, rath

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

On Thu, Apr 7, 2016 at 11:31 AM, wrote: > maybe a warning? >> > > AFAIR, there is a lot of code that works correctly with .T being a noop > for 1D > e.g. covariance matrix/inner product x.T dot y as mentioned before. > oh well, then no warning, either. > write unit tests with non square 2d arr

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

On Thu, Apr 7, 2016 at 10:00 AM, Ian Henriksen < insertinterestingnameh...@gmail.com> wrote: > Here's another example that I've seen catch people now and again. > > A = np.random.rand(100, 100) > b = np.random.rand(10) > A * b.T > typo? that was supposed to be b = np.random.rand(100). yes? Th

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

On Thu, Apr 7, 2016 at 8:13 AM, Todd wrote: > First you need to turn a into a 2D array. I can think of 10 ways to do > this off the top of my head, and there may be more: > > snip Basically, my argument here is the same as the argument from pep465 for the > inclusion of the @ operator: > > http

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

On Wed, Apr 6, 2016 at 10:47 AM, Todd wrote: > > I think that cat is already out of the bag. As long as you can do matrix > multiplication on arrays using the @ operator, I think they aren't really > "pure" anymore. > not really -- you still need to use arrays that are the "correct" shape. Idea

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

> I think that the problem is not that it doesn't raise an error for 1D array, > but that it doesn't do anything useful to 1D arrays. Raising an error would > change nothing to the way transpose is used now. No, but it would make it clear that you can't expect transpose to make a 1D array into a2D

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

On Tue, Apr 5, 2016 at 9:48 AM, 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. resolution > is > number of cubes along each axis) and averaging the points inside each cube > (if any). >

Re: [Numpy-discussion] Windows wheels, built, but should we deploy?

+1 -- thanks for doing all this work. There is a HUGE amount you can do with numpy that doesn't give a whit about how fast .dot() et all are. If you really do need that to be fast as possible, you can pug in a faster build later. This is great. Just as one example -- I teach a general python cla

Re: [Numpy-discussion] DyND 0.7.1 Release

> The DyND team would be happy to answer any questions people have about DyND, > like "what is working and what is not" or "what do we still need to do to hit > DyND 1.0". OK, how about: How does the performance. I'd DyND compare to Numpy for the core functionality they both support? - CHB ___

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

On Thu, Feb 18, 2016 at 2:19 PM, Alan Isaac wrote: > Would such a new function correct the apparent mistake (?) of > `linspace` including the endpoint by default? > Or is the current API justified by its Matlab origins? > I don't think so -- we don't need no stinkin' Matlab ! But I LIKE includi

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

nge() is getting silly. And it might be hard to do. At the C level I suppose you could actually know what the parameters and state of the range object are and create an array directly from that -- but that's what arange is for... -CHB > 2016-02-17 10:50 GMT-08:00 Chris Barker : > &g

Re: [Numpy-discussion] GSoC?

Apparetnly, NumFocus is applyign to be a GSoC Umbrella org as well: https://github.com/numfocus/gsoc Not sure why one might choose NumFocus vs PSF... -Chris On Wed, Feb 17, 2016 at 6:05 AM, Bryan Van de Ven wrote: > [This is a complete tangent, and so I apologize in advance.] > &g

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

On Sun, Feb 14, 2016 at 11:41 PM, Antony Lee wrote: > So how can np.array(range(...)) even work? > range() (in py3) is not a generator, nor is is a iterator. it is a range object, which is lazily evaluated, and satisfies both the iterator protocol and the sequence protocol (at least most of it:

Re: [Numpy-discussion] GSoC?

> > 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. do indexing the same way) Is that what you mean? -CHB --

Re: [Numpy-discussion] GSoC?

s time to get started. and I _think_ our ideas page can go on that Wiki. > Are you maybe interested in co-organizing or mentoring Chris? Updating the > ideas page, proposal reviewing and interviewing students via video calls > can be time-consuming, and mentoring definitely is, so the more

Re: [Numpy-discussion] GSoC?

p me about this or > suggest some , so that i can contribute . > > > > > Thanks & Regards, > Smruti Ranjan Sahoo > > On Tue, Feb 9, 2016 at 1:58 AM, Chris Barker > wrote: > >> ANyone interested in Google Summer of Code this year? >> >> I thi

[Numpy-discussion] GSoC?

approaching -- so I thought I'd ping the list and see if folks are interested. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206)

Re: [Numpy-discussion] Numpy 1.11.0b2 released

On Sat, Feb 6, 2016 at 4:11 PM, Michael Sarahan wrote: > Chris, > > Both conda-build-all and obvious-ci are excellent projects, and we'll > leverage them where we can (particularly conda-build-all). Obvious CI and > conda-smithy are in a slightly different space, as we

Re: [Numpy-discussion] Numpy 1.11.0b2 released

t it all up.. Chris, it may still be useful to use docker here (perhaps on the build > worker, or elsewhere), also, as the distinction between build machines and > user machines is important to make. Docker would be great for making sure > that all dependency requirements are met on end

Re: [Numpy-discussion] Numpy 1.11.0b2 released

On Fri, Feb 5, 2016 at 3:24 PM, Nathaniel Smith wrote: > On Fri, Feb 5, 2016 at 1:16 PM, Chris Barker > wrote: > > >> > If we set up a numpy-testing conda channel, it could be used to cache > >> > binary builds for all he versions of everything we want to

Re: [Numpy-discussion] Numpy 1.11.0b2 released

On Fri, Feb 5, 2016 at 9:55 AM, Nathaniel Smith wrote: > > If we set up a numpy-testing conda channel, it could be used to cache > > binary builds for all he versions of everything we want to test > > against. > > > > Conda-build-all could make it manageable to maintain that channel. > > What wou

Re: [Numpy-discussion] Numpy 1.11.0b2 released

> An extra ~2 hours of tests / 6-way parallelism is not that big a deal > in the grand scheme of things (and I guess it's probably less than > that if we can take advantage of existing binary builds) If we set up a numpy-testing conda channel, it could be used to cache binary builds for all he ver

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

On Tue, Jan 19, 2016 at 9:27 AM, Charles R Harris wrote: > On Tue, Jan 19, 2016 at 9:23 AM, Chris Barker - NOAA Federal < > chris.bar...@noaa.gov> wrote: > >> What does the standard lib do for rand range? I see that randint Is >> closed on both ends, so order doesn&#x

Re: [Numpy-discussion] Should I use pip install numpy in linux?

tions, and is > quite limited). > Yeah, GDAL/OGR is a F%$#ing nightmare -- and I do wish that Anaconda had a better build, but frankly, there is no system that's going to make that any easier -- do any of the Linux distros ship a really good compatible, up to date set of these libs -- and

Re: [Numpy-discussion] Should I use pip install numpy in linux?

> Last month, numpy had ~740,000 downloads from PyPI, Hm, given that Windows and Linux wheels have not been available, then that's mostly source installs anyway. Or failed installs -- no shortage of folks trying to pip install numpy on Windows and then having questions about why it doesn't work.

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

What does the standard lib do for rand range? I see that randint Is closed on both ends, so order doesn't matter, though if it raises for b wrote: Of the methods defined in *numpy/mtrand.pyx* (excluding helper functions and *random_integers*, as they are all related to *randint*), *randint* is the

Re: [Numpy-discussion] Should I use pip install numpy in linux?

On Fri, Jan 15, 2016 at 2:38 PM, Matthew Brett wrote: > > I think there's a distinction between 'promote numpy as wheels' and > 'make numpy available as a wheel'. I don't think you'll see much > evidence of "promotion" here - it's not really the open-source way. > Depends on how you define "pro

[Numpy-discussion] Should I use pip install numpy in linux?

tions, and is > quite limited). > Yeah, GDAL/OGR is a F%$#ing nightmare -- and I do wish that Anaconda had a better build, but frankly, there is no system that's going to make that any easier -- do any of the Linux distros ship a really good compatible, up to date set of these libs -- and

Re: [Numpy-discussion] Should I use pip install numpy in linux?

On Fri, Jan 15, 2016 at 11:21 AM, Nathaniel Smith wrote: > Sure. Someone's already packaged those for conda, and no one has packaged > them for pypi, so it makes sense that conda is more convenient for you. If > someone does the work of packaging them for pypi, then that difference goes > away. >

Re: [Numpy-discussion] Should I use pip install numpy in linux?

On Thu, Jan 14, 2016 at 10:58 AM, Matthew Brett wrote: > > but neither the culture nor the tooling support that > > approach now, so I'm not very confident you could gather adoption. > > I don't think there's a very large amount of cultural work - but some > to be sure. > > We already have the fo

Re: [Numpy-discussion] Should I use pip install numpy in linux?

>> Also, you have the problem that there is one PyPi -- so where do you put >> your nifty wheels that depend on other binary wheels? you may need to fork >> every package you want to build :-( > > Is this a real problem or a theoretical one? Do you know of some > situation where this wheel to wheel

Re: [Numpy-discussion] Should I use pip install numpy in linux?

On Mon, Jan 11, 2016 at 5:29 PM, Nathaniel Smith wrote: > I agree that talking about such things on distutils-sig tends to elicit a > certain amount of puzzled incomprehension, but I don't think it matters -- > wheels already have everything you need to support this. > well, that's what I figured

Re: [Numpy-discussion] Should I use pip install numpy in linux?

On Mon, Jan 11, 2016 at 11:02 AM, David Cournapeau wrote: > If we get all that worked out, we still haven't made any progress toward >> the non-standard libs that aren't python. This is the big "scipy problem" >> -- fortran, BLAS, hdf, ad infinitum. >> >> I argued for years that we could build bi

Re: [Numpy-discussion] Should I use pip install numpy in linux?

On Fri, Jan 8, 2016 at 7:13 PM, Nathaniel Smith wrote: > > that this would potentially be able to let packages like numpy serve > their > > linux > > users better without risking too much junk being uploaded to PyPI. > > That will never fly. But like Matthew says, I think we can probably > get th

Re: [Numpy-discussion] Should I use pip install numpy in linux?

On Fri, Jan 8, 2016 at 1:58 PM, Robert McGibbon wrote: > I'm not sure if this is the right path for numpy or not, > probably not -- AFAICT, the PyPa folks aren't interested in solving teh problems we have in the scipy community -- we can tweak around the edges, but we wont get there without a co

Re: [Numpy-discussion] Dynamic array list implementation

On Wed, Dec 30, 2015 at 6:34 AM, Nicolas P. Rougier < nicolas.roug...@inria.fr> wrote: > > > On 28 Dec 2015, at 19:58, Chris Barker wrote: > > > > >>> python benchmark.py > > Python list, append 10 items: 0.01161 > > Array list, append 10 i

Re: [Numpy-discussion] Dynamic array list implementation

On Wed, Dec 23, 2015 at 4:01 AM, Nicolas P. Rougier < nicolas.roug...@inria.fr> wrote: > But my implementation is quite slow, especially when you add one item at a > time: > > >>> python benchmark.py > Python list, append 10 items: 0.01161 > Array list, append 10 items: 0.46854 > are you

Re: [Numpy-discussion] Dynamic array list implementation

On Thu, Dec 24, 2015 at 10:19 AM, Chris Barker wrote: > I'll try to get the code up on gitHub. > Hey look -- it's already there: https://github.com/PythonCHB/NumpyExtras too many gitHub accounts. Here is the list/growable array/ accumulator: https://github.com/PythonCHB/

Re: [Numpy-discussion] Dynamic array list implementation

rray list, append 10 items: 0.46854 > Array list, append 10 items at once: 0.05801 > Python list, prepend 10 items: 1.96168 > Array list, prepend 10 items: 12.83371 > Array list, append 10 items at once: 0.06002 > > > > I realize I did not answ

Re: [Numpy-discussion] Dynamic array list implementation

e > > more broadly useful. > > > > > > Cheers, > > Stephan > > > > > > > > > > On Tue, Dec 22, 2015 at 8:20 PM, Chris Barker > > wrote: > > > > > > sorry for being so lazy as to not go look at the

Re: [Numpy-discussion] Proposal: stop providing official win32 downloads (for now)

On Tue, Dec 22, 2015 at 11:43 AM, Matthew Brett wrote: > On a virtual Windows machine I just span up, the Python.org site gave > me default buttons to download Python 3.5 or 2.7, and the linked > installers look like they are 32-bit. It's probably time for python.org to change that -- but this

Re: [Numpy-discussion] Proposal: stop providing official win32 downloads (for now)

On Tue, Dec 22, 2015 at 11:32 AM, Matthew Brett wrote: > The take-home is that about 12 percent of gamers have 32 bit Windows. > It's easy to believe business users will use 32-bit more. > yup -- I tend to think gamers are on the cutting edge Though I work on gov't which is very slow moving

Re: [Numpy-discussion] Proposal: stop providing official win32 downloads (for now)

On Tue, Dec 22, 2015 at 11:18 AM, David Cournapeau wrote: > Any way to know how many people are running 32 bit Python on Windows these >> days?? >> > > I don't claim we are representative of the whole community, but as far as > canopy is concerned, it is still a significant platform. That's the o

Re: [Numpy-discussion] Dynamic array list implementation

sorry for being so lazy as to not go look at the project pages, but This sounds like it could be really useful, and maybe supercise a coupl eof half-baked projects of mine. But -- what does "dynamic" mean? - can you append to these arrays? - can it support "ragged arrrays" -- it looks like it

Re: [Numpy-discussion] Proposal: stop providing official win32 downloads (for now)

On Mon, Dec 21, 2015 at 10:05 PM, Ralf Gommers wrote: > >>> There's a good chance that many downloads are from unsuspecting users > with a 64-bit Python, and they then just get an unhelpful "cannot find > Python" error from the installer. > could be -- hard to know. > At least until we have bi

Re: [Numpy-discussion] Proposal: stop providing official win32 downloads (for now)

On Fri, Dec 18, 2015 at 1:51 PM, Ralf Gommers > > +1 from me. Despite the number of downloads still being high, I don't > think there's too much value in these binaries anymore. > If there are a lot of downloads, then there is value. At least until we have binary wheels on PyPi. What's up with th

Re: [Numpy-discussion] array_equal too strict?

> If you have some spare cycles, maybe you can open a pull request to add > np.isclose to the "See Also" section? That would be great. Remember that equality for flits is bit-for but equality ( baring NaN and inf...). But you hardly ever actually want to do that with floats. But probably np.all

Re: [Numpy-discussion] Fast vectorized arithmetic with ~32 significant digits under Numpy

> There has also been some talk of adding a user type for ieee 128 bit doubles. > I've looked once for relevant code for the latter and, IIRC, the available > packages were GPL :(. This looks like it's BSD-Ish: http://www.jhauser.us/arithmetic/SoftFloat.html Don't know if it's any good C

Re: [Numpy-discussion] When to stop supporting Python 2.6?

drop 2.6 I still don't understand why folks insist that they need to run a (very)) old python on an old OS, but need the latest and greatest numpy. Chuck's list was pretty long and compelling. -CHB On Mon, Dec 7, 2015 at 1:38 AM, Sturla Molden wrote: > Charles R Harris wrote: > > > As a st

Re: [Numpy-discussion] Question about structure arrays

On Sat, Nov 7, 2015 at 1:18 PM, aerojockey wrote: > Inside a > low-level loop, I create a structure array, populate it Python, then turn > it > over to some handwritten C code for processing. can you do that inside bit of the low-level loop in C (or cython?) you often want to put the guts of y

Re: [Numpy-discussion] [Distutils] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

>> I'm not talking about in place installs, I'm talking about e.g. building a >> wheel and then tweaking one file and rebuilding -- traditionally build >> systems go to some effort to keep track of intermediate artifacts and reuse >> them across builds when possible, but if you always copy the sour

Re: [Numpy-discussion] deprecate fromstring() for text reading?

bring in a new delimited reader -- I.e. CSV in its various flavors. CHB Ben On Mon, Nov 2, 2015 at 6:44 PM, Chris Barker wrote: > On Tue, Oct 27, 2015 at 7:30 AM, Benjamin Root > wrote: > >> FWIW, when I needed a fast Fixed Width reader >> > > was there potentially

Re: [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

On Tue, Oct 27, 2015 at 8:25 AM, Nathan Goldbaum wrote: > Interestingly, conda actually does "setup.py install" in the recipe for > numpy: > indeed -- many, many conda packages do setup.py install, whihc doesn't mean it's a good idea --personally, I'm trying hard to switch them all to: pip inst

Re: [Numpy-discussion] [NumPy/Swig] Return NumPy array with same size as input array (no additional length argument)

On Fri, Oct 30, 2015 at 11:15 PM, laurentes wrote: > Using Swig, I don't manage to (properly) create the Python Binding for the > following C-like function: > > void add_array(double* input_array1, double* input_array2, double* > output_array, int length); > > where the three arrays have all the

Re: [Numpy-discussion] deprecate fromstring() for text reading?

to pure python for fixed width scenarios. > > On Fri, Oct 23, 2015 at 8:22 PM, Chris Barker - NOAA Federal < > chris.bar...@noaa.gov> wrote: > >> Grabbing the pandas csv reader would be great, and I hope it happens >> sooner than later, though alas, I haven't the spare

Re: [Numpy-discussion] deprecate fromstring() for text reading?

Grabbing the pandas csv reader would be great, and I hope it happens sooner than later, though alas, I haven't the spare cycles for it either. In the meantime though, can we put a deprecation Warning in when using fromstring() on text files? It's really pretty broken. -Chris On Oct 23

Re: [Numpy-discussion] deprecate fromstring() for text reading?

I think it would be good to keep the usage to read binary data at least. Agreed -- it's only the text file reading I'm proposing to deprecate. It was kind of weird to cram it in there in the first place. Oh, fromfile() has the same issues. Chris Or is there a good alte

[Numpy-discussion] deprecate fromstring() for text reading?

There was just a question about a bug/issue with scipy.fromstring (which is numpy.fromstring) when used to read integers from a text file. https://mail.scipy.org/pipermail/scipy-user/2015-October/036746.html fromstring() is bugging and inflexible for reading text files -- and it is a very, very u

Re: [Numpy-discussion] Making datetime64 timezone naive

> This is fine. Just be aware that *naive* datetimes will also have the PEP > 495 "fold" attribute in Python 3.6. You are free to ignore it, but you will > loose the ability to round-trip between naive stdlib datetimes and > numpy.datetime64. Sigh. I can see why it's there ( primarily to supp

Re: [Numpy-discussion] [Feature Suggestion]More comparison functions for floating point numbers

On Mon, Oct 19, 2015 at 3:06 AM, cy18 wrote: > I think these would be useful and easy to implement. > > greater_close(a, b) = greater_equal(a, b) | isclose(a, b) > less_close(a, b) = less_equal(a, b) | isclose(a, b) > greater_no_close = greater(a, b) & ~isclose(a, b) > less_no_clo

Re: [Numpy-discussion] Making datetime64 timezone naive

On Sun, Oct 18, 2015 at 12:20 PM, Alexander Belopolsky wrote: > > On Sat, Oct 17, 2015 at 6:59 PM, Chris Barker > wrote: > >> Off the top of my head, I think allowing a 60th second makes more sense >> -- jsut like we do leap years. > > > Yet we don't i

Re: [Numpy-discussion] Making datetime64 timezone naive

On Fri, Oct 16, 2015 at 10:19 AM, Alexander Belopolsky wrote: > Since Guido hates leap seconds, PEP 495 is silent on this issue, but > strictly speaking UTC leap seconds are "folds." AFAICT, a strictly POSIX > system must repeat the same value of time_t when a leap second is > inserted. While

Re: [Numpy-discussion] how is toolchain selected for compiling (OS X with python.org build)?

you might try the python-mac list: https://mail.python.org/mailman/listinfo/pythonmac-sig not very active, but folks there know what they are doing :-) -CHB On Thu, Oct 15, 2015 at 8:49 AM, Andrew Jaffe wrote: > This isn't, strictly speaking, a numpy question, but I suspect it's > something

Re: [Numpy-discussion] Numpy 1.10.1 released.

On Wed, Oct 14, 2015 at 12:38 PM, Ralf Gommers wrote: > I'm actually not sure if anyone even uses the 32 bit builds at all :-) >>> >> There's a lot of 32 bit python use out there still, including numpy. >> > > If you want a quick impression, there are download stats for our binaries: > http://sou

Re: [Numpy-discussion] Making datetime64 timezone naive

On Wed, Oct 14, 2015 at 10:34 AM, Phil Hodge wrote: > On 10/14/2015 11:59 AM, Chris Barker wrote: > >> we have no way to know when there will be leap-seconds in the future >> > > Leap seconds are announced about six months in advance. exactly -- so more than six mont

Re: [Numpy-discussion] Numpy 1.10.1 released.

On Wed, Oct 14, 2015 at 9:38 AM, Nathaniel Smith wrote: > The change in 1.10.1 only affects msvc, which is not what most people are > using (IIUC Enthought Canopy uses msvc, but the pypi, gohlke, and Anaconda > builds don't). > Anaconda uses MSVC for the most part -- they _may_ compile numpy itse

Re: [Numpy-discussion] Numpy 1.10.1 released.

On Mon, Oct 12, 2015 at 9:27 AM, Charles R Harris wrote: > * Compiling with msvc9 or msvc10 for 32 bit Windows now requires SSE2. > This was the easiest fix for what looked to be some miscompiled code when > SSE2 was not used. > Note that there is discusion right now on pyton-dev about requi

Re: [Numpy-discussion] Making datetime64 timezone naive

On Tue, Oct 13, 2015 at 5:08 PM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Maybe not directly relevant, but also very clearly why one should ideally >> not use these a >> > all! >> > I wouldn't say not at all -- I'd say "not in some circumstances" > Perhaps even less relevant, but

Re: [Numpy-discussion] Making datetime64 timezone naive

On Tue, Oct 13, 2015 at 3:58 PM, Nathaniel Smith wrote: > > However, numpy datetime is optimized for compact storage and fast > computation of absolute deltas (actual hours, minutes, seconds... not > calendar units like "the next day" ). > > Except that ironically it actually can't compute absolu

Re: [Numpy-discussion] Making datetime64 timezone naive

datetime in UTC, and apply the timezone on I/O. Alexander: Am I right that we don't need the "fold" bit in this case? You'd still need it when specifying a time in a timezone with folds.. -- but again, only on I/O -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Resp

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

actical. > Agreed -- I can imagine use-cases, but users can cadt to/from integers if that's what they want to do e.g. with .astype() -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (20

Re: [Numpy-discussion] Making datetime64 timezone naive

On Mon, Oct 12, 2015 at 12:38 AM, Nathaniel Smith wrote: > > As a temporary measure, we still will parse datetimes that include a > > timezone specification by converting them to UTC, but will issue a > > DeprecationWarning. This is important for a smooth transition, because at > > the very least

Re: [Numpy-discussion] Making datetime64 timezone naive

On Mon, Oct 12, 2015 at 11:48 AM, Alexander Belopolsky wrote: > If you are going to make datetime64 more like datetime.datetime, please > consider adding the "fold" bit. See PEP 495. [1] > > [1]: https://www.python.org/dev/peps/pep-0495/ > well, adding any timezone support is not (yet) in the t

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

On Sun, Oct 11, 2015 at 8:38 PM, Stephan Hoyer wrote: > Currently, NaT (not a time) does not have any special treatment when used > in comparison with datetime64/timedelta64 objects. > > To me, this seems a little crazy for a value meant to denote a > missing/invalid time -- NaT should really hav

Re: [Numpy-discussion] msvc9 comipiler problems

4266 I think the only difference is how.where it is installed, but you never know... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206)

Re: [Numpy-discussion] NumFOCUS fiscal sponsorship agreement

Looks good to me. This pretty exciting, actually :-) -CHB Sent from my iPhone > On Oct 7, 2015, at 10:57 PM, Nathaniel Smith wrote: > > Hi all, > > Now that the governance document is in place, we need to get our legal > ducks in a row by signing a fiscal sponsorship agreement with > NumFOCUS.

  1   2   3   4   5   6   7   8   9   10   >