LispStat, R and ViSta [was: Re: Status?]
Duncan Temple Lang
duncan@research.bell-labs.com
Wed, 21 Aug 2002 15:06:21 -0400
Hi Forrest.
It is definitely preferable to avoid giving up existing XLisp-Stat
code, especially when the facilities you probably want are not
currently part of R. Working from the RGtk or tcltk packages to create
dynamic graphics involves a lot of work, both design and programming
given that the R graphics are based on a static model.
I wonder if ggobi and the programmatic access via Rggobi and RGtk
would give you similar facilities to what currently exists in XLisp.
As you mention, it would be easiest to combine R and XLisp-Stat so
that you could use existing XLisp code and make use of R's statistical
functionality, etc. This is a perfect example for the use of embedding
one system inside the other; something we have done as part of the
Omegahat project for numerous languages.
So with some vital help from Luke, I have created an R package that
provides a very experimental interface between R and XLisp by allowing
XLisp to be embedded in R. The package contains and requires some
minor modifications to XLisp which allow it to be used as a shared
library and currently this only works on Unix. It allows one to call
arbitray XLisp functions, however there is an issue with the graphics
that I haven't sorted out yet. It did take less than a day
to put together so far, so I am reasonable confident that I and others
can iron out the details and make it reasonably complete and robust.
The package is available from
http://www.omegahat.org/RXLisp
Given that I only spent a day on it, don't expect too much
in the way of documentation, etc. Just e-mail me if you
have problems. I'd be very happy to hear from interested
people and we can
Duncan.
uluru@email.unc.edu wrote:
> I have been taking a break for the last month or so, and am only just
> now catching up on my email. Otherwise, I would have joined this
> discussion earlier. And... I apologize for the length of this, but I
> don't think it is overly long.
>
> >From the amount of activity in the LispStat news group (none), it seems
> that LispStat is dead. We all know that Luke is working on R and not on
> LispStat, and that Jan has switched UCLA over from LispStat to R. And we
> have not heard from users of LispStat for some time. So, it seems no
> one is using LispStat.
>
> For me, at least, this is not the case. As the developer of ViSta, I
> have and still am using LispStat a great deal. In fact, I cannot
> conceive of doing what I do with any other system.
>
> Of course, since I use it so much, I am very aware of LispStat's
> strengths and weaknesses, and want to add my views to the discussion.
> However, I spend all my time using only LispStat, so I can't make any
> comparisons to R or to any other systems.
>
> To me, the strengths of LispStat are:
> 1) The dynamic, highly interactive graphics
> 2) The object system
> 3) Lisp language and byte compiler
>
> These strengths make LispStat an ideal system for implementing
> statistical systems. It is less suited for doing statistical analysis.
> As a result, the most significant uses of LispStat have been statistical
> systems such as Arc and ViSta.
>
> In the work I've done with LispStat, ViSta's spreadplot architecture is
> the best example of LispStat being used to implement a statistical
> (sub)system (described in a forthcoming JCGS paper by myself, Pedro
> Valero, Richard Faldowski and Carla Bann).
>
> The weaknesses of LispStat are:
> 1) No high-level analysis modules
> 2) No standards for data sets, models, etc.
> 3) No user-oriented data manipulation language
> 4) Totally inadequate documentation
> 5) Poor or non-existant printing
> 6) No static graphic manipulation facilities
> 7) The underlying operating system interfaces are old.
>
> ViSta attempts to take care of these weaknesses, with varying degrees of
> success. Specifically:
> 1) ViSta has high-level analysis plugins. The method for writing these
> plugins is documented. I believe this very well solves the first weakness.
> 2) ViSta's statistical object architecture -- a hierarchy of objects
> that include datasets, datasheets, data editors, transformations,
> analysis methods, models and plugins --- solves the lack of standards
> for such things. The implementation is slow for data objects and needs
> to be re-architected. The implementation for the others is more than
> adequate.
> 3) At the suggestion of Sandy Weisberg, I have incorporated PARCIL, a
> C-to-Lisp Parser. This allows users to type a=2*(b+c)^2 rather than the
> awkward lisp equivalent:
> (setf a (^ (* 2 (+ b c)) 2))
> (I'm sorry I can't give a proper reference to PARCIL, I'm not at home).
> 4) Pedro Valero, Gabriel Molina, Michael Friendly and I, in various
> combinations, are working on the documentation problem.
> 5) Printing, while better than LispStat, is still not adequate.
> 6) Static graphics manipulation, as in SAS (and, apparently R), is
> totally lacking.
> 7) Nothing has been done about this.
>
> (Note that the newest version of ViSta use a modified version of
> LispStat that only works under Windows, so that Mac/Unix users don't
> have all the new features. This problem can be fixed by someone familiar
> with LispStat and Unix.)
>
> I am very interested in an effort to combine the strengths of LispStat
> and R, but have no clue how it would be done. From my viewpoint,
> though, it would need to add the three strengths of LispStat (Lisp,
> Objects and Dynamic Graphics) to the existing R environment, and it
> would need to work in all three supported environments -- Windows, Mac,
> and Linux/Unix
>
> Anyone know how to do that?
>
> Forrest
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
--
_______________________________________________________________
Duncan Temple Lang duncan@research.bell-labs.com
Bell Labs, Lucent Technologies office: (908)582-3217
700 Mountain Avenue, Room 2C-259 fax: (908)582-3340
Murray Hill, NJ 07974-2070
http://cm.bell-labs.com/stat/duncan
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._