[Numpy-discussion] Advanced numpy tutorial for SciPy?

In another thread, there is a discussion of a workshop on "Taking NumPy In Stride" for PyData Barcelona. I think it would be great to have something like that at SciPy in Austin this year. Jaime can't make it, and I don't think strides are going to fill a four hour tutorial, so it would be good

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 <ralf.gomm...@gmail.com&

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 =

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

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>

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

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

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,

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

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

On Fri, Sep 2, 2016 at 1:16 AM, Peter Creasey wrote: > > I'm not quite sure which approach is state-of-the-art as of 2016. How > would > > you do it if you had to make a C/C++ library available in Python right > now? > > > > In my case, I have a C library with

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

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

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, >

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

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

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 >

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

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

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

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

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?

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

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

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

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

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'

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

but special casing range() 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 Ch

Re: [Numpy-discussion] GSoC?

ck chat (or a few emails) to > answer questions, share your experience, or offer advice, please drop me a > line directly. > > Thanks, > > Bryan > > > > > On Feb 17, 2016, at 1:14 AM, Stephan Hoyer <sho...@gmail.com> wrote: > > > > On Wed, Feb 10,

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

Re: [Numpy-discussion] GSoC?

Thanks Ralf, Note that we have always done a combined numpy/scipy ideas page and > submission. For really good students numpy may be the right challenge, but > in general scipy is easier to get started on. > yup -- good idea. Is there a page ready to go, or do we need to get one up? (I don't

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] 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 want

[Numpy-discussion] GSoC?

ANyone interested in Google Summer of Code this year? I think the real challenge is having folks with the time to really put into mentoring, but if folks want to do it -- numpy could really benefit. Maybe as a python.org sub-project? https://wiki.python.org/moin/SummerOfCode/2016 Deadlines are

Re: [Numpy-discussion] GSoC?

you help 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 <chris.bar...@noaa.gov> > wrote: > >> ANyone interested in Google Summer of

Re: [Numpy-discussion] Numpy 1.11.0b2 released

On Fri, Feb 5, 2016 at 3:24 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Fri, Feb 5, 2016 at 1:16 PM, Chris Barker <chris.bar...@noaa.gov> > wrote: > > >> > If we set up a numpy-testing conda channel, it could be used to cache > >> > binary bui

Re: [Numpy-discussion] Numpy 1.11.0b2 released

On Sat, Feb 6, 2016 at 3:42 PM, Michael Sarahan wrote: > FWIW, we (Continuum) are working on a CI system that builds conda recipes. > great, could be handy. I hope you've looked at the open-source systems that do this: obvious-ci and conda-build-all. And conda-smithy to help

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

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

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

On Tue, Jan 19, 2016 at 9:27 AM, Charles R Harris <charlesr.har...@gmail.com > 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 >> clos

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

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

hmm -- didn't mean to rev this up quite so much -- sorry! But it's a good conversation to have, so... On Fri, Jan 15, 2016 at 1:08 PM, Benjamin Root wrote: > That being said... I take exception to your assertion that anaconda is > *the* solution to the packaging problem.

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.

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

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. >

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

hmm -- didn't mean to rev this up quite so much -- sorry! But it's a good conversation to have, so... On Fri, Jan 15, 2016 at 1:08 PM, Benjamin Root wrote: > That being said... I take exception to your assertion that anaconda is > *the* solution to the packaging problem.

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

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,

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

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

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

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 <chris.bar...@noaa.gov> wrote: > > > > >>> python benchmark.py > > Python list, append 10 items: 0.01

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

ject that could be > > more broadly useful. > > > > > > Cheers, > > Stephan > > > > > > > > > > On Tue, Dec 22, 2015 at 8:20 PM, Chris Barker <chris.bar...@noaa.gov> > > wrote: > > > > > > sorry for being so lazy as

Re: [Numpy-discussion] Dynamic array list implementation

On Thu, Dec 24, 2015 at 10:19 AM, Chris Barker <chris.bar...@noaa.gov> 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:

Re: [Numpy-discussion] Dynamic array list implementation

t > from Cython, which makes sense given that it needs to copy about 1/3 the > data (no type or reference count for individual elements). Obviously, it > uses 1/3 the space to store the data, too. We currently don't expose this > object externally, but it could be an interesting project to ad

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. >

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

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

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

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

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

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

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

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

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

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

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

reader -- I.e. CSV in its various flavors. CHB Ben On Mon, Nov 2, 2015 at 6:44 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > On Tue, Oct 27, 2015 at 7:30 AM, Benjamin Root <ben.v.r...@gmail.com> > wrote: > >> FWIW, when I needed a fast Fixed Width reader &

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

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

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

k > 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 th

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

.@gmail.com> wrote: > >> >> >> On Thu, Oct 22, 2015 at 5:47 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: >>> >>> >>>> I think it would be good to keep the usage to read binary data at least. >>>

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

to `np.fromstring(, dtype=...)`? -- Marten On Thu, Oct 22, 2015 at 1:03 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > 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/pi

[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

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,

Re: [Numpy-discussion] Making datetime64 timezone naive

On Sun, Oct 18, 2015 at 12:20 PM, Alexander Belopolsky <ndar...@mac.com> wrote: > > On Sat, Oct 17, 2015 at 6:59 PM, Chris Barker <chris.bar...@noaa.gov> > wrote: > >> Off the top of my head, I think allowing a 60th second makes more sense >> -- jsut like

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

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 >

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

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

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

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,

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_

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

Re: [Numpy-discussion] Making datetime64 timezone naive

On Wed, Oct 14, 2015 at 10:34 AM, Phil Hodge <ho...@stsci.edu> 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 -- s

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 --

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

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 >

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

On Tue, Oct 13, 2015 at 10:48 AM, Stephan Hoyer wrote: > This led to my discovery that NumPy currently supports unit-less > timedeltas (e.g., "np.timedelta64(5)"), which indicate some sort of generic > time difference. The current behavior is to take the time units from the >

Re: [Numpy-discussion] Making datetime64 timezone naive

On Tue, Oct 13, 2015 at 3:21 PM, Nathaniel Smith wrote: > > If you are going to make datetime64 more like datetime.datetime, please > consider adding the "fold" bit. See PEP 495. [1] > The challenge here is that we literally do not have a bit too use :-) > hmm -- I was first

Re: [Numpy-discussion] msvc9 comipiler problems

> > > NVM. Looks like Python 2.7 also uses msvc9. > yup, according to Wikipedia: *Visual C++ 2008* (known also as Visual C++ 9.0) so py2.7 Are you testing with the "MS Visual C++ compiler for Python 2.7" here: http://www.microsoft.com/en-us/download/details.aspx?id=44266 I think the only

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

Re: [Numpy-discussion] Let's move forward with the current governance document.

On Mon, Oct 5, 2015 at 2:11 PM, Sturla Molden wrote: > I just envisioned a Roman patron shouting veto or a US senator > filibustering. Expulsion would be the appropriate recation, yes :-) Oh if only the US Senate could expulse people! -sigh -- Christopher Barker,

Re: [Numpy-discussion] NumPy Governance Document.

> > > The NumPy Governance Document > has been merged and is now in effect. > whoo hoo! And a special thanks to Nathaniel, > Indeed -- and everyone else that put a lot of their time into the discussion. Looking forward to discussing technical issues

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

On Tue, Sep 29, 2015 at 7:32 AM, Travis Oliphant wrote: > I'm in a situation now where at least for 6 months or so I can help with > NumPy more than I have been able to for 7 years. > great news! > 1) 1 year of inactivity to be removed from the council is too little for a

Re: [Numpy-discussion] Sign of NaN

On Tue, Sep 29, 2015 at 6:35 PM, Charles R Harris wrote: > For this, and other use-cases, special casing Numpy arrays stored in >>> object arrays does make sense: >>> >>> "If this is s a Numpy array, pass the operation through." >>> >> >> Because we now (development)

  1   2   3   4   5   6   >