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: [...] > > >> 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.
Yes, I have briefly seen that you are doing it at the rpy2.robjects level. That's certainly a good way to go when wanting to offer such capability. Regarding SexpVector accepting numpy's one-dimensional arrays, that's because anything that provides the sequence protocol is accepted by the constructor. A potential drawback of the approach is that there is copying of the data from Python/numpy to the embedded R process (and that can be a significant penalty on performances when working with large(r) data sets), and I hoped I could avoid that. I am also aware that there is already copying when creating R vectors from array.array instances anyway, and the benefit of having something working at the rpy2.robjects level right now is looking greater than me fussing about an hypothetical perfect solution. It is also always possible to copy any voluminous numpy object to R once, then delete that numpy object and recreate one from the R object (making both point to the same underlying data). > > > 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 am not sure myself ;-) I was thinking that rpy2-2.0.x would only know bug fixes... that's the theory, as I am still finding annoying little obvious design problems at 2.0.0-release candidate, but I'd like to keep as close to it as I can. The patch does not seem to be changing much of the existing API, and will certainly be something good to have in 2.0.x. > I'm happy to backport to the branch as well, if that's preferred. (I > suspect the patch will just apply as is.) Very likely it will (I don't think I started modifying rpy2.robjects in the trunk yet). > > I'd like to review the patch before inclusion (hopefully next week-end). > > Thanks. Well, thanks for the patch and the thought-provoking intervention. Laurent > -- 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
