On Mon, Dec 12, 2011 at 12:33 PM, Marko Limbek <marko.lim...@valicon.net> wrote:
> Do you mean
> set_default_mode(NO_CONVERSION)
> or something else?
Yes, try the NO_CONVERSION mode of rpy v1, which
keeps the objects as R objects but allows you to access
them from Python.
> What you suggested is the second way of retreiving R
> objects, but I think it can only be used od R objects, that
> represent predefined built-in R functions. It can't be used
> it on the result I get from a method.
I think it can. Lots of my rpy code had things like this:
1. Set no conversion,
2. Generate complex object, say foo
3. Set default conversion
4. Call rpy.r("foo$var") or whatever to get a simple
variable which can safely be converted into a simple
python variable.
The hardest thing in using rpy v1 was object conversion,
when to allow it and when not to. In general I would keep
complex R objects unconverted (because converting them
to Python objects was lossy), especially if doing more
analysis with them within R.
> Anyway I will have to switch to rpy2, because the matching
> problem is apparently unsolvable here.
It probably can be solved, but you would be better off in
the long term moving to rpy2.
Peter
------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
