<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 19, 2015 at 2:14 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Oct 18, 2015 at 9:35 PM,  <<a href="mailto:josef.pktd@gmail.com">josef.pktd@gmail.com</a>> wrote:<br>
>>>> np.column_stack((np.ones(10), np.ones(10))).flags<br>
>   C_CONTIGUOUS : True<br>
>   F_CONTIGUOUS : False<br>
><br>
>>>> np.__version__<br>
> '1.9.2rc1'<br>
><br>
><br>
> on my notebook which has numpy 1.6.1 it is f_contiguous<br>
><br>
><br>
> I was just trying to optimize a loop over variable adjustment in regression,<br>
> and found out that we lost fortran contiguity.<br>
><br>
> I always thought column_stack is for fortran usage (linalg)<br>
><br>
> What's the alternative?<br>
> column_stack was one of my favorite commands, and I always assumed we have<br>
> in statsmodels the right memory layout to call the linalg libraries.<br>
><br>
> ("assumed" means we don't have timing nor unit tests for it.)<br>
<br>
</span>In general practice no numpy functions make any guarantee about memory<br>
layout, unless that's explicitly a documented part of their contract<br>
(e.g. 'ascontiguous', or some functions that take an order= argument<br>
-- I say "some" b/c there are functions like 'reshape' that take an<br>
argument called order= that doesn't actually refer to memory layout).<br>
This isn't so much an official policy as just a fact of life -- if<br>
no-one has any idea that the someone is depending on some memory<br>
layout detail then there's no way to realize that we've broken<br>
something. (But it is a good policy IMO.)<br></blockquote><div><br></div><div>I understand that in general.</div><div><br></div><div>However, I always thought column_stack is a array creation function which have guaranteed memory layout. And since it's stacking by columns I thought that order is always Fortran.</div><div>And the fact that it doesn't have an order keyword yet, I thought is just a missing extension.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If this kind of problem gets caught during a pre-release cycle then we<br>
generally do try to fix it, because we try not to break code, but if<br>
it's been broken for 2 full releases then there's no much we can do --<br>
we can't go back in time to fix it so it sounds like you're stuck<br>
working around the problem no matter what (unless you want to refuse<br>
to support 1.9.0 through 1.10.1, which I assume you don't... worst<br>
case, you just have to do a global search replace of np.column_stack<br>
with statsmodels.utils.column_stack_f, right?).<br>
<br>
And the regression issue seems like the only real argument for<br>
changing it back -- we'd never guarantee f-contiguity here if starting<br>
from a blank slate, I think?<br></blockquote><div><br></div><div>When the cat is out of the bag, the down stream developer writes compatibility code or helper functions.</div><div><br></div><div>I will do that at at least the parts I know are intentionally designed for F memory order.</div><div><br></div><div>---</div><div><br></div><div>statsmodels doesn't really check or consistently optimize the memory order, except in some cython functions.</div><div>But, I thought we should be doing quite well with getting Fortran ordered arrays. I only paid attention where we have more extensive loops internally.</div><div><br></div><div>Nathniel, Does patsy guarantee memory layout (F-contiguous) when creating design matrices?</div><div><br></div><div>Josef</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-n<br>
<br>
--<br>
Nathaniel J. Smith -- <a href="http://vorpus.org" rel="noreferrer" target="_blank">http://vorpus.org</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div></div>