Is Xlisp-Stat Dead?
Robert
Did SAS and SPSS chop it to pieces?
What happened to it?
Rainer Joswig
<78de26c1-fb05-4479...@i72g2000hsd.googlegroups.com>,
Robert <irish...@gmail.com> wrote:
See: http://repositories.cdlib.org/uclastat/papers/2004062201/
On Abandoning Xlisp-Stat
Jan de Leeuw, UCLA Department of Statistics
Tamas
> In article
> <78de26c1-fb05-4479-ac5f-97046de54...@i72g2000hsd.googlegroups.com>,
>
> Robert <irishhac...@gmail.com> wrote:
> > Did the founders of R cut it's head off?
> > Did SAS and SPSS chop it to pieces?
> > What happened to it?
>
> See:http://repositories.cdlib.org/uclastat/papers/2004062201/
>
> On Abandoning Xlisp-Stat
> Jan de Leeuw, UCLA Department of Statistics
Thanks, that was an interesting read, I didn't know that story
before. I switched to CL from R, and while I understand that the
syntax is more friendly for those who are used to Matlab or Fortran, I
find CL infinitely preferable and in fact I feel crippled when I have
to program in R. But I am an economist, not a statistician...
Tamas
Rainer Joswig
<8b36b08d-f1a9-4c97...@c23g2000hsa.googlegroups.com>,
Tamas <tkp...@gmail.com> wrote:
If code is written in Common Lisp, there is a chance that
it survives and others can pick it up. Maintaining a
special Lisp dialect and implementation for an application
is less desirable - especially when the dialect/implementation
does not provide any really special facilities.
Nicolas Neuss
> If code is written in Common Lisp, there is a chance that
> it survives and others can pick it up. Maintaining a
> special Lisp dialect and implementation for an application
> is less desirable - especially when the dialect/implementation
> does not provide any really special facilities.
I have also heard this story only now, thanks for the link. Having read it
I also tend to the opinion that one problem lies in Xlisp-Stat being not
Common Lisp. Do you know what the major obstacles were for porting it to
(or embedding it into) Common Lisp?
I would also be interested in the license (and could not immediately find
it). Was it a free license, or did it have restrictions like allowing only
academic use?
Thanks again,
Nicolas
Harald Hanche-Olsen
> I would also be interested in the license (and could not immediately
> find it). Was it a free license, or did it have restrictions like
> allowing only academic use?
I have only an old (1990) version sitting around, but the license
seems quite free: You could do what you want, but include the
copyright notice, no funny restrictions. Apparently xlisp did have a
"no commercial use" license before, but this restriction was lifted.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
ddd
<han...@math.ntnu.no> wrote:
>
> I have only an old (1990) version sitting around, but the license
> seems quite free: You could do what you want, but include the
> copyright notice, no funny restrictions. Apparently xlisp did have a
> "no commercial use" license before, but this restriction was lifted.
>
Be careful about the license: xlisp and xlisp-stat are different
implementations and (depending on the version) have different
licenses. The xlisp-stat license is somewhat like the old BSD license.
There is an old port of lisp-stat for common lisp. Here an extract
form the readme:
"This directory contains Lisp-Stat 1.0 Alpha 1, a first attempt at
producing a Common Lisp version of Lisp-Stat. This version contains NO
graphics, but should implement all the non-graphical facilities of
Lisp-Stat.
The implementation uses C code from XLISP-STAT for linear algebra and
probability distributions, so this code is dependent an a CL's foreign
function interface. At this time, three CL's are supported: AKCL (at
least verision 1-600) for UNIX systems, Franz' Allegro CL for UNIX
systems, and Macintosh CL (version 2.0b1). Separate README files
describe each version"
There is also some talk of a port to clisp and CLOS, however I don't know
anything particular.
The nice thing about xlispstat is its cross platform gui (X, Win,
Mac), its prototype object system (no CLOS), and of course the
math/stat.
The sources compile on linux and cygwin.
cheers
Ross Ihaka
I'm one of the two originators of R. After reading Jan's
paper I wrote to him and said I thought it was interesting
that he was choosing to jump from Lisp to R at the same
time I was jumping from R to Common Lisp.
Building something like R is a big task though. The
capabilities in R reflect the specialist contributions
of hundreds of research statisticians. Currently there
is a very small group of us scoping out ways to create
a Lisp-based framework in which similar contributions
could be made.
Marco Antoniotti
> Rainer Joswig wrote:
> > In article
> > Robert <irishhac...@gmail.com> wrote:
>
> >> Did the founders of R cut it's head off?
> >> Did SAS and SPSS chop it to pieces?
> >> What happened to it?
>
> > See:http://repositories.cdlib.org/uclastat/papers/2004062201/
>
> > On Abandoning Xlisp-Stat
> > Jan de Leeuw, UCLA Department of Statistics
>
> I'm one of the two originators of R. After reading Jan's
> paper I wrote to him and said I thought it was interesting
> that he was choosing to jump from Lisp to R at the same
> time I was jumping from R to Common Lisp.
>
> Building something like R is a big task though. The
> capabilities in R reflect the specialist contributions
> of hundreds of research statisticians. Currently there
> is a very small group of us scoping out ways to create
> a Lisp-based framework in which similar contributions
> could be made.
I am interested in the effort. I think that one of the key issues is
the definition of a decent "data massaging" (for lack of a better
word) library. I like the R solution for this.
Cheers
--
Marco
Ken Tilton
Ross Ihaka wrote:
> Rainer Joswig wrote:
>
>> In article
>> <78de26c1-fb05-4479...@i72g2000hsd.googlegroups.com>,
>> Robert <irish...@gmail.com> wrote:
>>
>>> Did the founders of R cut it's head off?
>>> Did SAS and SPSS chop it to pieces?
>>> What happened to it?
>>
>>
>> See: http://repositories.cdlib.org/uclastat/papers/2004062201/
>>
>> On Abandoning Xlisp-Stat Jan de Leeuw, UCLA Department of Statistics
>
>
> I'm one of the two originators of R. After reading Jan's
> paper I wrote to him and said I thought it was interesting
> that he was choosing to jump from Lisp to R at the same
> time I was jumping from R to Common Lisp.
Damn, I came this close to wondering aloud how silly Jan would feel when
they switch back to Lisp. :) I wondered that only because of all the
negatives he expressed in re s/r, and all the positives for Lisp. That
said, eyeballing the R site is does look to be a standard.
So how come an originator of something with the momentum and mindshare
of R is swimming against the current, and one he helped set in motion to
boot?
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ross Ihaka
> So how come an originator of something with the momentum and mindshare
> of R is swimming against the current, and one he helped set in motion to
> boot?
We started work on R in the early '90s. At the time
decent Lisp implementations required much more resources
than our target machines had. We therefore wrote a small
scheme-like interpreter and implemented over that.
Being rank amateurs we didn't do a great job of the
implementation and the semantics of the S language which
we borrowed also don't lead to efficiency (there is a
lot of copying of big objects).
R is now being applied to much bigger problems than we
ever anticipated and efficiency is a real issue. What
we're looking at now is implementing a thin syntax over
Common Lisp. The reason for this is that while Lisp is
great for programming it is not good for carrying out
interactive data analysis. That requires a mindset better
expressed by standard math notation. We do plan to make
the syntax thin enough that it is possible to still work
at the Lisp level. (I believe that the use of Lisp syntax
was partially responsible for why XLispStat failed to gain
a large user community).
The payoff (we hope) will be much greater flexibility and
a big boost in performance (we are working with SBCL so
we gain from compilation). For some simple calculations
we are seeing orders of magnitude increases in performance
over R, and quite big gains over Python.
There is lots to do. We're experimenting with syntax and
making a start on assembling quality numerics libraries.
Creating a fully-featured system will require buy-in from
the statistical specialists who can contribute implementations
of their methodology, so we also thinking about issues
associated with community building (eg. licensing).
Rainer Joswig
Ross Ihaka <ih...@stat.auckland.ac.nz> wrote:
What you say makes sense to me.
Just as a note: Just was looking what Statistics (and related)
stuff for CL is available on the net. It's not that much. But
still some interesting packages:
http://lib.stat.cmu.edu/sapaclisp/
http://compbio.uchsc.edu/Hunter_lab/Hunter/cl-statistics.lisp
http://compbio.uchsc.edu/Hunter_lab/Hunter/cl-statistics-doc.txt
Some tools and libs (CLASP, ...)
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/math/0.html
http://dan.corlan.net/R_to_common_lisp_translator/
Quantitative analysis in Lisp
http://www.stats.uwaterloo.ca/Quail/
image analysis
http://www.nist.gov/lispix/MLxDoc/mlx.html
SigLab, signal processing analysis pipeline
http://homepage.mac.com/dbmcclain
http://www.lispworks.com/success-stories/raytheon-siglab.html
InspireData, data analysis tool
http://www.inspiration.com/productinfo/inspiredata/index.cfm
SciGraph, software for graphing numeric data (using CLIM)
http://openmap.bbn.com/~kanderso/lisp/scigraph/
http://iridia0.ulb.ac.be/pulcinella/
http://wwww.common-lisp.net/project/cl-graph/
http://common-lisp.net/project/cl-mathstats/
"Arizona": collection of tools supporting scientific computing, ...
www.stat.washington.edu/www/research/reports/1988/tr131.pdf
Ken Tilton
Ross Ihaka wrote:
> Ken Tilton wrote:
>
>> So how come an originator of something with the momentum and mindshare
>> of R is swimming against the current, and one he helped set in motion
>> to boot?
>
>
> We started work on R in the early '90s. At the time
> decent Lisp implementations required much more resources
> than our target machines had. We therefore wrote a small
> scheme-like interpreter and implemented over that.
I am having vague flashbacks to my circuitous route from and then back
to Lisp, tho the from was Logo. I would have switched to CL when it was
time to repot my project from Logo but the Lisp's were not ready. Next
time I repotted they were.
>
> Being rank amateurs we didn't do a great job of the
> implementation and the semantics of the S language which
> we borrowed also don't lead to efficiency (there is a
> lot of copying of big objects).
>
> R is now being applied to much bigger problems than we
> ever anticipated and efficiency is a real issue. What
> we're looking at now is implementing a thin syntax over
> Common Lisp. The reason for this is that while Lisp is
> great for programming it is not good for carrying out
> interactive data analysis. That requires a mindset better
> expressed by standard math notation. We do plan to make
> the syntax thin enough that it is possible to still work
> at the Lisp level.
Well, do what they did in '58, get the functionality going with parens
and then do the syntactic sugar, you might not ever have to. :)
otoh, I am not asking Algebra students to use prefix notation:
http://www.theoryyalgebra.com/demo-25.html
...so I guess it's OK to coddle your statisticians... actually, come to
think of it, math notation is pretty efficient. Lemme know if you need a
WYSIWYG math editor (not fun), I could use the work.
I'll leave the rest untrimmed just to piss off Maciej.
kt
> (I believe that the use of Lisp syntax
> was partially responsible for why XLispStat failed to gain
> a large user community).
>
> The payoff (we hope) will be much greater flexibility and
> a big boost in performance (we are working with SBCL so
> we gain from compilation). For some simple calculations
> we are seeing orders of magnitude increases in performance
> over R, and quite big gains over Python.
>
> There is lots to do. We're experimenting with syntax and
> making a start on assembling quality numerics libraries.
> Creating a fully-featured system will require buy-in from
> the statistical specialists who can contribute implementations
> of their methodology, so we also thinking about issues
> associated with community building (eg. licensing).
--
Robert Dodier
> R is now being applied to much bigger problems than we
> ever anticipated and efficiency is a real issue. What
> we're looking at now is implementing a thin syntax over
> Common Lisp.
Well, I wonder if you have looked at Maxima, a computer algebra
program written in CL. The Maxima language is sort of a watered-
down Algol derivative; it is rather idiosyncratic, but I don't think
it
would be hard to replace it. Anyway, it is easy to drop into Lisp
from Maxima, and easy to write stuff in Lisp and get Maxima to
call it and vice versa.
I believe Maxima has a lot of potential as a tool for statistics,
through the combination of symbolic and numerical programming.
There are some basic statistical packages at present, and I am
hoping we'll write more in the near future. I have a special
interest in Bayesian inference; I believe that's especially suitable
for mixed symbolic/numerical methods.
For better or worse, code written in Maxima is typically much,
much slower than similar code written in Lisp, because Maxima
assumes any and every result might be symbolic instead of
numerical. There is a Maxima --> Lisp translator but from what I
can tell it only speeds stuff up by, say, a factor of 10 when 100
or 1000 is needed to match native (purely numeric) Lisp code.
But a Maxima function could easily detect if all arguments are
numbers and then punt to a Lisp library for that case; then almost
all of the processing would be in native Lisp code.
> There is lots to do. We're experimenting with syntax and
> making a start on assembling quality numerics libraries.
If/when you have some CL libraries to release, we'll be very
interested to hear about it. I would be inclined to consider
merging it into Maxima (only if the license permits, of course).
Maxima has absorbed various numerical packages over the
years and it's likely that trend will continue.
Incidentally recently we've discussed a Maxima implementation
of R's data frame object. In this case we're borrowing a design
instead of code.
best,
Robert Dodier
Maxima developer
Ross Ihaka
> I believe Maxima has a lot of potential as a tool for statistics,
> through the combination of symbolic and numerical programming.
> There are some basic statistical packages at present, and I am
> hoping we'll write more in the near future. I have a special
> interest in Bayesian inference; I believe that's especially suitable
> for mixed symbolic/numerical methods.
Indeed, Maxima is used in statistics, but toward the theoretical
end of the scale. As I mentioned we are pretty keen on performance
and that is driving things at present.
> If/when you have some CL libraries to release, we'll be very
> interested to hear about it. I would be inclined to consider
> merging it into Maxima (only if the license permits, of course).
> Maxima has absorbed various numerical packages over the
> years and it's likely that trend will continue.
Among many reasons to move to Lisp that it becomes possible to
start to play with the big kids. We will hopefully produce some
software modules which are useful to others and maybe to you guys.
Ross Ihaka
Thanks, most of this I've seen, but ...
> "Arizona": collection of tools supporting scientific computing, ...
> www.stat.washington.edu/www/research/reports/1988/tr131.pdf
Its great to see that John McDonald's stuff is on line.
There are some very interesting ideas there.
Ken Tilton
Ross Ihaka wrote:
> Robert Dodier wrote:
>
> Among many reasons to move to Lisp that it becomes possible to
> start to play with the big kids. We will hopefully produce some
> software modules which are useful to others and maybe to you guys.
de Leeuw reported funny looks from others over still (back then) using
Lisp as one factor in the decision to move on. I am curious if the arrow
has changed on that either in the attitude of others who are not giving
you funny looks for returning to Lisp or in your team's attitude such
that you have come to enjoy the funny looks.
This a great story, a winter inside a winter. The next thing you know
people will be doing AI in Lisp <gasp!>.
Rainer Joswig
Ross Ihaka <ih...@stat.auckland.ac.nz> wrote:
More here: http://jamcdonald.home.att.net/
------------------------------------------------------------------
For some old-school stuff that might be interesting
for some comp.lang.lisp readers: Videos of historical
software on the Lisp Machine. ;-)
Here a demo of Dataviewer (1987), a tool for the
Symbolics Lisp Machine, here analyzing Landsat satellite images:
http://stat-graphics.org/movies/tour-sensing.html
---
Here is another tool (DINDE, 1986), this time for the InterLisp machine
from Xerox written in LOOPS:
http://stat-graphics.org/movies/dinde.html
---
Plot Windows on a Symbolics Lisp Machine (1987)
http://stat-graphics.org/movies/odds-plots.html
---
Antelope: Data Analysis with Object Oriented Programming and Constraints
(1987), running a Symbolics Lisp Machine
http://stat-graphics.org/movies/antelope.mpg
---
Dataviewer: A Program for Looking at Data in Several Dimensions
(1987), running on a Symbolics Lisp Machine
http://stat-graphics.org/movies/dataviewer.html
---
Focusing and Linking as Paradigms for the Visualization of High-Dimensional Data
Symbolics Lisp Machine is being used.
Martin Rubey
> Ross Ihaka wrote:
>
> > R is now being applied to much bigger problems than we
> > ever anticipated and efficiency is a real issue. What
> > we're looking at now is implementing a thin syntax over
> > Common Lisp.
>
> Well, I wonder if you have looked at Maxima, a computer algebra program
> written in CL. The Maxima language is sort of a watered- down Algol
> derivative; it is rather idiosyncratic, but I don't think it would be hard to
> replace it. Anyway, it is easy to drop into Lisp from Maxima, and easy to
> write stuff in Lisp and get Maxima to call it and vice versa.
For what it's worth, the second CAS written in Common Lisp, axiom (FriCAS is
the fork I personally favour, but it shouldn't matter), also allows this.
For example, we just reuse integer arithmetic from Lisp. The line
random(x) == RANDOM(x)$Lisp
in the axiom domain integer defines the function random to be just the random
function from the underlying Common Lisp.
I.e., it is trivial to call lisp from within axiom. The other way round is
also possible, although I must admit that I do not know the details. In
principle, it works like:
(1) -> )lisp (|interpret| '(|integrate| (^ X 2) X)))
Value = ((|Polynomial| (|Fraction| (|Integer|))) WRAPPED 1 X
(3 0 1 . 3))
It is not necessary to use the interpreter as above, but then one needs to know
the precise function call...
Martin
Nicolas Neuss
> I.e., it is trivial to call lisp from within axiom. The other way round
> is also possible, although I must admit that I do not know the details.
> In principle, it works like:
>
> (1) -> )lisp (|interpret| '(|integrate| (^ X 2) X)))
>
> Value = ((|Polynomial| (|Fraction| (|Integer|))) WRAPPED 1 X
> (3 0 1 . 3))
>
> It is not necessary to use the interpreter as above, but then one needs
> to know the precise function call...
What I would prefer is to load FRICAS as an add-on library with asdf. Is
this possible, or are there any plans to support this?
Thanks, Nicolas
Martin Rubey
To be honest, I do not even know what this would mean. But I'll forward this
to the mailing list.
Just for clarification: what would you like to be able to do?
Martin
PS: I just thought of a possibly more interesting example:
)lisp (|interpret| '(|::| (((|guessPRec| (|construct| 0 1 4 9)) 1) |function|) OUTFORM))
Value = ((|OutputForm|) WRAPPED "**" |n| 2)
Nicolas Neuss
> Nicolas Neuss <last...@math.uni-karlsruhe.de> writes:
>
>> What I would prefer is to load FRICAS as an add-on library with asdf. Is
>> this possible, or are there any plans to support this?
>
> To be honest, I do not even know what this would mean. But I'll forward this
> to the mailing list.
>
> Just for clarification: what would you like to be able to do?
I want to work in Common Lisp but have access to CAS functionality. I
might need this, for example, in computing quadrature rules to high
accuracy in my PDE solver Femlisp, or for posing and solving symbolic math
exercises for students.
From within Common Lisp, I want to do something like
(load "fricas/start.lisp")
and after this command I want to have the FRICAS functionality available,
e.g. for commands like
(fricas:eigenvectors (fricas:read-matrix-from-string "[x,1;1/x,-1]"))
(sorry, I do not really know Fricas/Axiom, so I used Matlab matrix
notation).
Even better would be if Fricas was ASDF-compatible. Then loading it could
be done by (not much nicer, but without giving a precise path)
(asdf:asdf 'asdf:load-op :fricas)
which would load FRICAS (if it can be found between my libraries).
Additionally, other ASDF libraries could simply mention Fricas in their
dependency list.
Nicolas
P.S.: With Maxima, version 1 is possible, and version 2 probably could be
implemented as well rather easily (I think, by default, Maxima uses
mk:defsystem, which is an alternative to ASDF).
Rainer Joswig
Martin Rubey <axio...@yahoo.de> wrote:
> Nicolas Neuss <last...@math.uni-karlsruhe.de> writes:
>
> > Martin Rubey <axio...@yahoo.de> writes:
> >
> > > I.e., it is trivial to call lisp from within axiom. The other way round
> > > is also possible, although I must admit that I do not know the details.
> > > In principle, it works like:
> > >
> > > (1) -> )lisp (|interpret| '(|integrate| (^ X 2) X)))
> > >
> > > Value = ((|Polynomial| (|Fraction| (|Integer|))) WRAPPED 1 X
> > > (3 0 1 . 3))
> > >
> > > It is not necessary to use the interpreter as above, but then one needs
> > > to know the precise function call...
> >
> > What I would prefer is to load FRICAS as an add-on library with asdf. Is
> > this possible, or are there any plans to support this?
>
> To be honest, I do not even know what this would mean. But I'll forward this
> to the mailing list.
Ideally one would start a Lisp, load Axiom into it, have a command line
for it and another one for Lisp - so that one can use both. Many
Lisp implementations are multi-threaded and allow more than one
command loop at the same time. So one could work on
mathematical algorithms on the command line and implement
some other stuff in a Lisp command line. Both would
be running in one Lisp system. Say, one would use the user environment
of McCLIM (including Climacs (the editor) and the McCLIM command loops)
and use Axiom in it - even develop some integration for Axiom
into the McCLIM environment - so for example that Axiom results
can be presented in McCLIM (graphically and textually).
Is that possible?
The other way would be that loading Axiom would give me only
Axiom then (Lisp then is only accessible via Axiom).
Martin Rubey
below)
Nicolas Neuss <last...@math.uni-karlsruhe.de> writes:
> Martin Rubey <axio...@yahoo.de> writes:
>
> > Nicolas Neuss <last...@math.uni-karlsruhe.de> writes:
> >> What I would prefer is to load FRICAS as an add-on library with asdf.
[...]
> > Just for clarification: what would you like to be able to do?
> I want to work in Common Lisp but have access to CAS functionality. I might
> need this, for example, in computing quadrature rules to high accuracy in my
> PDE solver Femlisp, or for posing and solving symbolic math exercises for
> students.
> From within Common Lisp, I want to do something like
> (load "fricas/start.lisp")
> and after this command I want to have the FRICAS functionality available,
> e.g. for commands like
>
> (fricas:eigenvectors (fricas:read-matrix-from-string "[x,1;1/x,-1]"))
>
> (sorry, I do not really know Fricas/Axiom, so I used Matlab matrix
> notation).
(1) -> radicalEigenvectors [[x, 1], [1/x, -1]]
(1)
[
+------------------+
| 4 3 2 2
- \|x + 2x + x + 4x + x - x
[radval= --------------------------------, radmult= 1,
2x
+ +------------------+ +
| | 4 3 2 2 |
|- \|x + 2x + x + 4x + x + x|
radvect= [|--------------------------------|]]
| 2 |
| |
+ 1 +
,
+------------------+
| 4 3 2 2
\|x + 2x + x + 4x + x - x
[radval= ------------------------------, radmult= 1,
2x
+ +------------------+ +
| | 4 3 2 2 |
|\|x + 2x + x + 4x + x + x|
radvect= [|------------------------------|]]
| 2 |
| |
+ 1 +
]
Type: List Record(radval: Expression Integer,radmult: Integer,radvect: List Matrix Expression Integer)
> Even better would be if Fricas was ASDF-compatible. Then loading it could
> be done by (not much nicer, but without giving a precise path)
>
> (asdf:asdf 'asdf:load-op :fricas)
>
> which would load FRICAS (if it can be found between my libraries).
> Additionally, other ASDF libraries could simply mention Fricas in their
> dependency list.
>
> Nicolas
>
> P.S.: With Maxima, version 1 is possible, and version 2 probably could be
> implemented as well rather easily (I think, by default, Maxima uses
> mk:defsystem, which is an alternative to ASDF).
Rainer Joswig <jos...@lisp.de> writes:
> Ideally one would start a Lisp, load Axiom into it, have a command line for
> it and another one for Lisp - so that one can use both. Many Lisp
> implementations are multi-threaded and allow more than one command loop at
> the same time. So one could work on mathematical algorithms on the command
> line and implement some other stuff in a Lisp command line. Both would be
> running in one Lisp system. Say, one would use the user environment of McCLIM
> (including Climacs (the editor) and the McCLIM command loops) and use Axiom
> in it - even develop some integration for Axiom into the McCLIM environment -
> so for example that Axiom results can be presented in McCLIM (graphically and
> textually).
>
> Is that possible?
I do not know, sorry.
> The other way would be that loading Axiom would give me only Axiom then (Lisp
> then is only accessible via Axiom).
This is trivial, as I indicated already. If myLispThing defuns foo taking bar
as argument, you could in axiom just say [(1) -> and (2) -> are the prompts,
leading close paren introduces a system command]
(1) -> )lisp (load "myLispThing.lisp")
(2) -> FOO(bar)$Lisp
of course, you can also drop completely into lisp
(1) -> )fin
* (+ 1 1)
2
* (|spad|)
(1) ->
Martin
Rainer Joswig
Martin Rubey <axio...@yahoo.de> wrote:
> Rainer Joswig <jos...@lisp.de> writes:
>
> > Ideally one would start a Lisp, load Axiom into it, have a command line for
> > it and another one for Lisp - so that one can use both. Many Lisp
> > implementations are multi-threaded and allow more than one command loop at
> > the same time. So one could work on mathematical algorithms on the command
> > line and implement some other stuff in a Lisp command line. Both would be
> > running in one Lisp system. Say, one would use the user environment of McCLIM
> > (including Climacs (the editor) and the McCLIM command loops) and use Axiom
> > in it - even develop some integration for Axiom into the McCLIM environment -
> > so for example that Axiom results can be presented in McCLIM (graphically and
> > textually).
> >
> > Is that possible?
>
> I do not know, sorry.
That's where the fun would be. ;-)
>
> > The other way would be that loading Axiom would give me only Axiom then (Lisp
> > then is only accessible via Axiom).
>
> This is trivial, as I indicated already. If myLispThing defuns foo taking bar
> as argument, you could in axiom just say [(1) -> and (2) -> are the prompts,
> leading close paren introduces a system command]
>
> (1) -> )lisp (load "myLispThing.lisp")
>
> (2) -> FOO(bar)$Lisp
>
> of course, you can also drop completely into lisp
>
> (1) -> )fin
>
> * (+ 1 1)
>
> 2
> * (|spad|)
>
> (1) ->
While you are at answering questions ;-) :
a) what about a break into the Lisp debugger? Is there a command for that?
b) Is there a debugger for the Axiom language (s)?
>
>
>
> Martin
Raymond Toy (RT/EUS)
Nicolas> P.S.: With Maxima, version 1 is possible, and version 2 probably could be
Nicolas> implemented as well rather easily (I think, by default, Maxima uses
Nicolas> mk:defsystem, which is an alternative to ASDF).
Not sure what you mean by version 1 and version 2, but yes, Maxima
uses mk:defsystem (asdf didn't exist then), and I've used it to load
up the core of maxima in other applications. Works just fine.
Ray
Martin Rubey
> While you are at answering questions ;-) :
>
> a) what about a break into the Lisp debugger? Is there a command for that?
Yes. In fact
(1) -> )set break break
gives you the lisp debugger on every error (even if you hit Ctrl-c). That
functionality is easy to customize, meanwhile, too.
> b) Is there a debugger for the Axiom language (s)?
Well, you can trace functions, grouped by "domain", but you cannot "step".
Find an example below. There is also a profiler, which is *extremely* useful
in computer algebra, I must say.
Martin
(1) -> )tr IntegrationTools )ma
Parameterized constructors traced:
INTTOOLS
(1) -> )tr INTEF )ma
Parameterized constructors traced:
INTTOOLS, INTEF
(1) -> integrate(1/sqrt(1-x^2), x)
1<enter IntegrationTools.varselect,18 :
+--------+
| 2
arg1= [x,\|- x + 1 ]
arg2= x
1>exit IntegrationTools.varselect,18 :
+--------+
| 2
[x,\|- x + 1 ]
1<enter ElementaryIntegration.lfintegrate,58 :
1
arg1= -----------
+--------+
| 2
\|- x + 1
arg2= x
1<enter IntegrationTools.intPatternMatch,100 :
1
arg1= -----------
+--------+
| 2
\|- x + 1
arg2= x
arg3= theMap(INTEF;lfintegrate0,303)
arg4= theMap(newGoGet)
1<enter IntegrationTools.varselect,18 :
+--------+
| 2
arg1= [\|- x + 1 ]
arg2= x
1>exit IntegrationTools.varselect,18 :
+--------+
| 2
[\|- x + 1 ]
1<enter IntegrationTools.kmax,24 :
+--------+
| 2
arg1= [\|- x + 1 ]
1>exit IntegrationTools.kmax,24 :
+--------+
| 2
\|- x + 1
1<enter IntegrationTools.ksec,25 :
+--------+
| 2
arg1= \|- x + 1
+--------+
| 2
arg2= [\|- x + 1 ]
arg3= x
1<enter IntegrationTools.vark,23 :
2
arg1= [- x + 1,2]
arg2= x
1<enter IntegrationTools.varselect,18 :
arg1= [x]
arg2= x
1>exit IntegrationTools.varselect,18 :
[x]
1>exit IntegrationTools.vark,23 :
[x]
1<enter IntegrationTools.kmax,24 :
arg1= [x]
1>exit IntegrationTools.kmax,24 :
x
1>exit IntegrationTools.ksec,25 :
x
1>exit IntegrationTools.intPatternMatch,100 :
+--------+
| 2
--+ \|- x + 1 - 1
> %B log(- %B + ---------------)
--+ x
2
%B + 1= 0
1>exit ElementaryIntegration.lfintegrate,58 :
+--------+
| 2
--+ \|- x + 1 - 1
> %B log(- %B + ---------------)
--+ x
2
%B + 1= 0
1<enter IntegrationTools.mkPrim,76 :
+--------+
| 2
\|- x + 1 - 1
arg1= - 2atan(---------------)
x
arg2= x
1>exit IntegrationTools.mkPrim,76 :
+--------+
| 2
\|- x + 1 - 1
- 2atan(---------------)
x
1<enter IntegrationTools.removeConstantTerm,51 :
+--------+
| 2
\|- x + 1 - 1
arg1= - 2atan(---------------)
x
arg2= x
1>exit IntegrationTools.removeConstantTerm,51 :
+--------+
| 2
\|- x + 1 - 1
- 2atan(---------------)
x
+--------+
| 2
\|- x + 1 - 1
(1) - 2atan(---------------)
x
Type: Union(Expression Integer,...)
(2) ->
Nicolas Neuss
> Not sure what you mean by version 1 and version 2, but yes, Maxima
> uses mk:defsystem (asdf didn't exist then), and I've used it to load
> up the core of maxima in other applications. Works just fine.
Version 1 was meant loading the startup file (which is
"maxima/src/maxima-build.lisp", BTW) which works fine for me. I'm sure
sure that calling mk:defsystem would work too, but the above startup file
loads also "defsystem.lisp" which is an advantage for me. It would be nice
if an ASDF system definition would be available as well, because ASDF is
simply more frequently used nowadays (sometimes even delivered with the CL
implementation, e.g. with SBCL and Allegro).
Nicolas
Nicolas Neuss
> raymo...@ericsson.com (Raymond Toy (RT/EUS)) writes:
>
>> Not sure what you mean by version 1 and version 2, but yes, Maxima
>> uses mk:defsystem (asdf didn't exist then), and I've used it to load
>> up the core of maxima in other applications. Works just fine.
>
> Version 1 was meant loading the startup file (which is
> "maxima/src/maxima-build.lisp", BTW) which works fine for me.
Sorry, I got that wrong. What I am really using for loading Maxima is
(setq *default-pathname-defaults* (pathname "/home/neuss/CL-HOME/maxima/src/"))
(load "../configure.lisp")
(load "maxima-build.lisp")
(maxima-load)
Nicolas
Waldek Hebisch
> Martin Rubey <axio...@yahoo.de> writes:
>
> > Nicolas Neuss <last...@math.uni-karlsruhe.de> writes:
> >
> >> What I would prefer is to load FRICAS as an add-on library with asdf. Is
> >> this possible, or are there any plans to support this?
> >
> > To be honest, I do not even know what this would mean. But I'll forward this
> > to the mailing list.
> >
> > Just for clarification: what would you like to be able to do?
>
> I want to work in Common Lisp but have access to CAS functionality. I
> might need this, for example, in computing quadrature rules to high
> accuracy in my PDE solver Femlisp, or for posing and solving symbolic math
> exercises for students.
>
> From within Common Lisp, I want to do something like
> (load "fricas/start.lisp")
> and after this command I want to have the FRICAS functionality available,
> e.g. for commands like
>
> (fricas:eigenvectors (fricas:read-matrix-from-string "[x,1;1/x,-1]"))
>
> (sorry, I do not really know Fricas/Axiom, so I used Matlab matrix
> notation).
>
If you have build tree in place it is possible to write quick and dirty
load so that
(load "load-fricas.lisp")
load FriCAS. Then one can do:
BOOT[3]> (in-package "BOOT")
BOOT[4]> (|parseAndInterpret| "x^2")
2
(2) x
Type: Polynomial Integer
((Polynomial (Integer)) WRAPPED 1 x (2 0 . 1))
BOOT[5]> (defvar *mult-i-sup*
(|getFunctionFromDomain| '* '(|SparseUnivariatePolynomial| (|Integer|)) '((|SparseUnivariatePolynomial| (|Integer|)) (|SparseUnivariatePolynomial| (|Integer|)))))
*MULT-I-SUP*
BOOT[6]> (SPADCALL '((2 . 1) (0 . 1)) '((5 . 1) (0 . 1)) *mult-i-sup*)
((7 . 1) (5 . 1) (2 . 1) (0 . 1))
BOOT[7]>
Notes:
- all intersting functionality is in package called "BOOT".
- at mathematical level FriCAS is case-sensitive, so at Lisp level one
has to use bars.
- the simplest interface is |parseAndInterpret| which takes a string
as input and produces a Lisp form repesenting printed output. As
side effect |parseAndInterpret| prints the result.
- at deeper lever FriCAS functions are overloaded, so to call correct
function one has to first use |getFunctionFromDomain| to get
function which matches to given argument types. Above I want to
multiply two sparse univarate polynomials with integer coefficients.
Since lookup may be expensive the caller is adviced to cache result
of the lookup.
- FriCAS functions use special calling convention, so one has to use
SPADCALL macro to call them. Actually, |getFunctionFromDomain|
returns a pair consistion of a function and an extra argument.
SPADCALL takes care of decomposing the pair and appending the
extra argument to the argument list.
With moderate effort it would be possible to include something like
"load-fricas.lisp" in the standard FriCAS distribution.
> Even better would be if Fricas was ASDF-compatible. Then loading it could
> be done by (not much nicer, but without giving a precise path)
>
> (asdf:asdf 'asdf:load-op :fricas)
>
> which would load FRICAS (if it can be found between my libraries).
> Additionally, other ASDF libraries could simply mention Fricas in their
> dependency list.
>
There are no plans to use ASDF for building FriCAS. It should not be
hard to hook something like "load-fricas.lisp" into ASDF. But I am
not sure how much ASDF-compatible implies...
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Pedro Valero
Stat".
I believe that some of the other papers might be of interest too for
those reading this discussion. I would recommend Sandford's,
Balasubramanian's, and, of course, Tierney's.
Pedro
Dr. Pedro M. Valero Mora (val...@uv.es)
Facultad de Psicología
Universitat de Valencia
Tlf. (34) 96 3983564 (Interno: 83564)
Mob. 651120788
http://www.uv.es/valerop
SINTEC-INTRAS
Driving Simulation and Human Factors of New Technologies in the
Vehicle
Institute of Traffic and Road Safety
http://www.uv.es/sintec
METHODOLOGY OF BEHAVIOURAL SCIENCES
Data Visualization and Computational Statistics
http://www.uv.es/visualstats/Book/
http://www.uv.es/prodat
CHECK THE VISUAL STATISTICS BOOK!
http://www.uv.es/visualstats/Book/
Nicolas Neuss
> With moderate effort it would be possible to include something like
> "load-fricas.lisp" in the standard FriCAS distribution.
Thanks for your detailed explanation. Such a file "load-fricas.lisp" would
be useful for me.
>> Even better would be if Fricas was ASDF-compatible. Then loading it could
>> be done by (not much nicer, but without giving a precise path)
>>
>> (asdf:asdf 'asdf:load-op :fricas)
>>
>> which would load FRICAS (if it can be found between my libraries).
>> Additionally, other ASDF libraries could simply mention Fricas in their
>> dependency list.
>>
> There are no plans to use ASDF for building FriCAS. It should not be
> hard to hook something like "load-fricas.lisp" into ASDF. But I am
> not sure how much ASDF-compatible implies...
For my uses, that should be sufficient. In fact, this is what I have done
with my commands that load Maxima.
Thanks again,
Nicolas
jboe...@gmail.com
http://repo.or.cz/w/CommonLispStat.git
From the project description:
"This is an update of the original alpha-level port for Common
LispStat by Luke Tierney. It makes an amusing hobby. This is the
"true to the original idea" version, not my working copy which had
some modernisms which I'd like to rewind on. This version probably
doesn't work (but it might compile)."
The last update was 1/2/2008
--Joel
Pedro Valero
The person doing this is Toni Rossini.
Pedro
AJ Rossini
Note that I'm also running on repo.or.cz, updates/patches from the
last copy of the XLispStat repository that I had access to around
2000-2001, since I need that for validation/verification purposes
(there is one small goal of having backwards compatibility if possible
-- clearly not completely possible, XLisp and the LispStat extensions
to it were ahead of there time -- R has only very recently met some of
the capabilities.
For XLispStat, my goal is to clean up the directory structure and use
it for validation purposes (along with R) for CommonLisp Stat.
Patches, criticisms, etc welcome. I'm not reading comp.lang.lisp
religiously (nor #lisp) but hope to again in March.
For CommonLisp Stat, my primary goal is a set of coordinated packages
that can be mixed and matched to get customized statistical processing
systems. I'm still working on the design of that approach, and the
code is very much a work in progress.
Waldek Hebisch
> Waldek Hebisch <heb...@math.uni.wroc.pl> writes:
>
> > With moderate effort it would be possible to include something like
> > "load-fricas.lisp" in the standard FriCAS distribution.
>
> Thanks for your detailed explanation. Such a file "load-fricas.lisp" would
> be useful for me.
>
With current FriCAS (SVN revision 213) it is just:
(let ((*default-pathname-defaults*
#P"/var/tmp/hebisch/axp2/ax-build4/src/interp/"))
(load "../lisp/fricas-package.lisp")
(load "../lisp/fricas-lisp")
(load "makeint.lisp"))
(in-package "BOOT")
(fricas-init)
Of course, you need to plug in the correct path to the build tree.
Also, the above works with sbcl, clisp and Closure CL. Ecl and
gcl do things differently and would require special support.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Rainer Joswig
Waldek Hebisch <heb...@math.uni.wroc.pl> wrote:
> Nicolas Neuss <last...@math.uni-karlsruhe.de> wrote:
> > Waldek Hebisch <heb...@math.uni.wroc.pl> writes:
> >
> > > With moderate effort it would be possible to include something like
> > > "load-fricas.lisp" in the standard FriCAS distribution.
> >
> > Thanks for your detailed explanation. Such a file "load-fricas.lisp" would
> > be useful for me.
> >
>
> With current FriCAS (SVN revision 213) it is just:
>
> (let ((*default-pathname-defaults*
> #P"/var/tmp/hebisch/axp2/ax-build4/src/interp/"))
> (load "../lisp/fricas-package.lisp")
> (load "../lisp/fricas-lisp")
> (load "makeint.lisp"))
> (in-package "BOOT")
> (fricas-init)
I would usually write a function to create such a pathname.
I'm not sure if ../foo.lisp is in Common Lisp.
(defun pathname-up (base file)
(let ((base (pathname base))
(file (pathname file)))
(make-pathname :defaults base
:directory (append (butlast (pathname-directory base))
(rest (pathname-directory file)))
:name (pathname-name file)
:type (pathname-type file))))
Also note that the variable *load-pathname* is bound
to the file that is loaded. So, if you have a start
file, you can load it and get the necessary
pathname constructed. So you don't need to hardcode the
path into the load file.
(load (pathname-up *load-pathname* "lisp/fricas-package.lisp"))
I also usually want to make sure that it works with
logical pathnames like:
(load "fricas:lisp;fricas-package.lisp")
In file /tmp/p.lisp :
(setf (logical-pathname-translations "FRICAS")
`(("fricas:**;*.*" ,(make-pathname :defaults *load-pathname*
:directory (append (pathname-directory *load-pathname*)
(list :wild-inferiors))
:name :wild
:type :wild))))
CL-USER> (load "/tmp/p.lisp")
T
CL-USER> (pathname "fricas:src;algebra;ring.lisp")
#P"FRICAS:SRC;ALGEBRA;RING.LISP"
CL-USER> (translate-logical-pathname *)
#P"/tmp/src/algebra/ring.lisp"
One sets the logical pathname translations once,
(it is also possible to create them with the load
file) and then it doesn't matter where the files
are anymore. This is for example useful when you
compile a Lisp program and the Lisp compiler
records the source locations. It is preferable to
compile using a logical pathname then. The compiler
will record the logical pathnames of the source
file for each Lisp construct. Later, if you move
a compiled system plus source code, to
some other place (machine) - you just have to adjust the logical
pathname and the Lisp system will still find the source
code for all the Lisp constructs - usually one
types M-. on a symbol and you can edit it. Also
(ed 'my-function) will find the source for my function
and open an editor in any more useful Lisp environment.