Huh, the numpy qr failure is a bit worrisome... did you notice why? I
suppose it might just be that you need a "full" rather than "economic" qr,
and the API for requesting a full qr in numpy is in the middle of a messy
transition, so sticking with scipy in that case seems good. I'm just a
little nervous in case there's some deeper reason, where later scipy might
stop working too or something.


On Tue, Jun 3, 2014 at 9:37 PM, broessli <notifications@github.com> wrote:

> In patsy/mgcv_cubic_splines.py:
>
> > +# This file is part of Patsy
> > +# Copyright (C) 2014 Nathaniel Smith <njs@pobox.com
> >
> > +# See file LICENSE.txt for license information.
> > +
> > +# R package 'mgcv' compatible cubic spline basis functions
> > +
> > +# These are made available in the patsy.* namespace
> > +__all__ = ["cr", "cs", "cc", "ms", "te"]
> > +
> > +import warnings
> > +import numpy as np
> > +
> > +try:
> > +    from scipy import linalg
> > +except ImportError:
> > +    raise ImportError("Cubic spline functionality requires scipy.")
>
> Yep, I need scipy in _get_natural_f but also for qr() in
> _absorb_constraints since numpy's version of qr() make the tests fail :-(
> I will move the scipy import check/error to these two functions.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/pydata/patsy/pull/43/files#r13357641>.
>



-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org