I took the time to do that a little earlier.
There are adaptations to the patch, and the numpy-capabilities are
confined to a module (this way, no conditional import - and you can have
more freedom to modify further your code).
It also made me realize shortcomings in the design of
rpy2.robjects-level conversion. I just committed a proposed improvement
(that does not break much of the existing API).
The usage is:
import rpy2.robjects
# this line adds numpy conversion capabilities
import rpy2.robjects.numpy2ri
L.
On Mon, 2008-11-17 at 10:33 -0800, Nathaniel Smith wrote:
> On Mon, Nov 17, 2008 at 8:01 AM, laurent <[EMAIL PROTECTED]> wrote:
> > On Sun, 2008-11-16 at 22:25 -0800, Nathaniel Smith wrote:
> >> rpy2 is awesome.
> >>
> >> But I was disconcerted to discover passing a numpy array to an R
> >> function just makes things blow up ("Nothing can be done for that
> >> type...") --
> >
> > Complete error messages are:
> > "Nothing can be done for this array type at the moment."
> > or
> > "Nothing can be done for the type %s at the moment." %(type(o))
> >
> > The attentive reader will note the time statement "at the moment",
> > denoting the likely intent of restricting the behaviour to a limited
> > stretch of time.
>
> Indeed -- I figured I'd go the next step and limit that time period
> still further.
>
> >> who uses rpy without numpy?
> >
> > The R-to-numpy bridge is (officially) working.
> > (The other way around is not sorted out - I'd like to have that at the
> > lower level -rpy2.rinterface- as well).
>
> That seems logical, but thinking about it I'm not sure what exactly it
> would entail -- SexpVector already does accept ndarray's just fine
> (only 1-dimensional ones, but R vectors are always 1-dimensional
> anyway, so that seems reasonable). The things my patch actually adds
> are just teaching py2ri to use SexpVector's in this case, and to do
> some extra dispatching through r["array"] and r["data.frame"] where
> appropriate.
>
> > It is currently possible to create vector/array structures in R and use
> > them with numpy.
>
> I know -- it's very slick.
>
> >> The patch does not introduce any dependency on numpy, is against
> >> current trunk,
> >
> > That's fine, trunk is currently 2.1-dev.
> > 2.0.x is already in a branch.
>
> I noticed that, but wasn't sure what your stable branch policy was --
> I'm happy to backport to the branch as well, if that's preferred. (I
> suspect the patch will just apply as is.)
>
> > I'd like to review the patch before inclusion (hopefully next week-end).
>
> Thanks.
>
> -- Nathaniel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
