Re: [Numpy-discussion] [SciPy-Dev] Setting up a dev environment with conda

Thanks for the help Nathaniel --- but building via `./runtests.py` is failing in the same way. Hopefully Numpy-discussion can help me out. I'm able to build using `python setup.py build_ext --inplace` but both trying to run `python setup.py install` or `./runtests.py` leads to the following

Re: [Numpy-discussion] [SciPy-Dev] Setting up a dev environment with conda

Hi Luke, Could you check if you have "/Users/lzkelley/Programs/public/numpy/ in your PYTHONPATH? I would also suggest you add a print(np) line before the crash in nosetester.py. I got something like this (which didn't crash): If you see something not starting with 'numpy/build', then it is

Re: [Numpy-discussion] [SciPy-Dev] Setting up a dev environment with conda

Thanks Yu, There was nothing in my PYTHONPATH at first, and adding my numpy directory ('/Users/lzkelley/Programs/public/numpy') didn't help (same error). In both cases, adding 'print(np)' yields: > On Oct 18, 2015, at 7:22 PM, Feng Yu wrote: > > Hi Luke, > > Could

Re: [Numpy-discussion] [SciPy-Dev] Setting up a dev environment with conda

Running tests in the folder might be causing your problem. If it's trying to import numpy, and numpy is a folder in your current folder, sometimes you see errors like this. The confusion is that Python treats folders (packages) similarly to modules, and the resolution order sometimes bites you.

Re: [Numpy-discussion] [SciPy-Dev] Setting up a dev environment with conda

On Sun, Oct 18, 2015 at 5:02 PM, Michael Sarahan wrote: > Running tests in the folder might be causing your problem. If it's trying > to import numpy, and numpy is a folder in your current folder, sometimes you > see errors like this. The confusion is that Python treats

Re: [Numpy-discussion] Making datetime64 timezone naive

On Sat, Oct 17, 2015 at 6:59 PM, Chris Barker wrote: > If anyone decides to actually get around to leap seconds support in numpy > datetime, s/he can decide ... This attitude is the reason why we will probably never have bug free software when it comes to civil time

Re: [Numpy-discussion] [SciPy-Dev] Setting up a dev environment with conda

I tried cleaning the git dir, and trying again. It still didn't work giving me the report: == ERROR: test_scripts.test_f2py -- Traceback (most recent call

Re: [Numpy-discussion] numpy-1.11.0.dev0 windows wheels compiled with mingwpy available

Hi, Is it possible to test this with py35 as well? For MSVC, py35 requires a new compiler toolchain (VS2015) -- is that something mingwpy/mingw-w64 can handle? -Robert On Fri, Oct 9, 2015 at 3:29 PM, Carl Kleffner wrote: > I made numpy master (numpy-1.11.0.dev0 , >

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

On Mon, Oct 19, 2015 at 1:10 AM, Stephan Hoyer wrote: > Looking at the git logs, column_stack appears to have been that way > (creating a new array with concatenate) since at least NumPy 0.9.2, way > back in January 2006: >

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

>>> np.column_stack((np.ones(10), np.ones(10))).flags C_CONTIGUOUS : True F_CONTIGUOUS : False >>> np.__version__ '1.9.2rc1' on my notebook which has numpy 1.6.1 it is f_contiguous I was just trying to optimize a loop over variable adjustment in regression, and found out that we lost

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

On Mon, Oct 19, 2015 at 1:27 AM, wrote: > > > On Mon, Oct 19, 2015 at 1:10 AM, Stephan Hoyer wrote: > >> Looking at the git logs, column_stack appears to have been that way >> (creating a new array with concatenate) since at least NumPy 0.9.2, way >> back

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

On Mon, Oct 19, 2015 at 12:35 AM, wrote: > >>> np.column_stack((np.ones(10), np.ones(10))).flags > C_CONTIGUOUS : True > F_CONTIGUOUS : False > > >>> np.__version__ > '1.9.2rc1' > > > on my notebook which has numpy 1.6.1 it is f_contiguous > > > I was just trying to

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

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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 implement DST by allowing the 24th hour. Even the countries that adjust the clocks at midnight