Re: [Numpy-discussion] when did column_stack become C-contiguous?
On Sun, Oct 18, 2015 at 9:35 PM, 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 optimize a loop over variable adjustment in regression, > and found out that we lost fortran contiguity. > > I always thought column_stack is for fortran usage (linalg) > > What's the alternative? > column_stack was one of my favorite commands, and I always assumed we have > in statsmodels the right memory layout to call the linalg libraries. > > ("assumed" means we don't have timing nor unit tests for it.) In general practice no numpy functions make any guarantee about memory layout, unless that's explicitly a documented part of their contract (e.g. 'ascontiguous', or some functions that take an order= argument -- I say "some" b/c there are functions like 'reshape' that take an argument called order= that doesn't actually refer to memory layout). This isn't so much an official policy as just a fact of life -- if no-one has any idea that the someone is depending on some memory layout detail then there's no way to realize that we've broken something. (But it is a good policy IMO.) If this kind of problem gets caught during a pre-release cycle then we generally do try to fix it, because we try not to break code, but if it's been broken for 2 full releases then there's no much we can do -- we can't go back in time to fix it so it sounds like you're stuck working around the problem no matter what (unless you want to refuse to support 1.9.0 through 1.10.1, which I assume you don't... worst case, you just have to do a global search replace of np.column_stack with statsmodels.utils.column_stack_f, right?). And the regression issue seems like the only real argument for changing it back -- we'd never guarantee f-contiguity here if starting from a blank slate, I think? -n -- Nathaniel J. Smith -- http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 in January 2006: >> https://github.com/numpy/numpy/blob/v0.9.2/numpy/lib/shape_base.py#L271 >> > > Then it must have been changed somewhere else between 1.6.1 amd 1.9.2rc1 > > I have my notebook and my desktop with different numpy and python versions > next to each other and I don't see a typo in my command. > > I assume python 2.7 versus python 3.4 doesn't make a difference. > > -- > > >>> np.column_stack((np.ones(10), np.ones(10))).flags > C_CONTIGUOUS : False > F_CONTIGUOUS : True > OWNDATA : False > WRITEABLE : True > ALIGNED : True > UPDATEIFCOPY : False > > >>> np.__version__ > '1.6.1' > >>> import sys > >>> sys.version > '2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)]' > > > > >>> np.column_stack((np.ones(10), np.ones(10))).flags > C_CONTIGUOUS : True > F_CONTIGUOUS : False > OWNDATA : True > WRITEABLE : True > ALIGNED : True > UPDATEIFCOPY : False > > >>> np.__version__ > '1.9.2rc1' > >>> import sys > >>> sys.version > '3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit > (AMD64)]' > > --- > > comparing all flags, owndata also has changed, but I don't think that has > any effect > qualification It looks like in 1.9 it depends on the order of the 2-d arrays, which it didn't do in 1.6 >>> np.column_stack((np.ones(10), np.ones((10, 2), order='F'))).flags C_CONTIGUOUS : False F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False which means the default order looks more like "K" now, not "C", IIUC Josef > > Josef > > >> >> >> Stephan >> >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> https://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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: > https://github.com/numpy/numpy/blob/v0.9.2/numpy/lib/shape_base.py#L271 > Then it must have been changed somewhere else between 1.6.1 amd 1.9.2rc1 I have my notebook and my desktop with different numpy and python versions next to each other and I don't see a typo in my command. I assume python 2.7 versus python 3.4 doesn't make a difference. -- >>> np.column_stack((np.ones(10), np.ones(10))).flags C_CONTIGUOUS : False F_CONTIGUOUS : True OWNDATA : False WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False >>> np.__version__ '1.6.1' >>> import sys >>> sys.version '2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)]' >>> np.column_stack((np.ones(10), np.ones(10))).flags C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False >>> np.__version__ '1.9.2rc1' >>> import sys >>> sys.version '3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)]' --- comparing all flags, owndata also has changed, but I don't think that has any effect Josef > > > Stephan > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] when did column_stack become C-contiguous?
Looking at the git logs, column_stack appears to have been that way (creating a new array with concatenate) since at least NumPy 0.9.2, way back in January 2006: https://github.com/numpy/numpy/blob/v0.9.2/numpy/lib/shape_base.py#L271 Stephan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 optimize a loop over variable adjustment in > regression, and found out that we lost fortran contiguity. > > I always thought column_stack is for fortran usage (linalg) > > What's the alternative? > column_stack was one of my favorite commands, and I always assumed we have > in statsmodels the right memory layout to call the linalg libraries. > > ("assumed" means we don't have timing nor unit tests for it.) > What's the difference between using array and column_stack except for a transpose and memory order? my current usecase is copying columns on top of each other #exog0 = np.column_stack((np.ones(nobs), x0, x0s2)) exog0 = np.array((np.ones(nobs), x0, x0s2)).T exog_opt = exog0.copy(order='F') the following part is in a loop, followed by some linear algebra for OLS, res_optim is a scalar parameter. exog_opt[:, -1] = np.clip(exog0[:, k] + res_optim, 0, np.inf) Are my assumption on memory access correct, or is there a better way? (I have quite a bit code in statsmodels that is optimized for fortran ordered memory layout especially for sequential regression, under the assumption that column_stack provides that Fortran order.) Also, do I need to start timing and memory benchmarking or is it obvious that a loop for k in range(maxi): x = arr[:, :k] depends on memory order? Josef > > Josef > > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 fortran contiguity. I always thought column_stack is for fortran usage (linalg) What's the alternative? column_stack was one of my favorite commands, and I always assumed we have in statsmodels the right memory layout to call the linalg libraries. ("assumed" means we don't have timing nor unit tests for it.) Josef ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 last): File "/Users/lzkelley/anaconda/envs/numpy-py27/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/Users/lzkelley/Programs/public/numpy/build/testenv/lib/python2.7/site-packages/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/Users/lzkelley/Programs/public/numpy/build/testenv/lib/python2.7/site-packages/numpy/tests/test_scripts.py", line 68, in test_f2py code, stdout, stderr = run_command([f2py_cmd, '-v']) File "/Users/lzkelley/Programs/public/numpy/build/testenv/lib/python2.7/site-packages/numpy/tests/test_scripts.py", line 48, in run_command proc = Popen(cmd, stdout=PIPE, stderr=PIPE) File "/Users/lzkelley/anaconda/envs/numpy-py27/lib/python2.7/subprocess.py", line 710, in __init__ errread, errwrite) File "/Users/lzkelley/anaconda/envs/numpy-py27/lib/python2.7/subprocess.py", line 1335, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory -- Ran 6029 tests in 82.132s FAILED (KNOWNFAIL=6, SKIP=10, errors=2) f2py itself did seem to work fine from the command-line... I did get things (seemingly) working, by cleaning the dir again, and then running: python setupegg.py develop --user This built properly, and now lets me make modification to the source files and have them take effect immediately. This is really all I need for now, but I will try to get the `./runtests.py` working for the future. Perhaps the problem is something to do with my previous python environment installed via macports... > On Oct 18, 2015, at 9:04 PM, Nathaniel Smith wrote: > > 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 folders >> (packages) similarly to modules, and the resolution order sometimes bites >> you. Try cd'ing to a different folder (importantly, one NOT containing a >> numpy folder!) and run the test command from there. > > This isn't the problem -- ./runtests.py is designed to work fine when > run from the root of the numpy checkout. > > You might try nuking your checkout and environment and starting over > just in case your earlier attempts left behind some broken detritus > somewhere. 'git clean -xdf' will clear everything out of a git > directory aside from tracked files (so make sure to add any new files > you want to keep first!). > > -n > > -- > Nathaniel J. Smith -- http://vorpus.org > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 , > https://github.com/numpy/numpy/commit/0243bce23383ff5e894b99e40df2f8fd806ad79f) > windows binary wheels available for testing. > > Install it with pip: > > > pip install -i https://pypi.anaconda.org/carlkl/simple numpy > > These builds are compiled with OPENBLAS trunk for BLAS/LAPACK support and > the mingwpy compiler toolchain. > > OpenBLAS is deployed within the numpy wheels. To be performant on all > usual CPU architectures OpenBLAS is configured with it's 'dynamic > architecture' and automatic CPU detection. > > This version of numpy fakes long double as double just like the MSVC > builds. > > Some test statistics: > > win32 (32 bit) > numpy-1.11.0.dev0, python-2.6: errors=8, failures=1 > numpy-1.11.0.dev0, python-2.7: errors=8, failures=1 > numpy-1.11.0.dev0, python-3.3: errors=9 > numpy-1.11.0.dev0, python-3.4: errors=9 > > amd64 (64bit) > numpy-1.11.0.dev0, python-2.6: errors=9, failures=6 > numpy-1.11.0.dev0, python-2.7: errors=9, failures=6 > numpy-1.11.0.dev0, python-3.3: errors=10, failures=6 > numpy-1.11.0.dev0, python-3.4: errors=10, failures=6 > > Carl > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 folders > (packages) similarly to modules, and the resolution order sometimes bites > you. Try cd'ing to a different folder (importantly, one NOT containing a > numpy folder!) and run the test command from there. This isn't the problem -- ./runtests.py is designed to work fine when run from the root of the numpy checkout. You might try nuking your checkout and environment and starting over just in case your earlier attempts left behind some broken detritus somewhere. 'git clean -xdf' will clear everything out of a git directory aside from tracked files (so make sure to add any new files you want to keep first!). -n -- Nathaniel J. Smith -- http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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. Try cd'ing to a different folder (importantly, one NOT containing a numpy folder!) and run the test command from there. HTH, Michael On Sun, Oct 18, 2015 at 6:46 PM Luke Zoltan Kelley wrote: > 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: > > '/Users/lzkelley/Programs/public/numpy/numpy/__init__.pyc'> > > > > On Oct 18, 2015, at 7:22 PM, Feng Yu wrote: > > > > 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): > > > > > > '/home/yfeng1/source/numpy/build/testenv/lib64/python2.7/site-packages/numpy/__init__.pyc'> > > > > If you see something not starting with 'numpy/build', then it is again > > pointing at PYTHONPATH. > > > > I hope these helps. > > > > Best, > > > > - Yu > > > > On Sun, Oct 18, 2015 at 1:25 PM, Luke Zoltan Kelley > wrote: > >> 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 error: > >> > >> (numpy-py27)daedalus-2:numpy lzkelley$ ./runtests.py > >> Building, see build.log... > >> Running from numpy source directory. > >> Traceback (most recent call last): > >> File "setup.py", line 264, in > >>setup_package() > >> File "setup.py", line 248, in setup_package > >>from numpy.distutils.core import setup > >> File > "/Users/lzkelley/Programs/public/numpy/numpy/distutils/__init__.py", > >> line 21, in > >>from numpy.testing import Tester > >> File "/Users/lzkelley/Programs/public/numpy/numpy/testing/__init__.py", > >> line 14, in > >>from .utils import * > >> File "/Users/lzkelley/Programs/public/numpy/numpy/testing/utils.py", > line > >> 17, in > >>from numpy.core import float32, empty, arange, array_repr, ndarray > >> File "/Users/lzkelley/Programs/public/numpy/numpy/core/__init__.py", > line > >> 59, in > >>test = Tester().test > >> File > "/Users/lzkelley/Programs/public/numpy/numpy/testing/nosetester.py", > >> line 180, in __init__ > >>if raise_warnings is None and '.dev0' in np.__version__: > >> AttributeError: 'module' object has no attribute '__version__' > >> > >> Build failed! > >> > >> > >> Has anyone seen something like this before? > >> > >> Thanks! > >> Luke > >> > >> ___ > >> NumPy-Discussion mailing list > >> NumPy-Discussion@scipy.org > >> https://mail.scipy.org/mailman/listinfo/numpy-discussion > >> > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 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): > > '/home/yfeng1/source/numpy/build/testenv/lib64/python2.7/site-packages/numpy/__init__.pyc'> > > If you see something not starting with 'numpy/build', then it is again > pointing at PYTHONPATH. > > I hope these helps. > > Best, > > - Yu > > On Sun, Oct 18, 2015 at 1:25 PM, Luke Zoltan Kelley > wrote: >> 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 error: >> >> (numpy-py27)daedalus-2:numpy lzkelley$ ./runtests.py >> Building, see build.log... >> Running from numpy source directory. >> Traceback (most recent call last): >> File "setup.py", line 264, in >>setup_package() >> File "setup.py", line 248, in setup_package >>from numpy.distutils.core import setup >> File "/Users/lzkelley/Programs/public/numpy/numpy/distutils/__init__.py", >> line 21, in >>from numpy.testing import Tester >> File "/Users/lzkelley/Programs/public/numpy/numpy/testing/__init__.py", >> line 14, in >>from .utils import * >> File "/Users/lzkelley/Programs/public/numpy/numpy/testing/utils.py", line >> 17, in >>from numpy.core import float32, empty, arange, array_repr, ndarray >> File "/Users/lzkelley/Programs/public/numpy/numpy/core/__init__.py", line >> 59, in >>test = Tester().test >> File "/Users/lzkelley/Programs/public/numpy/numpy/testing/nosetester.py", >> line 180, in __init__ >>if raise_warnings is None and '.dev0' in np.__version__: >> AttributeError: 'module' object has no attribute '__version__' >> >> Build failed! >> >> >> Has anyone seen something like this before? >> >> Thanks! >> Luke >> >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> https://mail.scipy.org/mailman/listinfo/numpy-discussion >> > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 again pointing at PYTHONPATH. I hope these helps. Best, - Yu On Sun, Oct 18, 2015 at 1:25 PM, Luke Zoltan Kelley wrote: > 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 error: > > (numpy-py27)daedalus-2:numpy lzkelley$ ./runtests.py > Building, see build.log... > Running from numpy source directory. > Traceback (most recent call last): > File "setup.py", line 264, in > setup_package() > File "setup.py", line 248, in setup_package > from numpy.distutils.core import setup > File "/Users/lzkelley/Programs/public/numpy/numpy/distutils/__init__.py", > line 21, in > from numpy.testing import Tester > File "/Users/lzkelley/Programs/public/numpy/numpy/testing/__init__.py", > line 14, in > from .utils import * > File "/Users/lzkelley/Programs/public/numpy/numpy/testing/utils.py", line > 17, in > from numpy.core import float32, empty, arange, array_repr, ndarray > File "/Users/lzkelley/Programs/public/numpy/numpy/core/__init__.py", line > 59, in > test = Tester().test > File "/Users/lzkelley/Programs/public/numpy/numpy/testing/nosetester.py", > line 180, in __init__ > if raise_warnings is None and '.dev0' in np.__version__: > AttributeError: 'module' object has no attribute '__version__' > > Build failed! > > > Has anyone seen something like this before? > > Thanks! > Luke > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 error: (numpy-py27)daedalus-2:numpy lzkelley$ ./runtests.py Building, see build.log... Running from numpy source directory. Traceback (most recent call last): File "setup.py", line 264, in setup_package() File "setup.py", line 248, in setup_package from numpy.distutils.core import setup File "/Users/lzkelley/Programs/public/numpy/numpy/distutils/__init__.py", line 21, in from numpy.testing import Tester File "/Users/lzkelley/Programs/public/numpy/numpy/testing/__init__.py", line 14, in from .utils import * File "/Users/lzkelley/Programs/public/numpy/numpy/testing/utils.py", line 17, in from numpy.core import float32, empty, arange, array_repr, ndarray File "/Users/lzkelley/Programs/public/numpy/numpy/core/__init__.py", line 59, in test = Tester().test File "/Users/lzkelley/Programs/public/numpy/numpy/testing/nosetester.py", line 180, in __init__ if raise_warnings is None and '.dev0' in np.__version__: AttributeError: 'module' object has no attribute '__version__' Build failed! Has anyone seen something like this before? Thanks! Luke___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 reckoning. Even though ANSI C has the difftime(time_t time1, time_t time0) function which in theory may not reduce to time1 - time0, in practice it is only useful to avoid overflows in integer to float conversions in cross-platform code and cannot account for the fact some days are longer than others. Similarly, current numpy.datetime64 design ties arithmetic with encoding. This makes arithmetic easier, but in the long run may preclude designs that better match the problem domain. Note how the development of PEP 495 has highlighted the fact that allowing binary operations (subtraction, comparison etc.) between times in different timezones was a design mistake. It will be wise to learn from such mistakes when redesigning numpy.datetime64. If you ever plan to support civil time in some form, you should think about it now. In Python 3.6, datetime.now() will return different values in the first and the second repeated hour in the "fall-back fold." If you allow datetime.datetime to numpy.datetime64 conversion, you should decide what you do with that difference. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 don't do that. In some sense leap seconds are more similar to timezone changes (DST or political) because they are irregular and unpredictable. Furthermore, the notion of "fold" is not tied to a particular 24/60/60 system of encoding times and thus more applicable to numpy where times are encoded as binary integers. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion