Stateful transforms compatible with 'mgcv' R package

Hi!
I've added the file *mgcv.py* containing the code for the following stateful transforms: *cr/cs*, *cc* and *te*.
Benoît. 
After reading your answer I checked eval.py's code and realized that it is
already automatically handling stateful transforms machinery in case of
composition (as it should)...Oops... Your suggestion will work just fine!

Le dimanche 29 juin 2014, Nathaniel J. Smith <notifications@github.com> a
écrit :

> In patsy/mgcv_cubic_splines.py:
>
> > +
> > +def ms(smooth_st, **kwargs):
> > +    """Defines a marginal smooth with its specific parameters.
> > +
> > +    :param smooth_st: The stateful_transform associated with the marginal
> > +     smooth.
> > +    :param kwargs: Smooth specific keyworded arguments.
> > +    :return: Dictionary containing smooth object's type (key: 'smooth_type')
> > +     and associated keyworded arguments (key: 'kwargs').
> > +
> > +    :raise ValueError: if the requested smooth is not supported or if it has
> > +     a defined ``constraints`` argument.
> > +    """
> > +    if smooth_st.__name__ not in TE.supported_marginal_smooths:
> > +        raise ValueError("Unsupported marginal smooth '%r'."
> > +                         % (smooth_st.__name__,))
>
> If te doesn't actually need to know about the inner workings of the
> spline basis generation functions and just calls them, then this makes me
> wonder whether we should just make the syntax
>
> te(cr(x1, ...), cr(x2, ...), constraint="center")
>
> From te's point of view, this would mean that it just receives a set of
> pre-transformed basis vectors as its positional arguments, and all it has
> to worry about is taking the tensor product and applying the constraint. It
> would still need to be a stateful transform in order to handle
> constraints="center", but it wouldn't need nearly so much complicated
> messing about with the stateful transform machinery. Also, if all we're
> trying to do is compute the mean of the tensor product matrices then it
> should be possible to do this without storing tons of intermediate data --
> see patsy.state.Center. What do you think? Would this work?
>
> [P.S.: I'd appreciate if you could avoid using the word "lame"
> <http://bunnika.wordpress.com/2012/06/02/thats-so-lame/> (which literally
> refers to people who have difficulty walking) as a generic term for things
> that are bad. No need to reply to this part.]
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/pydata/patsy/pull/43/files#r14331238>.
>


-- 

Benoît.