[Zope] Zope and R

[Ragnar Beer]

On 05 Feb 2002 05:31:41 -0800
rossini@blindglobe.net (A.J. Rossini) wrote:

> >>>>> "RB" == Ragnar Beer <rbeer@uni-goettingen.de> writes:
> 
>     RB> Thanks a lot! RSPython seems to be the most likely candidate
>     RB> for my purposes. I actually don't need R's interactive
>     RB> features in this case. What I need is a Python script that
>     RB> accesses an SQL database, unpickles data that is stored in a
>     RB> blob, and then generates an image (a rather large GIF) with a
>     RB> predefined style or calculates a couple of coefficients.
>     RB> Generating images seems to be the hardest part. How are you
>     RB> handling temporary files with more than one concurrent thread
>     RB> and possible security issues? I've never used temporary files
>     RB> so far.
> 
> If you want this to really work, I'd go one further than Seb's
> "critical" comments (remember, I'm an academic, I can afford crashes,
> especially of the "crash early, crash often" in research projects :-),
> and suggest using Python, PIL, or GDchart for this, NOT R.   Really,
> "right tools for the job", "stability", and all that stuff.
> 
> Instead, for numerics, I'd suggest NumPy or SciPy (both excellent,
> though lacking some (all!)  of S/R's better features for data analysis
> and annotation), for the computations.
> 
> I've done just as well with Python's SQL methods as I've done with R's
> (maybe better), and there are a number of Zope products for doing what
> you are proposing.
> 
> Python seems to be a better choice -- I've been doing Flow Cytometry
> analysis in both R and Python (flow cyt files are like the files you
> are describing) and Python definitely has better behaviour (not to
> mention that you'll have a 1-2 second start-up cost server-side for
> getting R "fired up").
> 
> Now if you are looking at incorporating R for a "lab
> workbench/notebook" style project, that would be a another story...

Hmm, do you mean RSPython shouldn't be used in a production environment because RSPython *itself* isn't ready for production or would it rather be *my* code that'd crash for trial-and-error reasons?

Cheers,

Ragnar