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

[Luke Zoltan Kelley]

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] [SciPy-Dev] Setting up a dev environment with conda

[Feng Yu]

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

[Luke Zoltan Kelley]

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

[Michael Sarahan]

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

[Nathaniel Smith]

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] Making datetime64 timezone naive

[Alexander Belopolsky]

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] [SciPy-Dev] Setting up a dev environment with conda

[Luke Zoltan Kelley]

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

[Robert McGibbon]

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] when did column_stack become C-contiguous?

[josef.pktd]

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

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

[josef.pktd]

>>> 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] when did column_stack become C-contiguous?

[josef.pktd]

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?

[josef.pktd]

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

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

[Stephan Hoyer]

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] Making datetime64 timezone naive

[Alexander Belopolsky]

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