why lisp is better than python
rjf
wrote about automatic differentiation of algorithms. (Yes, this makes
sense; no, it's not the same as symbolic differentiation).
see http://www.cs.berkeley.edu/~fateman/papers/adil.pdf
for my paper
and for background, see www.autodiff.org
Here's where Lisp works better than Python, I think.
You can more easily write a program in Lisp that transforms a program
(in Lisp) into another program (in Lisp).
compare that to writing a program in Python that transforms a program
(in Python) into another program (in Python).
The program dcomp in my paper converts the body of a program f
(x):= ....
into a program g(x) that computes the derivative of f evaluatuated at
x.
(there are some constraints, explained in the paper.)
I think this comparison has much more meat than arguments about
indentation vs parentheses
and somewhat more meat than
who needs macros
or
who needs a compiler.
(Lisp has macros, which are used here, and Lisps usually have
compilers,
which are optionally used here too.)
Tom Boothby
program into another program. In fact, the transformation is
guaranteed to take O(1) time, and the resulting program provably
terminates in O(1) time.
def transform(f):
def foo():
print "done!"
return foo
Tom Boothby
Ok, so you can do program differentiation. What's it good for? I
know that functional programming is said to be easier to prove
termination, but harder to prove runtime -- I get the feeling that
this is just one of those differences. There's tradeoffs we make.
Like, most lisp looks like line noise to novices, but Python is
typically quite easy to read. Perl is crazy powerful... but
frequently makes lisp look like a large-print copy of a Dr. Seuss
book.
Robert Bradshaw
> Going through some old papers and updating them, I came across one I
> wrote about automatic differentiation of algorithms. (Yes, this makes
> sense; no, it's not the same as symbolic differentiation).
>
> see http://www.cs.berkeley.edu/~fateman/papers/adil.pdf
> for my paper
>
> and for background, see www.autodiff.org
>
> Here's where Lisp works better than Python, I think.
> You can more easily write a program in Lisp that transforms a program
> (in Lisp) into another program (in Lisp).
>
> compare that to writing a program in Python that transforms a program
> (in Python) into another program (in Python).
Yep, no doubt about it. I remember one of the first programs I wrote
in Lisp was a (limited) Lisp interpreter, and that was much easier
than writing a Python interpreter would have been using Python.
Macros, and the general low barrier between data and code, make Lisp
a very powerful language.
However, I think one of the main (non-social) advantages that Python
has over Lisp is readability, especially for novices. (The antithesis
of this is C++ template meta-programming; it makes the language much
more powerful, but can sure make it hard to figure out what any given
line is actually doing...)
- Robert
rjf
On Sep 4, 4:15 pm, Tom Boothby <tomas.boot...@gmail.com> wrote:
> on a more serious note...
>
> Ok, so you can do program differentiation. What's it good for?
it
is of substantial interest. And I don't mean of interest to pure
mathematicians.
> I
> know that functional programming is said to be easier to prove
> termination, but harder to prove runtime -- I get the feeling that
> this is just one of those differences.
functional programming, it does not require that you use this model.
The autodiff programs have nothing much to do with proofs of
termination.
> There's tradeoffs we make.
> Like, most lisp looks like line noise to novices, but Python is
> typically quite easy to read.
kind of shallow evaluation that says oh dear, too many parentheses!!!
Oh Python. I have such trouble lining up indentations. Who would have
guessed that it mattered so much??
> Perl is crazy powerful... but
> frequently makes lisp look like a large-print copy of a Dr. Seuss
> book.
The programming language that I think looks most like line-noise is
TECO, a text editor which was the original host for EMACS.
If you don't like the way Lisp looks, you can find any number of
languages L that have translators from L into Lisp. However, most
serious programmers find Lisp to be more than adequate.
>
Actually, if you looked at the material you might realize that the
point
of the message is really that the model of a Lisp program looks like
Lisp data.
The list (+ 2 2) can be used as a program. the program (+ 2 2) can
be
viewed as a list.
The Python program segment 2+2 can be viewed as parsed data, but it
is a lot more complicated.
>>> parse("2 + 2")
['eval_input', ['testlist', ['test', ['and_test', ['not_test',
['comparison',
['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr',
['term',
['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term',
['factor',
['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']]
So you are not as likely to start with this and modify it to make
another
python program.
The example above comes from..
http://norvig.com/python-lisp.html
In fact, the best way to do autodiff in Python is to find another
parser
for Python, one that converts Python into Lisp-like data. Transform
this
data into a Lisp program, and then convert that back to a Python
program.
I think that is pretty much what all the autodiff programs do, except
instead of
using Python, they use C or Fortran.
In the middle of most compilers for python-like languages you will
probably find
an intermediate level of representation which is a tree, represented
most
easily in list form. Apparently this is the case for the output of
the Python
parser, assuming that the example by Norvig still is valid.
Just the parser output left all the grammar non-terminals in the
tree. Like
factor, term, power, ...
Clumsy.
Harald Schilly
On Sep 5, 7:14 am, rjf <fate...@gmail.com> wrote:
> Norvig
Here a talk explaining why he "ended up with python"
http://www.archive.org/details/scipy09_day1_03-Peter_Norvig
cute examples in pure python (using no library at all) in a functional
programming style
> macros
i personally hate them [talking mainly about C++, but it's similar in
lisp] , since i don't know what the actual line/command i'm in does.
i'm even not a fan of operator overloading, but i understand that it
is somewhat ok in python and useful, since it is limited and clearly
defined in it's scope. for me, macros are just a sign of a design
deficit that is compensated by a mechanism. everytime i read
"powerful" in that context i understand "confusing" ... and for me
it's not cool to solve funny riddles all the time i find an error
associated with macros.
and about the opening statement, wasn't the design principle of lisp
by mcCarthy to translate mathematical notations to a list processing
language? therefore it's no surprise that your AD code looks nice,
since the language is designed that way. but not everything boils down
to mathematical notations while being nice to read, easy to comprehend
and friendly to new coders.
h
rjf
On Sep 5, 2:33 am, Harald Schilly <harald.schi...@gmail.com> wrote:
> On Sep 5, 7:14 am, rjf <fate...@gmail.com> wrote:
>
> > Norvig
>
> Here a talk explaining why he "ended up with python"http://www.archive.org/details/scipy09_day1_03-Peter_Norvig
> cute examples in pure python (using no library at all) in a functional
> programming style
arguments with respect to lisp vs python (most of which are in
the article I linked to)
> > macros
>
> i personally hate them [talking mainly about C++, but it's similar in
> lisp] , since i don't know what the actual line/command i'm in does.
into, you
can explicitly macroexpand it and see.
I find, when I use macros, (which is not that often), I macroexpand
them to look at
the results quite frequently when debugging.
> i'm even not a fan of operator overloading, but i understand that it
> is somewhat ok in python and useful, since it is limited and clearly
> defined in it's scope. for me, macros are just a sign of a design
> deficit that is compensated by a mechanism. everytime i read
> "powerful" in that context i understand "confusing" ... and for me
> it's not cool to solve funny riddles all the time i find an error
> associated with macros.
just not hard enough to justify your learning enough about programming
languages to use so-called "powerful" techniques. Extensive use of
macros in writing a sort program would probably be a waste of time
(though I could see writing macros for data-field access and
overloading
">" perhaps).
The point you are making seems to me like the pilot of a Piper Cub
saying,
"radar, shmadar, who needs this crap?"
> and about the opening statement, wasn't the design principle of lisp
> by mcCarthy to translate mathematical notations to a list processing
> language? therefore it's no surprise that your AD code looks nice,
> since the language is designed that way. but not everything boils down
> to mathematical notations while being nice to read, easy to comprehend
> and friendly to new coders.
representation where
it is possible to manipulate it easily?
So you take a language which was designed and applied successfully to
that task
and dismiss it by saying it is "unfriendly to new coders." I do not
expect that writing
a compiler for automatic differentiation will be easy for new coders,
but it is a lot easier in Lisp than in most other languages. In fact,
the first programming
project for one of my graduate students was an automatic
differentiation compiler
(the "reverse" version, not in my paper).
In my teaching of large courses at Berkeley (say 500 students), I find
a dramatic
difference in quality of programmers. First of all, note that almost
any of the
students in the class are OK, and at least 400 would be considered
good hires
for a commercial programming job. But out of the 500, there will be 5
or maybe 10
who are so outstanding that they do the assignments essentially at
first glance,
correctly and beautifully. Sometimes improving on the solutions I had
expected.
They are probably 50X more productive than the other students. That is
why
I am not so keen on attracting large numbers of mediocre workers.
Even with
the best languages, their programs tend to be buggy, fragile,
inefficient, and
in need of rewriting (by me, perhaps) before serious use.
If a student cannot learn Lisp, (or has had trouble in the intro
course that uses it)
that's a clear sign that this student is not for me.
>
R
William Stein
>
>
>
> On Sep 5, 2:33 am, Harald Schilly <harald.schi...@gmail.com> wrote:
>> On Sep 5, 7:14 am, rjf <fate...@gmail.com> wrote:
>>
>> > Norvig
>>
>> Here a talk explaining why he "ended up with python"http://www.archive.org/details/scipy09_day1_03-Peter_Norvig
>> cute examples in pure python (using no library at all) in a functional
>> programming style
>
You should -- it's a pretty relevant video!
> They are probably 50X more productive than the other students. That is
> why
> I am not so keen on attracting large numbers of mediocre workers.
> Even with
> the best languages, their programs tend to be buggy, fragile,
> inefficient, and
> in need of rewriting (by me, perhaps) before serious use.
>
> If a student cannot learn Lisp, (or has had trouble in the intro
> course that uses it)
> that's a clear sign that this student is not for me.
In the video Ondrej posted, Peter Norvig begins by saying "we started
getting complaints from students [about them not understanding lisp].
'I can understand the pseudocode, but I do not understand the Lisp
code.' I thought: 'You can't fight reality, if they say they don't
get it, then they don't get it and you have to change.'
It looks like that is relevant lesson.
-- William
rjf
On Sep 5, 8:26 am, William Stein <wst...@gmail.com> wrote:
where Norvig talks
about Lisp vs Python.
It makes sense if you are selling a textbook and want it to be sold to
as
many people as possible.
I expect that you realize that half the people in any group are -- um
-- below average. While I have not taught an undergraduate course in
artificial intelligence, I have on good authority that when half of
the students are engineers/math/compsci and the other half are
"cognitive science" you have a fairly clear distribution. The cogsci
students are generally, how shall we say, below the line. (Math
students are, I think, highly variable.)
As Norvig says in the video, the Lisp corresponded to the pseudo code.
And people who understood lisp probably understood that
correspondence, since it was mostly 1:1.
For people who said "I understand the pseudocode but not the Lisp" ..
do you really think they gained anything by seeing Python?
I doubt that they really understood the pseudocode so well, either.
OK, so much for the video........................
So why not use Python, anyway, even if you are smart? Isn't it just as
good as Lisp?
(First, let me say that Python standard libraries make it more useful
than "portable ANSI Standard Lisp" for OS interfaces etc. because
those kinds of things are not ANSI standard. Although there is some
"extra" commonality, each vendor or FOSS implementation has its own
way of doing things. This is a disadvantage of Lisp hard to overcome
unless you sacrifice something.
What I sacrifice is: I write programs that are OS dependent on one
computer (my own) on one Lisp.)
So assuming you are doing something that is not dependent on external
stuff. Like symbolic integration, or building a geometric reasoning
system for storing assumptions. Or automatic differentiation of
algorithms. Why not write it in Python?
Writing in Python may not make sense if you are writing an ambitious
program, and are concerned about doing it in the most effective way,
and helping smart people obtain the greatest leverage via choice of
programming language.
The automatic differentiation program example I gave is reasonably
ambitious and very easy to write in Lisp.
Short, and (if you know Lisp) easy to read.
My guess is that it would be quite hard to write in Python; the
easiest way, as I've said, would be to translate the Python to
Lisp data, and do the job there. Then translate back to Python.
..............
Asking for popular opinion is not always the route to truth.
Among North Carolina Republican voters,
Only 54% of voters say they believe Obama was born in the US, while
26% think he was not and 20% are unsure.
http://www.publicpolicypolling.com/pdf/PPP_Release_NC_811424.pdf
(How many North Carolina Republicans think that Python is better than
Lisp for writing symbolic math programs?)
> -- William
William Stein
So would you agree that the same argument makes sense if you are
creating a mathematics software system for which you want
contributions from as many people as possible?
> I expect that you realize that half the people in any group are -- um
> -- below average. While I have not taught an undergraduate course in
> artificial intelligence, I have on good authority that when half of
> the students are engineers/math/compsci and the other half are
> "cognitive science" you have a fairly clear distribution. The cogsci
> students are generally, how shall we say, below the line. (Math
> students are, I think, highly variable.)
I like them too.
> As Norvig says in the video, the Lisp corresponded to the pseudo code.
>
> And people who understood lisp probably understood that
> correspondence, since it was mostly 1:1.
>
> For people who said "I understand the pseudocode but not the Lisp" ..
> do you really think they gained anything by seeing Python?
I'm sure they gained by being able to read, modifying, and work with
the code (which they do with Python), instead of being frustrated by
having to constantly switch back and forth between two different
representations of the same idea (which they are forced to do by using
Lisp).
> I doubt that they really understood the pseudocode so well, either.
>
> OK, so much for the video........................
>
>
> So why not use Python, anyway, even if you are smart? Isn't it just as
> good as Lisp?
> (First, let me say that Python standard libraries make it more useful
> than "portable ANSI Standard Lisp" for OS interfaces etc. because
> those kinds of things are not ANSI standard. Although there is some
> "extra" commonality, each vendor or FOSS implementation has its own
> way of doing things. This is a disadvantage of Lisp hard to overcome
> unless you sacrifice something.
> What I sacrifice is: I write programs that are OS dependent on one
> computer (my own) on one Lisp.)
So you sacrifice the ability to write programs that other people can
use? That sounds like the ultimate sacrifice to me.
> So assuming you are doing something that is not dependent on external
> stuff. Like symbolic integration, or building a geometric reasoning
> system for storing assumptions.
There's a dangerous assumption above. Just because it's possible to
implement an algorithm without using "external stuff" doesn't mean
that is a good way to do it. Indeed, Sage's symbolic integration
*does* use the "external stuff" that's called "Maxima".
> Or automatic differentiation of algorithms. Why not write it in Python?
>
> Writing in Python may not make sense if you are writing an ambitious
> program, and are concerned about doing it in the most effective way,
> and helping smart people obtain the greatest leverage via choice of
> programming language.
To use the phrase "the most effective way" with respect to any
nontrivial program is naive at best.
And, dividing people up between smart and dumb based on whether they
get lisp or not isn't something I would be proud of doing.
> The automatic differentiation program example I gave is reasonably
> ambitious and very easy to write in Lisp.
> Short, and (if you know Lisp) easy to read.
>
> My guess is that it would be quite hard to write in Python; the
> easiest way, as I've said, would be to translate the Python to
> Lisp data, and do the job there. Then translate back to Python.
I will refrain from further guessing about how hard it would be to
implement something that solves a vague formulation of a problem that
nobody cares about, and just remark (following
http://www.nabble.com/Automatic-differentiation-%28was-Re:-second-order-gradient%29-td20249006.html)
that there are several possibilities, some of them are listed on
http://en.wikipedia.org/wiki/Automatic_differentiation
== pycppad
http://www.seanet.com/~bradbell/pycppad/index.xml
pycppad is a wrapper of the C++ library CppAD ( http://www.coin-or.org/CppAD/ )
the wrapper can do up to second order derivatives very efficiently in
the so-called reverse mode of AD
requires boost::python
== pyadolc
http://github.com/b45ch1/pyadolc
which is a wrapper for the C++ library ADOL-C (
http://www.math.tu-dresden.de/~adol-c/ )
this can do abritrary degree of derivatives and works quite well with
numpy, i.e. you can work with numpy arrays
also quite efficient in the so-called reverse mode of AD
requires boost::python
== ScientificPython
http://dirac.cnrs-orleans.fr/ScientificPython/ScientificPythonManual/
can provide first order derivatives. But as far as I understand only
first order derivatives of functions
f: R -> R
and only in the usually not so efficient forward mode of AD
pure python
== Algopy
http://github.com/b45ch1/algopy/tree/master
pure python, arbitrary derivatives in forward and reverse mode
still quite experimental.
Offers also the possibility to differentiate functions that make heavy
use of matrix operations.
> Asking for popular opinion is not always the route to truth.
And ignoring popular opinion is a sure route to creating software that
nobody cares about.
William
Robert Bradshaw
> On Sep 5, 2:33 am, Harald Schilly <harald.schi...@gmail.com> wrote:
>> On Sep 5, 7:14 am, rjf <fate...@gmail.com> wrote:
>>
>>> Norvig
>>
>> Here a talk explaining why he "ended up with python"http://
>> www.archive.org/details/scipy09_day1_03-Peter_Norvig
>> cute examples in pure python (using no library at all) in a
>> functional
>> programming style
>
> I haven't looked at this video, but I am familiar with Norvig's
> arguments with respect to lisp vs python (most of which are in
> the article I linked to)
>>
>>> macros
>>
>> i personally hate them [talking mainly about C++, but it's similar in
>> lisp] , since i don't know what the actual line/command i'm in does.
>
> In Lisp, at least, if you have any question about what a macro expands
> into, you can explicitly macroexpand it and see.
>
> I find, when I use macros, (which is not that often), I macroexpand
> them to look at the results quite frequently when debugging.
You can do that with, e.g., gcc -E
However (responding to Harald), C/C++ macros are basically just
string mangling and replacement, without any real understanding of
the code. Lisp macros operate on the code structure itself, which
make them, in my opinion, both cleaner and more powerful.
- Robert
Ondrej Certik
Great you setup this list William, it's nice to be able to discuss these things.
Rjf --- I don't understand one thing --- I noticed in several of your
emails, that you don't value students who are "below average", e.g.
that they are not for you. Why is that?
I believe that every student can do useful work. And in fact, judging
by grades, in many subjects, I am in the lower part of the class
myself. It's not in the grades. I think what matters is if you want to
do and then do it.
Ondrej
rjf
> > where Norvig talks
> > about Lisp vs Python.
>
> > It makes sense if you are selling a textbook and want it to be sold to
> > as
> > many people as possible.
>
> So would you agree that the same argument makes sense if you are
> creating a mathematics software system for which you want
> contributions from as many people as possible?
contribute to a piece of software, I think you will not have a very
good piece of software. I think you will find the software
engineering literature pretty consistent on this point, and I do not
think that "many eyes make all bugs shallow" is as relevant as "many
shallow eyes make bugs".
>
> > I expect that you realize that half the people in any group are -- um
> > -- below average. While I have not taught an undergraduate course in
> > artificial intelligence, I have on good authority that when half of
> > the students are engineers/math/compsci and the other half are
> > "cognitive science" you have a fairly clear distribution. The cogsci
> > students are generally, how shall we say, below the line. (Math
> > students are, I think, highly variable.)
>
> I like them too.
>
> > As Norvig says in the video, the Lisp corresponded to the pseudo code.
>
> > And people who understood lisp probably understood that
> > correspondence, since it was mostly 1:1.
>
> > For people who said "I understand the pseudocode but not the Lisp" ..
> > do you really think they gained anything by seeing Python?
>
> I'm sure they gained by being able to read, modifying, and work with
> the code (which they do with Python), instead of being frustrated by
> having to constantly switch back and forth between two different
> representations of the same idea (which they are forced to do by using
> Lisp).
thought
they understood both.
>l
> > (RJF) So assuming you are doing something that is not dependent on external
> > system for storing assumptions.
>
> There's a dangerous assumption above. Just because it's possible to
> implement an algorithm without using "external stuff" doesn't mean
> that is a good way to do it. Indeed, Sage's symbolic integration
> *does* use the "external stuff" that's called "Maxima".
Python code.
Also, your tools (in Python? Pexpect?) seem to have been a real
problem.
So here is a case where Python is crappy, anyway.
>
> > Or automatic differentiation of algorithms. Why not write it in Python?
>
> > Writing in Python may not make sense if you are writing an ambitious
> > program, and are concerned about doing it in the most effective way,
> > and helping smart people obtain the greatest leverage via choice of
> > programming language.
>
> To use the phrase "the most effective way" with respect to any
> nontrivial program is naive at best.
>
> And, dividing people up between smart and dumb based on whether they
> get lisp or not isn't something I would be proud of doing.
smart.
Occasionally I take a chance with students who have (relatively) poor
grades
who seem to have a creative streak. I may miss some promising
students
who only SEEM dumb but are really smart. I definitely take on some
students
who seem smart but are really lacking something (like initiative or
creativity).
Even with good students I find that the programs they write are often
not
useful as written, and I end up rewriting or just discarding their
work.
There is hardly enough time for dumb students, and there are enough
smart ones,
usually.
>
> > The automatic differentiation program example I gave is reasonably
> > ambitious and very easy to write in Lisp.
> > Short, and (if you know Lisp) easy to read.
>
> > My guess is that it would be quite hard to write in Python; the
> > easiest way, as I've said, would be to translate the Python to
> > Lisp data, and do the job there. Then translate back to Python.
>
> I will refrain from further guessing about how hard it would be to
> implement something that solves a vague formulation of a problem that
> nobody cares about,
people,
people even using python.
But the majority of users of AD are not using python.
I suspect that one or more of the projects is merely a front end using
python which
allows people to run AD on C++ programs.
And the question remains, assuming the algorithm to be automatically
differentiated is in Python how much of their programming effort was
devoted
to overcoming this choice of language?
Actually, you might be something of an expert on things that nobody
cares about. Judging from your CV.
< snip.. references to software that, on first glance, looks very
elaborate to install and run, and seems quite bulky>
rations.
>
> > (RJF) Asking for popular opinion is not always the route to truth.
> And ignoring popular opinion is a sure route to creating software that
> nobody cares about.
people contribute to
and writing software that many people want to use. One does not
follow from the other.
The first version of Mathematica was written by something like 5-7
people.
RJF
rjf
On Sep 5, 10:52 am, Ondrej Certik <ond...@certik.cz> wrote:
> Great you setup this list William, it's nice to be able to discuss these things.
>
> Rjf --- I don't understand one thing --- I noticed in several of your
> emails, that you don't value students who are "below average", e.g.
> that they are not for you. Why is that?
projects.
I have, say 30 applicants. I try to pick the best ones. Now some
of these students have also applied for positions with
other faculty, so I might not get the ones I think are the very best.
But there is not much motivation for me to pick someone who is below
average. My experience is that even the apparently good ones cannot be
relied upon.
(Wolfram, by the way, at one point said that he could hire the best
people at WRI, and that this was a far better way of getting things
done than via graduate students.)
>
> I believe that every student can do useful work. And in fact, judging
> by grades, in many subjects, I am in the lower part of the class
> myself. It's not in the grades. I think what matters is if you want to
> do and then do it.
something
about the subject, perhaps by taking courses. (b) You appear to be
capable
of working on a project -- you are smart enough, you have time to work
on the
project, you can work with others.
I suppose that if you only have poorly educated, dumb students, then
you have to use them.
My assumption is that Sage contributions are not uniformly distributed
across all "interested" people.
I assume that a few of people make substantial contributions, (perhaps
in separate projects),
and that most people -- in spite of their love of Python -- are
unlikely to do much of anything useful
anytime soon.
RJF
William Stein
> On Sep 5, 10:34 am, William Stein <wst...@gmail.com> wrote:
> o library at all) in a functional
>
>>
>> > Actually I disagree. I looked at the first few minutes of the talk,
>> > where Norvig talks
>> > about Lisp vs Python.
>>
>> > It makes sense if you are selling a textbook and want it to be sold to
>> > as
>> > many people as possible.
>>
>> So would you agree that the same argument makes sense if you are
>> creating a mathematics software system for which you want
>> contributions from as many people as possible?
>
> If the sole or even major criterion for excellence is how many people
> contribute to a piece of software, I think you will not have a very
> good piece of software.
How many people contribute is not my sole or major "criterion for
excellence". And, you just completely changed the subject., which is
"Lisp is better than Python".
How many people have the option to contribute is relevant factor on
which to compare Lisp and Python as a language choice. I maintain
that in this regard Python is a superior choice to Lisp. I think you
have in fact argued the same point.
>>
>> > As Norvig says in the video, the Lisp corresponded to the pseudo code.
>>
>> > And people who understood lisp probably understood that
>> > correspondence, since it was mostly 1:1.
>>
>> > For people who said "I understand the pseudocode but not the Lisp" ..
>> > do you really think they gained anything by seeing Python?
>>
>> I'm sure they gained by being able to read, modifying, and work with
>> the code (which they do with Python), instead of being frustrated by
>> having to constantly switch back and forth between two different
>> representations of the same idea (which they are forced to do by using
>> Lisp).
>
> My guess is that most of the students either understood neither, but
> thought
> they understood both.
To speak of "understanding" as an absolute -- either something is
understood or not -- is far too simplistic and naive to buseful.
Understanding is complicated and multidimensional. The question is
not whether or not something is understood, but "in what ways is
something understood? How well in each way?" Two people can "deeply
understand" the same thing in two orthogonal ways.
>
>>l
>> > (RJF) So assuming you are doing something that is not dependent on external
>> > stuff. Like symbolic integration, or building a geometric reasoning
>> > system for storing assumptions.
>>
>> There's a dangerous assumption above. Just because it's possible to
>> implement an algorithm without using "external stuff" doesn't mean
>> that is a good way to do it. Indeed, Sage's symbolic integration
>> *does* use the "external stuff" that's called "Maxima".
>
> That's fine, except you seem to be busy trying to replace it with
> Python code.
I'm not working on that right now.
> Also, your tools (in Python? Pexpect?) seem to have been a real
> problem.
They are also a real solution.
> So here is a case where Python is crappy, anyway.
Everything is crappy from an appropriate perspective. Computers are
just levels of hacks built on top of each other.
>> > The automatic differentiation program example I gave is reasonably
>> > ambitious and very easy to write in Lisp.
>> > Short, and (if you know Lisp) easy to read.
>>
>> > My guess is that it would be quite hard to write in Python; the
>> > easiest way, as I've said, would be to translate the Python to
>> > Lisp data, and do the job there. Then translate back to Python.
>>
>> I will refrain from further guessing about how hard it would be to
>> implement something that solves a vague formulation of a problem that
>> nobody cares about,
>
> Hm, Nobody = nobody you know? It seems you have uncovered a bunch of
> people,
> people even using python.
The problem I was referring to what "AD of Python programs", which was
what you launched this thread with. The list I gave was actual
formulations of AD problems involving Python. Those are concrete and
people clearly do care about them.
> But the majority of users of AD are not using python.
> I suspect that one or more of the projects is merely a front end using
> python which
> allows people to run AD on C++ programs.
> And the question remains, assuming the algorithm to be automatically
> differentiated is in Python how much of their programming effort was
> devoted
> to overcoming this choice of language?
>
>
> Actually, you might be something of an expert on things that nobody
> cares about. Judging from your CV.
Ooooh. I have two distinct academic lives:
(1) pure mathematics research, and
(2) computer software, hopefully for the masses.
When discussing computer software, applications, users, community,
etc., are all extremely important. When discussing pure mathematics
research, the criteria of quality and value are completely different,
since the goals of research mathematics, the techniques -- indeed
everything -- is completely different.
It is a difficult to live in two such different worlds, but I have the
maturity to at least understand that they are different worlds. I
hope you do too.
>>
>> > (RJF) Asking for popular opinion is not always the route to truth.
>>
>> And ignoring popular opinion is a sure route to creating software that
>> nobody cares about.
>
> There is a significant difference between writing software that many
> people contribute to
> and writing software that many people want to use. One does not
> follow from the other.
And ignoring popular opinion is a sure route to failing at both.
William
William Stein
>
>
>
> On Sep 5, 10:52 am, Ondrej Certik <ond...@certik.cz> wrote:
>
>> Great you setup this list William, it's nice to be able to discuss these things.
>>
>> Rjf --- I don't understand one thing --- I noticed in several of your
>> emails, that you don't value students who are "below average", e.g.
>> that they are not for you. Why is that?
>
> Let's say I can reasonably meet with 5 undergraduates per semester for
> projects.
> I have, say 30 applicants. I try to pick the best ones. Now some
> of these students have also applied for positions with
> other faculty, so I might not get the ones I think are the very best.
> But there is not much motivation for me to pick someone who is below
> average. My experience is that even the apparently good ones cannot be
> relied upon.
You are trying to apply to the Sage project the same filtering
mechanism you use for undergrad research students that you will
personally advise. That doesn't make any sense.
> (Wolfram, by the way, at one point said that he could hire the best
> people at WRI, and that this was a far better way of getting things
> done than via graduate students.)
I'm sure the WRI employees are much easier to keep in line and boss around.
>
>>
>> I believe that every student can do useful work. And in fact, judging
>> by grades, in many subjects, I am in the lower part of the class
>> myself. It's not in the grades. I think what matters is if you want to
>> do and then do it.
>
> Motivation counts. However it also counts if (a) You appear to know
> something
> about the subject, perhaps by taking courses. (b) You appear to be
> capable
> of working on a project -- you are smart enough, you have time to work
> on the
> project, you can work with others.
>
> I suppose that if you only have poorly educated, dumb students, then
> you have to use them.
> My assumption is that Sage contributions are not uniformly distributed
> across all "interested" people.
> I assume that a few of people make substantial contributions, (perhaps
> in separate projects),
> and that most people -- in spite of their love of Python -- are
> unlikely to do much of anything useful
> anytime soon.
What is "most people"? I would say your assumption is wrong, but I
can't dignify it with that, and
instead, I'll just have to say it is meaningless.
William
William Stein
>> > stuff. Like symbolic integration, or building a geometric reasoning
>> > system for storing assumptions.
>>
>> There's a dangerous assumption above. Just because it's possible to
>> implement an algorithm without using "external stuff" doesn't mean
>> that is a good way to do it. Indeed, Sage's symbolic integration
>> *does* use the "external stuff" that's called "Maxima".
>
> That's fine, except you seem to be busy trying to replace it with
> Python code.
> Also, your tools (in Python? Pexpect?) seem to have been a real
> problem.
Since I'm not working on any of this, by "you" I'll take it to mean
the Sage community. As it turns out, literally as you were writing
that, Nils Bruin posted a message to sage-devel that begins:
"Thanks to some very helpful changes to the way that ECL uses GMP made
by Juanjo, it is now possible to interface ECL cleanly with SAGE as a
library. I have constructed a prototype. Patch is available at:
http://sage.math.washington.edu/home/nbruin/eclmax.patch
...
"
This is the beginning of a potentially highly optimized C-level
Maxima<-->Sage interface.
So the simple fact of the matter is that instead of us being "busy
trying to replace it with Python code", we're writing a fast
Maxima<-->Sage interface.
William
Robert Bradshaw
An employer (like WRI) makes significant investments in its
employees. Likewise, in the academic sector, time and energy are
limited and valuable resources. It is totally rational to choose to
invest in the "best" (whatever that may mean to you) in these cases.
The context of an open source project is very different: there is
generally little time wasted on those who are unable to contribute
(for whatever reason). The people you actually spend time with have
already, for the most part, self-selected themselves out as the ones
who can contribute. That's not to say there's no place for mentoring
or employment, but the criteria there is much different.
Another distinction is that with an open source project is that the
barrier to entry is much more important. If you hire someone, they
can spend a whole day, maybe even weeks, trying to understand how to
work with a codebase. For an open source project, if it takes more
than a couple of hours to figure out what a piece of code is doing,
that will turn a lot of people away. This is where readability is
key. Again, this is completely subjective, but in my experience it's
much easier for a person who doesn't already know Python to
understand what a chunk of code does, and perhaps even locate (or
fix) a bug, than it is for someone who doesn't know Lisp to pick up
part of a Lisp program and even have the slightest clue of what it
means. Most contributors start out small, and as they get comfortable/
more familiar move onto bigger things (again, self-selecting like
above, with little (relative) investment on the project leaders
side). This is especially true when many potential contributors
usefulness is due to non-CS expertise.
A related but important point is that with a project like Sage,
rather than expecting (and counting on) person X to do Y, because Y
is important, we just expect someone to show up and do Y. The former
is much riskier, and depends on being able to select the "right" X.
Of course this doesn't always happen for every important Y, but the
larger the pool of potential developers the greater the chances of
this working.
- Robert
William Stein
A huge +1! I strongly agree with the above. It's exactly what I have
had difficulty putting into words. Robert -- if you have a blog -- it
would make a nice blog post.
William
rjf
On Sep 5, 1:06 pm, William Stein <wst...@gmail.com> wrote:
<snip..>
> > There is a significant difference between writing software that many
> > people contribute to
> > and writing software that many people want to use. One does not
> > follow from the other.
>
> And ignoring popular opinion is a sure route to failing at both.
are even written
in languages you consider unpopular. Orbitz comes to mind.
Many products, commercial and free, are unsuccessful, regardless of
the popularity of
the programming language underneath.
Popular opinion doesn't seem to have anything "sure" about it.
rjf
> what you launched this thread with. The list I gave was actual
> formulations of AD problems involving Python. Those are concrete and
> people clearly do care about them.
Python" do not,
at least for the links I could follow, describe differentiation of
programs written in Python.
Rather, they are front ends written in Python that give the user a
handle to differentiate
C++ programs, and they mostly call someone else's program, written in C
++.
They do, however, attest to some level of interest in AD.
That's like saying CocaCola is involved in automobile manufacturing
because some people drive
with cups of Coke in their cupholders.
rjf
> Maxima<-->Sage interface.
>
> So the simple fact of the matter is that instead of us being "busy
> trying to replace it with Python code", we're writing a fast
> Maxima<-->Sage interface.
really
just using Sage as a front-end to Maxima, is to use a front-end to
Maxima
written for Maxima, e.g. wxmaxima. I don't know what compromises
remain
in the ECL version of Maxima, but I'm suspicious of "conservative
garbage
collection" generally.
William Stein
>
>
>
> On Sep 5, 1:06 pm, William Stein <wst...@gmail.com> wrote:
> <snip..>
>>
>> > There is a significant difference between writing software that many
>> > people contribute to
>> > and writing software that many people want to use. One does not
>> > follow from the other.
>>
>> And ignoring popular opinion is a sure route to failing at both.
>
> Most successful commercial projects are written by few people. Some
> are even written
> in languages you consider unpopular. Orbitz comes to mind.
I checked and Orbitz evidently gets important parts of their software
from "ITA Software". I looked them up and found this:
http://www.eweek.com/c/a/Application-Development/Python-Slithers-into-Systems/
"ITA Software is using the Python language for its airline reservation
system, proving that sometimes snakes and planes do mix.
Last summers box office hit "snakes on a plane" was the unlikely story
of a batch of snakes getting loose in flight on a 747. In what some
might view as just as unlikely, ITA Software is using the Python
language to empower its airline reservation system.
Many computer language purists say that languages such as Java, C++ or
C should be used for enterprise applications. However, ITA, a
Cambridge, Mass., provider of airline IT software and services, is
proving that dynamic languages such as Python can be rock-solid for
enterprise work.
[...]
ITA Softwares customers include Air Canada, Alaska Airlines, Alitalia,
Continental Airlines, US Airways, Star Alliance, Galileo
International, Kayak, Orbitz and others."
rjf
On Sep 5, 1:44 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
>
> generally little time wasted on those who are unable to contribute
> (for whatever reason).
there is not much time wasted. Onlookers are free.
If someone attempts to contribute, but is really counterproductive,
there is the potential for wasting a LOT of time.
Certainly you've seen examples of that, even on Sage.
> The people you actually spend time with have
> already, for the most part, self-selected themselves out as the ones
> who can contribute. That's not to say there's no place for mentoring
> or employment, but the criteria there is much different.
>
> Another distinction is that with an open source project is that the
> barrier to entry is much more important. If you hire someone, they
> can spend a whole day, maybe even weeks, trying to understand how to
> work with a codebase. For an open source project, if it takes more
> than a couple of hours to figure out what a piece of code is doing,
> that will turn a lot of people away. This is where readability is
> key. Again, this is completely subjective, but in my experience it's
> much easier for a person who doesn't already know Python to
> understand what a chunk of code does, and perhaps even locate (or
> fix) a bug, than it is for someone who doesn't know Lisp to pick up
> part of a Lisp program and even have the slightest clue of what it
> means.
application.
A similarly shallow Lisp version may be just as easy to understand.
Comparing Python and Lisp code for a necessarily complex solution to a
deep
problem may yield different results. I would expect that to be the
case.
Now that ECL is being so intimately incorporated into Sage, maybe we
will see Sage fans learning Lisp so they can make Maxima do what
they want. They may then be able to compare, for themselves.
Of course Maxima includes some ancient code (parts date from 1963)
and so may not be the best examples of Lisp.
rjf
On Sep 5, 2:51 pm, William Stein <wst...@gmail.com> wrote:
...
> from "ITA Software". I looked them up and found this:
>
> "ITA Software is using the Python language for its airline reservation
> system, proving that sometimes snakes and planes do mix.
>
I followed your link regarding Orbitz..
If you read carefully, it says ...." Some of the key components are
written in Python. "
and
".., ITAs contract with Air Canada will have the company pulling Air
Canadas systems off the mainframe and onto a farm of Linux PCs. ..
So the question now is what is running on the farm of Linux PCs?
Python??
Let's learn about ITA itself instead of finding an article which
appears to be just pumping up Python.
(why would anyone do that?? why is it that ITA and Orbitz don't seem
to mention Lisp? Dunno, but...)
Say you want to get a job at ITA. What programming language might you
use? See
http://www.itasoftware.com/careers/l_e_t_lisp.html?catid=7
The title of that page is "Technologies we like: Lisp"
I highly recommend reading that half-page blurb. the comments it
makes may very well
be pertinent to parts of Sage.
there are also indications that ITA uses python, c++, java... so they
are not solely writing in Lisp.
You can try to judge the mix yourself. I wouldn't ordinarily place
Python in a time-critical
real-time computationally intensive situation like computing the least-
cost airline routes.
Originally this was done in Lisp. Maybe still, though they talk about
QPX, which seems to me
to be a language implemented in Lisp, which is compiled to assembler.
..............
oh, somewhere back there, someone suggested that my programs, written
on my own computer, with my own lisp, wouldn't be used by anyone else
because they weren't portable.
I expect that they run on the (estimated) 95% of the computers
running Windows XP or later, using free software (not GPL)
to do the Lisp. On 32 or 64 bit machines with AMD or Intel chips. It
might run on Linux systems or MacOS-X or Solaris or ... but frankly,
I'm not going to spend my time to make sure. Well, maybe I'll try
MacOS.
Unlike Sage, I don't require the user to install a virtual machine
system to run on Windows.
In that respect, It might be plausible to say my setup is more
portable than Sage, running on a higher percentage of actual computer
systems.
Maybe that is one of the advantages of using Lisp instead python? Runs
natively on Windows.
Just to bring the note back to the thread's subject.
RJF
Robert Bradshaw
>
> Unlike Sage, I don't require the user to install a virtual machine
> system to run on Windows.
>
> In that respect, It might be plausible to say my setup is more
> portable than Sage, running on a higher percentage of actual computer
> systems.
> Maybe that is one of the advantages of using Lisp instead python? Runs
> natively on Windows.
> Just to bring the note back to the thread's subject.
> RJF
To really bring it back to the title, Python runs just fine on
Windows, in fact it's probably more common and easier to get than Lisp.
Sage, well, Sage depends on a lot of stuff that doesn't run on
Windows. And you clearly aren't a going to suggest "well, let's just
re-write it all in Python" :)
- Robert
Robert Bradshaw
> On Sep 5, 1:44 pm, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> On Sep 5, 2009, at 12:58 PM, rjf wrote:
>>
> <snip>
>> The context of an open source project is very different:
> yes.
>> there is
>> generally little time wasted on those who are unable to contribute
>> (for whatever reason).
>
> If someone "does not contribute" and does not promise anything, then
> there is not much time wasted. Onlookers are free.
>
> If someone attempts to contribute, but is really counterproductive,
> there is the potential for wasting a LOT of time.
> Certainly you've seen examples of that, even on Sage.
Yes, of course. Nothing's perfect. But on the whole (implicitly or
explicitly) inviting people to participate/contribute is a whole lot
cheaper for a project like Sage than commercial software or academic
research.
>> The people you actually spend time with have
>> already, for the most part, self-selected themselves out as the ones
>> who can contribute. That's not to say there's no place for mentoring
>> or employment, but the criteria there is much different.
>
> Or disputes, creating branches etc.
>
>>
>> Another distinction is that with an open source project is that the
>> barrier to entry is much more important. If you hire someone, they
>> can spend a whole day, maybe even weeks, trying to understand how to
>> work with a codebase. For an open source project, if it takes more
>> than a couple of hours to figure out what a piece of code is doing,
>> that will turn a lot of people away. This is where readability is
>> key. Again, this is completely subjective, but in my experience it's
>> much easier for a person who doesn't already know Python to
>> understand what a chunk of code does, and perhaps even locate (or
>> fix) a bug, than it is for someone who doesn't know Lisp to pick up
>> part of a Lisp program and even have the slightest clue of what it
>> means.
>
> Perhaps the Python code is for an easily-explained and shallow
> application.
> A similarly shallow Lisp version may be just as easy to understand.
Suppose I walk up to a bunch of "random" people and ask what the
following code does:
def do_something(L):
total = 0
for a in L:
total = total + a
return total
I bet a good percentage would be able to deduce that this returns the
sum of the elements of L, even if they've never even heard of Python.
However, if I were to show them
(deffun do_something (L)
(if (null L) 0 (+ (car L) (do_something (cdr L)))))
let alone
(deffun do_something (L)
(reduce '+ L)
I doubt anyone who had never heard of Lisp would even have a clue,
and many people who had would have to think a bit.
> Comparing Python and Lisp code for a necessarily complex solution to a
> deep
> problem may yield different results. I would expect that to be the
> case.
Perhaps, but you can't start with complex code. Someone able to
understand complex code should find both Lisp and Python easy to pick
up and use.
> Now that ECL is being so intimately incorporated into Sage, maybe we
> will see Sage fans learning Lisp so they can make Maxima do what
> they want. They may then be able to compare, for themselves.
> Of course Maxima includes some ancient code (parts date from 1963)
> and so may not be the best examples of Lisp.
I am wildly enthusiastic about this project. I am also very
optimistic about SymPy and more Sage-native symbolic implementations.
- Robert
William Stein
>
>
>
> On Sep 5, 2:51 pm, William Stein <wst...@gmail.com> wrote:
> ...
>> I checked and Orbitz evidently gets important parts of their software
>> from "ITA Software". I looked them up and found this:
>>
>> http://www.eweek.com/c/a/Application-Development/Python-Slithers-into...
>>
>> "ITA Software is using the Python language for its airline reservation
>> system, proving that sometimes snakes and planes do mix.
>>
> ......
>
> I followed your link regarding Orbitz..
>
> If you read carefully, it says ...." Some of the key components are
> written in Python. "
>
> and
> ".., ITAs contract with Air Canada will have the company pulling Air
> Canadas systems off the mainframe and onto a farm of Linux PCs. ..
>
> So the question now is what is running on the farm of Linux PCs?
> Python??
>
> Let's learn about ITA itself instead of finding an article which
> appears to be just pumping up Python.
> (why would anyone do that??
I actually know a bit about ITA. For example, I gave a talk about
Sage at ITA once. They used to host the local Python Users Group
meetings in Boston, since a lot of their employees are really into
Python and the viewed hosting the meetings as a good recruitment
opportunity.
>
> ..............
> oh, somewhere back there, someone suggested that my programs, written
> on my own computer, with my own lisp, wouldn't be used by anyone else
> because they weren't portable.
You wrote: "What I sacrifice is: I write programs that are OS
dependent on one computer (my own) on one Lisp."
It sounds to me like you are saying that you write programs that
depend on your computer and your Lisp interpreter.
> I expect that they run on the (estimated) 95% of the computers
> running Windows XP or later, using free software (not GPL)
> to do the Lisp. On 32 or 64 bit machines with AMD or Intel chips. It
> might run on Linux systems or MacOS-X or Solaris or ... but frankly,
> I'm not going to spend my time to make sure. Well, maybe I'll try
> MacOS.
>
> Unlike Sage, I don't require the user to install a virtual machine
> system to run on Windows.
This has absolutely nothing to do with Python versus Lisp.
> In that respect, It might be plausible to say my setup is more
> portable than Sage, running on a higher percentage of actual computer
> systems.
> Maybe that is one of the advantages of using Lisp instead python? Runs
> natively on Windows.
Python runs natively on Windows. In fact, it is as easy or easier to
run Python and Python programs natively on Windows than Lisp programs.
William
rjf
On Sep 5, 5:28 pm, Robert Bradshaw <rober...@math.washington.edu>
> On Sep 5, 2009, at 2:57 PM, rjf wrote:
>
>
>
> > On Sep 5, 1:44 pm, Robert Bradshaw <rober...@math.washington.edu>
> > wrote:
> >> On Sep 5, 2009, at 12:58 PM, rjf wrote:
>
> > <snip>
> >> The context of an open source project is very different:
> > yes.
> >> there is
> >> generally little time wasted on those who are unable to contribute
> >> (for whatever reason).
>
> > If someone "does not contribute" and does not promise anything, then
> > there is not much time wasted. Onlookers are free.
>
> > If someone attempts to contribute, but is really counterproductive,
> > there is the potential for wasting a LOT of time.
> > Certainly you've seen examples of that, even on Sage.
>
> Yes, of course. Nothing's perfect. But on the whole (implicitly or
> explicitly) inviting people to participate/contribute is a whole lot
> cheaper for a project like Sage than commercial software or academic
> research.
How about if you were to show them idiomatic Lisp, like this:
(defun AddUpElements (L) (loop for i in L sum i))
or
(defun AddUpElements(L) (let ((total 0))
(dolist (i L total)
(setf total (+ i total)))))
or
(defun AddUpElements(L) (let ((total 0)) (dolist (i L)(setf total (+
i total))) total)
or
(defun AddUpElements(L)
(if (null L)
0
(+ (first L) (AddUpElements (rest L)))))
or
(apply #'+ L)
or, as you suggest
(defun AddUpElements(L) (reduce '+ L))
When you use the variable "total" in the Python program, you give a
big hint.
When you use car and cdr, you are deliberately obscuring the fact that
you are adding the first element to the sum of the rest of the
elements.
What do you think you would get if the program were
> I doubt anyone who had never heard of Lisp would even have a clue,
> and many people who had would have to think a bit.
style
is a pretty poor way to judge much. But I think we must agree to
disagree on this.
>
> > Comparing Python and Lisp code for a necessarily complex solution to a
> > deep
> > problem may yield different results. I would expect that to be the
> > case.
>
> Perhaps, but you can't start with complex code. Someone able to
> understand complex code should find both Lisp and Python easy to pick
> up and use.
it
may be better for structuring complex code.
>
> > Now that ECL is being so intimately incorporated into Sage, maybe we
> > will see Sage fans learning Lisp so they can make Maxima do what
> > they want. They may then be able to compare, for themselves.
> > Of course Maxima includes some ancient code (parts date from 1963)
> > and so may not be the best examples of Lisp.
>
> I am wildly enthusiastic about this project. I am also very
> optimistic about SymPy and more Sage-native symbolic implementations.
RJF
rjf
On Sep 5, 7:13 pm, William Stein <wst...@gmail.com> wrote:
....
> I actually know a bit about ITA. For example, I gave a talk about
> Sage at ITA once. They used to host the local Python Users Group
> meetings in Boston, since a lot of their employees are really into
> Python and the viewed hosting the meetings as a good recruitment
> opportunity.
in Lisp,
or you were bluffing, asserting that it was a Python based business.
>
>
>
> > ..............
> > oh, somewhere back there, someone suggested that my programs, written
> > on my own computer, with my own lisp, wouldn't be used by anyone else
> > because they weren't portable.
> You wrote: "What I sacrifice is: I write programs that are OS
>
> dependent on one computer (my own) on one Lisp."
>
> It sounds to me like you are saying that you write programs that
> depend on your computer and your Lisp interpreter.
world,
and the Lisp system I use can be run on any of them (given some disk
space)
free. So my work does not need to be ported. It runs on these
systems.
By the way, it is not quite right to refer to Lisp systems as
"interpreters" since
they can, and sometimes are, implemented entirely without
interpreters.
Just compilers and run-time system.
>
> > I expect that they run on the (estimated) 95% of the computers
> > running Windows XP or later, using free software (not GPL)
> > to do the Lisp. On 32 or 64 bit machines with AMD or Intel chips. It
> > might run on Linux systems or MacOS-X or Solaris or ... but frankly,
> > I'm not going to spend my time to make sure. Well, maybe I'll try
> > MacOS.
>
> > Unlike Sage, I don't require the user to install a virtual machine
> > system to run on Windows.
>
> This has absolutely nothing to do with Python versus Lisp.
the virtual machine environment on Windows, would I also need
a virtual machine environment on Windows to call it from Lisp?
Maybe. I think I've seen some situations where gcc and the
Microsoft C compiler don't do the same things, and that might
matter for Lisp too. The language C is just not as portable as
claimed.
>
> > In that respect, It might be plausible to say my setup is more
> > portable than Sage, running on a higher percentage of actual computer
> > systems.
> > Maybe that is one of the advantages of using Lisp instead python? Runs
> > natively on Windows.
>
> Python runs natively on Windows. In fact, it is as easy or easier to
> run Python and Python programs natively on Windows than Lisp programs.
Python, having just looked at
the web pages to do each. There is a gcl.exe at
http://www.cs.utexas.edu/users/novak/gclwin.html.
There are several nicer free lisps, and the one I use, Allegro Common
Lisp Express, has many
features absent from Gnu Common Lisp and ECL.
It is probably easier to download Maxima to Windows than Python.
see
http://sourceforge.net/projects/maxima/files/
maybe 2 clicks. One to download, one to execute the downloaded file.
As for how easy it is to run -- this depends on what you think is
"easy". A multiple-window
IDE, or a raw tty-window or an emacs buffer. or the front-end
wxmaxima.
They are all possible for Lisp.
RJF
William Stein
>
>
>
> On Sep 5, 5:28 pm, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> On Sep 5, 2009, at 2:57 PM, rjf wrote:
>>
>>
>>
>> > On Sep 5, 1:44 pm, Robert Bradshaw <rober...@math.washington.edu>
>> > wrote:
>> >> On Sep 5, 2009, at 12:58 PM, rjf wrote:
>>
>> > <snip>
>> >> The context of an open source project is very different:
>> > yes.
>> >> there is
>> >> generally little time wasted on those who are unable to contribute
>> >> (for whatever reason).
>>
>> > If someone "does not contribute" and does not promise anything, then
>> > there is not much time wasted. Onlookers are free.
>>
>> > If someone attempts to contribute, but is really counterproductive,
>> > there is the potential for wasting a LOT of time.
>> > Certainly you've seen examples of that, even on Sage.
>>
>> Yes, of course. Nothing's perfect. But on the whole (implicitly or
>> explicitly) inviting people to participate/contribute is a whole lot
>> cheaper for a project like Sage than commercial software or academic
>> research.
>
> How is it cheaper than just telling people to download Maxima?
If only things were so simple. We could all just go home.
Maxima was pretty impressive back in 1990. But by even the mid 1990s
it was left behind functionality-wise by Magma, GAP, Singular, PARI,
and R. For wide swaths of mathematics, each of those systems has
far, *far* surpassed Maxima purely on the basis of functionality and
performance. I've talked to the people who started and developed
some of the systems I mentioned above and they told me they tried to
use Maxima in the early 1990s for their work, but found it to be far
too slow to do research-level computations, so they switched to C (the
implementation language of all the above systems). This is a common
story. Even in 1992 Maxima wasn't up to snuff to support the work
research mathematicians were doing. It's nearly two decades later,
and Maxima isn't much different, is it?
Most Sage developers use Sage for *research* mathematics, so if you
wish to argue about the above with some statement like: "research math
is irrelevant", then you're not going to get far. I started Sage
primarily for research mathematics. That's it's primary reason for
existence.
Compared to the systems I listed above, *symbolic*
integration/differentiation is the one area that none of them do much
with, and Maxima does. That's because symbolic integration doesn't
come up much in actual mathematics research (which is ironic given
that most undergrads who take some math courses think calculus -- a
theory worked out in the 1680s -- *is* mathematics). If symbolic
integration does come up, the integral is often easy to do by hand or
impossible. In applied math, numerical solutions are often enough.
>> I doubt anyone who had never heard of Lisp would even have a clue,
>> and many people who had would have to think a bit.
>
> I think that asking people on the street for opinions on programming
> style
> is a pretty poor way to judge much. But I think we must agree to
> disagree on this.
What are you judging? Remember the title of the thread: "why lisp is
better than python". Robert Bradshaw pointed out that one way in
which Python is better than Lisp is that it is more readable to T.C.
MITS (the main on the street). I get the impression that you agree
with him on this point, but note that you don't consider this an
important criterion to consider.
William
William Stein
>
>
>
> On Sep 5, 7:13 pm, William Stein <wst...@gmail.com> wrote:
> ....
>
>> I actually know a bit about ITA. For example, I gave a talk about
>> Sage at ITA once. They used to host the local Python Users Group
>> meetings in Boston, since a lot of their employees are really into
>> Python and the viewed hosting the meetings as a good recruitment
>> opportunity.
>
> Well, you either didn't know that their core operation is programmed
> in Lisp,
> or you were bluffing, asserting that it was a Python based business.
Neither. I do know they also use Lisp a lot. That's why you
mentioned them in the first place. I just wanted to point out that
they also use Python.
>> > oh, somewhere back there, someone suggested that my programs, written
>> > on my own computer, with my own lisp, wouldn't be used by anyone else
>> > because they weren't portable.
>> You wrote: "What I sacrifice is: I write programs that are OS
>>
>> dependent on one computer (my own) on one Lisp."
>>
>> It sounds to me like you are saying that you write programs that
>> depend on your computer and your Lisp interpreter.
>
> That operating system is shared with 95% of the computers in the
> world,
"Apple market share tops 10%, Windows share lowest since tracking began":
http://www.tuaw.com/2009/01/02/apple-market-share-tops-10-windows-share-lowest-since-tracking/
>> > I expect that they run on the (estimated) 95% of the computers
>> > running Windows XP or later, using free software (not GPL)
>> > to do the Lisp. On 32 or 64 bit machines with AMD or Intel chips. It
>> > might run on Linux systems or MacOS-X or Solaris or ... but frankly,
>> > I'm not going to spend my time to make sure. Well, maybe I'll try
>> > MacOS.
>>
>> > Unlike Sage, I don't require the user to install a virtual machine
>> > system to run on Windows.
>>
>> This has absolutely nothing to do with Python versus Lisp.
>
> I don't know. If it is some program XyZ that Sage uses that requires
> the virtual machine environment on Windows, would I also need
> a virtual machine environment on Windows to call it from Lisp?
Yes. There's no native version of Sage-Python for Windows (yet --
this will change!) for pretty much the same reasons that there would
be no native Sage-Lisp for Windows.
> Maybe. I think I've seen some situations where gcc and the
> Microsoft C compiler don't do the same things, and that might
> matter for Lisp too. The language C is just not as portable as
> claimed.
Nobody in this discussion claimed C is portable...
>> > In that respect, It might be plausible to say my setup is more
>> > portable than Sage, running on a higher percentage of actual computer
>> > systems.
>> > Maybe that is one of the advantages of using Lisp instead python? Runs
>> > natively on Windows.
>>
>> Python runs natively on Windows. In fact, it is as easy or easier to
>> run Python and Python programs natively on Windows than Lisp programs.
>
> Actually, I think it is easier to download Lisp to Windows than
> Python, having just looked at
> the web pages to do each. There is a gcl.exe at
> http://www.cs.utexas.edu/users/novak/gclwin.html.
> There are several nicer free lisps, and the one I use, Allegro Common
> Lisp Express, has many
> features absent from Gnu Common Lisp and ECL.
>
> It is probably easier to download Maxima to Windows than Python.
> see
> http://sourceforge.net/projects/maxima/files/
>
> maybe 2 clicks. One to download, one to execute the downloaded file.
>
Python is completely trivial to install on Windows, and *comes
standard* with all other major operating systems:
-- William
Robert Bradshaw
[...]
My experience is that tail recursion is *very* idiomatic Lisp.
> like this:
>
> (defun AddUpElements (L) (loop for i in L sum i))
>
> or
>
> (defun AddUpElements(L) (let ((total 0))
> (dolist (i L total)
> (setf total (+ i total)))))
>
> or
>
> (defun AddUpElements(L) (let ((total 0)) (dolist (i L)(setf total (+
> i total))) total)
>
> or
>
> (defun AddUpElements(L)
> (if (null L)
> 0
> (+ (first L) (AddUpElements (rest L)))))
>
> or
>
> (apply #'+ L)
>
>
>
>
> or, as you suggest
>
> (defun AddUpElements(L) (reduce '+ L))
>
> When you use the variable "total" in the Python program, you give a
> big hint.
OK, replace "total" by "x" and of course "AddUpElements" by
"DoSomething." I would still argue that each program you've listed
above is more obscure (for someone who doesn't know Lisp) than the
Python implementation (for someone who doesn't know Python). And most
people start out not knowing either.
> When you use car and cdr, you are deliberately obscuring the fact that
> you are adding the first element to the sum of the rest of the
> elements.
To be honest, I first learned Lisp with car, cons, and cdr--I was not
trying to deliberately obscure things. And yeah, I'm way rusty.
> What do you think you would get if the program were
>
>
>> I doubt anyone who had never heard of Lisp would even have a clue,
>> and many people who had would have to think a bit.
>
> I think that asking people on the street for opinions on
> programming style
> is a pretty poor way to judge much. But I think we must agree to
> disagree on this.
This is why I put random in quotes. I'm with you that random people
on the street aren't necessarily the most meaningful set to consider,
but I believe the same conclusions hold for more relevant groups such
as "undergrads taking calculus this year" or "people who want to do
math on their computer" or "physics Ph.D. students" or "computational
number theorests" and many other groups of people that are relevant
(or not) to Sage.
- Robert
Ondrej Certik
Indeed, that was nicely written. I would also add, that very important
is that people belive in whoever is leading the project, that he can
eventually fix the bugs and fix broken code (or simply maintain the
code). For example I trust Sage and based FEMhub on Sage, because I
trust William that he can eventually fix (or knows how to fix) any
showstopper bugs and maintain the project, if very important people
leave the project (as they did in the past and will do so in the
future too).
Ondrej
rjf
> it was left behind functionality-wise by Magma, GAP, Singular, PARI,
> and R.
1. There is nothing I am aware of that is provided in Magma, GAP,
Singular, or PARI
that I wished I had in Macsyma. If I wanted to use R, (or S) or
Matlab, I used them.
2. In 1990, Macsyma was owned by a company that had its own technology
development plan, and marketing plan. They did not apparently notice
that there were people standing, with cash in their hands, wanting to
buy Macsyma if only it had more stuff from Magma (etc) in it. We can
speculate on why Macsyma was not a commercial success, but I would
sincerely doubt that it had anything to do with not-enough support for
pure mathematicians.
For wide swaths of mathematics, each of those systems has
> far, *far* surpassed Maxima purely on the basis of functionality and
> performance.
negligible compared to (say) applied mathematics or engineering. The
amount of funding for computing in pure mathematics has generally been
negligible, since mathematicians tend to prefer grant money to support
people. (the amount of money for buying computers for mathematicians
took a big leap a few decades ago when Alvin Thaler [incidentally,
with my help] promoted an "instrumentation" program for mathematicians
at NSF. We got VAX computers at a discount for math departments).
> I've talked to the people who started and developed
> some of the systems I mentioned above and they told me they tried to
> use Maxima in the early 1990s for their work, but found it to be far
> too slow to do research-level computations, so they switched to C (the
> implementation language of all the above systems).
Macsyma Inc to help them to
do their one-of-a-kind research computations.
> This is a common
> story. Even in 1992 Maxima wasn't up to snuff to support the work
> research mathematicians were doing. It's nearly two decades later,
> and Maxima isn't much different, is it?
other research mathematicians. Really, why should anyone care?
Also note that for many programs written in C it is quite easy to
write foreign-function call
from Lisp to that program. If people wanted to use Macsyma. But they
probably
couldn't afford Macsyma anyway, during its commerical phase.
> Most Sage developers use Sage for *research* mathematics, so if you
> wish to argue about the above with some statement like: "research math
> is irrelevant", then you're not going to get far.
some other research mathematics.
Much of R.M. is irrelevant to most other R.M. I have sat on enough
math PhD qualifying exams to
see that.
If research mathematics were relevant to something else, it would be
applied mathematics, not
research mathematics, and so irrelevance is a requirement. :)
> I started Sage
> primarily for research mathematics. That's it's primary reason for
> existence.
>
> Compared to the systems I listed above, *symbolic*
> integration/differentiation is the one area that none of them do much
> with, and Maxima does. That's because symbolic integration doesn't
> come up much in actual mathematics research (which is ironic given
> that most undergrads who take some math courses think calculus -- a
> theory worked out in the 1680s -- *is* mathematics). If symbolic
> integration does come up, the integral is often easy to do by hand or
> impossible. In applied math, numerical solutions are often enough.
elementary)
functions is a kind of parlor trick that overlaps to some extent with
freshman calculus, and
that relevance to applications is quite limited. In fact I think it
is an example
of Pure Mathematics, as pursued by Liouville, Ritt, Risch, and then
in the
post-1968 era, by a host of others with computer programming in mind.
But the teaching of symbolic calculus by pure mathematicians is a way
to keep them employed, and to keep riff-raff who can't do algebra from
graduating from college.
>
> >> I doubt anyone who had never heard of Lisp would even have a clue,
> >> and many people who had would have to think a bit.
>
> > I think that asking people on the street for opinions on programming
> > style
> > is a pretty poor way to judge much. But I think we must agree to
> > disagree on this.
>
> What are you judging? Remember the title of the thread: "why lisp is
> better than python". Robert Bradshaw pointed out that one way in
> which Python is better than Lisp is that it is more readable to T.C.
> MITS (the main on the street). I get the impression that you agree
> with him on this point, but note that you don't consider this an
> important criterion to consider.
is quite limited. I think that some of the Lisp programs I supplied
are sufficient for a reader to guess what they do, and I could
certainly return the favor by obscuring the python program ...by
renaming variables, so they would be less likely to guess. For
example....
StringConcatenation=StringConcatenation+i
or
PrintOut=Printout+I
or even
PrintOut+=i (in Python 2.0)
And I notice that you avoided declaring anything and using the key
Pythonesque grammatical constructions
which would have looked like foo.add or perhaps references to that
mysterious "self"
Incidentally, whatever indentation and spacing I had in the programs
seems to have gotten clobbered by pasting into this mail-writing
system (in google groups) so the lisp programs are mal-indented.
sorry about that. Maybe there are tabs that are lost in copying from
the emacs buffer in which all lisp programs are perfected indented.
RJF
rjf
On Sep 5, 10:03 pm, William Stein <wst...@gmail.com> wrote:
...snip...
> "Apple market share tops 10%, Windows share lowest since tracking began":
>
I was considering desk and laptop computers. This 10% includes Ipods
and Iphones.
The same article says that Windows XP alone has 65% of the installed
base.
Presumably Windows Vista, Windows 2000, add up to more. Still, my
point is:
my programs run on more computers natively (without VM) than yours,
and you agree....
<snip>
> Yes. There's no native version of Sage-Python for Windows (yet --
> this will change!) for pretty much the same reasons that there would
> be no native Sage-Lisp for Windows.
>
> > Maybe. I think I've seen some situations where gcc and the
> > Microsoft C compiler don't do the same things, and that might
> > matter for Lisp too. The language C is just not as portable as
> > claimed.
>
> Nobody in this discussion claimed C is portable...
is your problem.
<snip>
>
> > It is probably easier to download Maxima to Windows than Python.
> > see
> >http://sourceforge.net/projects/maxima/files/
>
> > maybe 2 clicks. One to download, one to execute the downloaded file.
>
> Python is completely trivial to install on Windows, and *comes
> standard* with all other major operating systems:
>
> http://python.org/download/
backwards-incompatible 3.1.1 or the 2.6.2, and also
if I want source, which is recommended on that page, or one of the
packaged versions. and that is
even before I click on a download.
RJF
Harald Schilly
>
> In my teaching of large courses[...] that this student is not for me.
I'm not sure what and how exactly you teach, but my idea of teaching
(when I do it) is to educate those who know less about the subject. I
do this by evaluating what they know, and don't know, build some kind
of dependency tree, sort it, repeat it, find the missing spots to fill
them in, etc.
You concentrate only on those who already know everything and ignore
the majority -- or even focus on those who are better than you. If I
would be sitting in your lecture, I would be dissatisfied and perhaps
a bit angry to be excluded, just because I don't already know lisp -
and I would try to attend a lecture somewhere else.
To tie this with the thread-title: My feeling is that with Python, you
get more students to code a useful program. The entrance barrier is
lower, intuition helps more, and from the coding examples later, it's
far more clear how a specific task should be coded. The lisp examples
for the same task are very different ... this implies inhomogeneous
code among different contributors [you said that you have rewrite it,
even if it is from a top 1% student], it needs more time to understand
what the code means... Python's "import this" zen philosophy is among
others: "There should be one-- and preferably only one --obvious way
to do it."
Perhaps we in the python worlds and you with lisp have totally
different attitudes towards others. We try to be open, help each
other, include code that works - even if it is not the best one - and
try to convince more to contribute. You filter by the language (lisp
cuts out the majority), you in part refuse to include code from top 1%
students because you have to rewrite it (which is also some kind of
rejection, e.g. copyright is yours, not her/his), and so on. We will
never find common ground.
H
rjf
On Sep 5, 10:04 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
<snip>
> My experience is that tail recursion is *very* idiomatic Lisp.
Recursion is, of course, possible.
But Common Lisp has a whole pile of iteration constructs, some of
which I
illustrated, and most experienced Lisp programmers would use one of
them
in this case.
Sometimes Scheme is taught to emphasize recursion because the teacher
or
text wishes to make a subtle point, which is that a recursive function
may
in fact be implemented by an iterative process. Also Scheme in its
simplest
form may be taught without "do loops" -- partly an intellectual
conceit, in my view.
I wrote other comments about the program in a previous response.
>
> OK, replace "total" by "x" and of course "AddUpElements" by
> "DoSomething." I would still argue that each program you've listed
> above is more obscure (for someone who doesn't know Lisp) than the
> Python implementation (for someone who doesn't know Python). And most
> people start out not knowing either.
+=i is so clear?
>
> To be honest, I first learned Lisp with car, cons, and cdr--I was not
> trying to deliberately obscure things. And yeah, I'm way rusty.
understanding on the 1959 Lisp 1.5 programmers manual.
There are many excellent books on Common Lisp.
<snip>
About polling people who are more or less random...
There are lots of things you could ask them about and they would
likely get them pretty much randomly wrong.
Questions about history, biology, nutrition, health, airline safety,
whether Obama was born in the US, which
is a better programming language, etc.
If you consider it important that a program read more or less like
English, then you should be programming in COBOL.
If you did the same test on mathematics, you could ask people which is
more understandable
NOT (P OR Q) = (NOT P) AND (NOT Q)
or
Given two statements each of which may be independently true or
false, you could say, neither one statement or the other is true, or
equivalently the statements are not both true.
uh, I think I got that about right.
Now which one would you like to use in proving theorems (or is
deMorgan's law not used any more?)
My point is that random people, or even "random technical" people
should no more be the judge of what should be in a programming
language for computer algebra systems, than most other things. Some
people have studied these issues, and have written position papers on
them. Now some of the positions may be wrong, or may be altered by
the passage of time and technical progress, but ignorance of the
positions is somewhat hazardous.
William Stein
>
>
>
> On Sep 5, 9:54 pm, William Stein <wst...@gmail.com> wrote:
>
> ....
>
>>
>> Maxima was pretty impressive back in 1990. But by even the mid 1990s
>> it was left behind functionality-wise by Magma, GAP, Singular, PARI,
>> and R.
>
> There are 2 perspectives here.
> 1. There is nothing I am aware of that is provided in Magma, GAP,
> Singular, or PARI
> that I wished I had in Macsyma. If I wanted to use R, (or S) or
> Matlab, I used them.
Quick review. You wrote "How is it cheaper than just telling people
to download Maxima?" I responded (in short): "Maxima doesn't solve
the problems that many Sage users have."
Your rebuttals:
1. You assume that the entire target audience of Sage is *you*. It isn't!
> 2. In 1990, Macsyma was owned by a company that had its own technology
> development plan, and marketing plan. They did not apparently notice
> that there were people standing, with cash in their hands, wanting to
> buy Macsyma if only it had more stuff from Magma (etc) in it. We can
> speculate on why Macsyma was not a commercial success, but I would
> sincerely doubt that it had anything to do with not-enough support for
> pure mathematicians.
Again, quick review: You wrote "How is it cheaper than just telling
people to download Maxima?" I responded (in short): "Maxima doesn't
solve the problems that many Sage users have for the following
reasons..."
Whether or not Macsyma was a commercial success, or Magma is (which it
*is* by the way), complete ignores my point about the limitations of
Maxima.
>
>
> For wide swaths of mathematics, each of those systems has
>> far, *far* surpassed Maxima purely on the basis of functionality and
>> performance.
>
> The amount of funding for pure mathematics has almost always been
> negligible compared to (say) applied mathematics or engineering. The
> amount of funding for computing in pure mathematics has generally been
> negligible, since mathematicians tend to prefer grant money to support
> people. (the amount of money for buying computers for mathematicians
> took a big leap a few decades ago when Alvin Thaler [incidentally,
> with my help] promoted an "instrumentation" program for mathematicians
> at NSF. We got VAX computers at a discount for math departments).
What's your point? I state that the systems research mathematicians
produced far surpass maxima, and you respond: "pure mathematicians
have no money". It's like a random response.
>> I've talked to the people who started and developed
>> some of the systems I mentioned above and they told me they tried to
>> use Maxima in the early 1990s for their work, but found it to be far
>> too slow to do research-level computations, so they switched to C (the
>> implementation language of all the above systems).
>
> This is just fine. It probably didn't make financial sense for
> Macsyma Inc to help them to
> do their one-of-a-kind research computations.
Given that you wrote "How is it cheaper than just telling people to
download Maxima?" and I responded (in short): "Maxima doesn't solve
the problems that many Sage users have for the following reasons..."
I think a conclusion of "This is just fine." is pretty irrelevant.
>
>> This is a common
>> story. Even in 1992 Maxima wasn't up to snuff to support the work
>> research mathematicians were doing. It's nearly two decades later,
>> and Maxima isn't much different, is it?
>
> Most work done by research mathematicians isn't even of interest to
> other research mathematicians. Really, why should anyone care?
So not only do you now agree with my claim: "Maxima doesn't solve the
problems that many Sage users have for the following reasons...", but
you are *glad* this is true?
> Also note that for many programs written in C it is quite easy to
> write foreign-function call
> from Lisp to that program. If people wanted to use Macsyma. But they
> probably
> couldn't afford Macsyma anyway, during its commerical phase.
>>
>> Most Sage developers use Sage for *research* mathematics, so if you
>> wish to argue about the above with some statement like: "research math
>> is irrelevant", then you're not going to get far.
>
> Well, irrelevant to what? Some research mathematics is relevant to
> some other research mathematics.
> Much of R.M. is irrelevant to most other R.M. I have sat on enough
> math PhD qualifying exams to
> see that.
>
> If research mathematics were relevant to something else, it would be
> applied mathematics, not
> research mathematics, and so irrelevance is a requirement. :)
Research mathematics can be either "pure or applied". The statement
you just made that "research mathematics" can't be applied mathematics
is hopelessly naive.
[Aside: I remember Berkeley Ph.D. math qualifying exams. Me and
another graduate student trolled the CS building looking for random CS
professor who we could have as the "outside member" of our committee
(it would have been ironic now if I had asked you, but that didn't
happen). You're right -- at the exams the outside member often does
not have a clue what is going on. (And Ph.D qualifying exams are
about core 2 year graduate-level mathematics, not research.)]
>> I started Sage
>> primarily for research mathematics. That's it's primary reason for
>> existence.
>
> That's awfully vague. All of research mathematics?
More of research mathematics than Maxima.
And as much as Maple, Magma, and Mathematica combined.
William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
William Stein
>
>
>
> On Sep 5, 10:03 pm, William Stein <wst...@gmail.com> wrote:
> ...snip...
>>
>> "Apple market share tops 10%, Windows share lowest since tracking began":
>>
>> http://www.tuaw.com/2009/01/02/apple-market-share-tops-10-windows-sha...
>
> I was considering desk and laptop computers. This 10% includes Ipods
> and Iphones.
> The same article says that Windows XP alone has 65% of the installed
> base.
> Presumably Windows Vista, Windows 2000, add up to more. Still, my
> point is:
> my programs run on more computers natively (without VM) than yours,
> and you agree....
Yes, I agree that right now your program runs natively on more
computers than Sage. I disagree that this has anything at all to do
with Lisp being better or worse than Python. Also, Sage will run on
Windows -- it's just a matter of time.
>> Nobody in this discussion claimed C is portable...
>
> I was just speculating on the gcc vs. Microsoft C, which I am guessing
> is your problem.
The problem is lack of developer effort and time. Little work has
gone into making Sage and its components work on Windows, because
very, very few people in the potential developer pool for Sage use
Windows. Here's a quote from Paul Graham that explains why pretty
nicely:
"The last nail in the coffin came, of all places, from Apple. Thanks
to OS X, Apple has come back from the dead in a way that is extremely
rare in technology. [2] Their victory is so complete that I'm now
surprised when I come across a computer running Windows. Nearly all
the people we fund at Y Combinator use Apple laptops. It was the same
in the audience at startup school. All the computer people use Macs or
Linux now. Windows is for grandmas, like Macs used to be in the 90s.
So not only does the desktop no longer matter, no one who cares about
computers uses Microsoft's anyway."
http://www.paulgraham.com/microsoft.html
>
> <snip>
>
>>
>> > It is probably easier to download Maxima to Windows than Python.
>> > see
>> >http://sourceforge.net/projects/maxima/files/
>>
>> > maybe 2 clicks. One to download, one to execute the downloaded file.
>>
>> Python is completely trivial to install on Windows, and *comes
>> standard* with all other major operating systems:
>>
>> http://python.org/download/
>
> No it isn't. I find that I have to first decide if I want the
> backwards-incompatible 3.1.1 or the 2.6.2, and also
> if I want source, which is recommended on that page, or one of the
> packaged versions. and that is
> even before I click on a download.
> RJF
You mean you actually read? Us kids these days just click on the first
link we see :-).
William
William Stein
> My point is that random people, or even "random technical" people
> should no more be the judge of what should be in a programming
> language for computer algebra systems, than most other things. Some
> people have studied these issues, and have written position papers on
> them. Now some of the positions may be wrong, or may be altered by
> the passage of time and technical progress, but ignorance of the
> positions is somewhat hazardous.
The above elitist ivory tower perspective is precisely why
Mathematica, Maple, Matlab, etc., have had so little competition.
-- William
rjf
On Sep 6, 9:49 am, William Stein <wst...@gmail.com> wrote:
> On Sun, Sep 6, 2009 at 8:38 AM, rjf<fate...@gmail.com> wrote:
>
><snip>
> > is your problem.
>
> The problem is lack of developer effort and time. Little work has
> gone into making Sage and its components work on Windows, because
> very, very few people in the potential developer pool for Sage use
> Windows.
> Here's a quote from Paul Graham that explains why pretty
> nicely:
1. I think it is premature to declare Microsoft dead. Choosing to
run Windows on IBM PCs (over, say, Berkeley UNIX on Sun Microsystems)
was never a technical decision, but a pragmatic one. It is still a
pragmatic decision to choose Windows over (say) Linux or Mac OS.
2. While Mac OSX is nice, I think that what saved Apple was iPod,
iPhone, iTunes.
3. It shouldn't matter to Sage. It doesn't matter to Maxima, so far
as I can tell.
Regarding PhD qualifying exams in Math (at Berkeley). I have attended
quite a few.
What has struck me more than anything else was the appearance that
the math professors asking questions, serially, often had no interest,
and likely not much knowledge of, the areas that their colleagues were
testing the candidates about.
That is, the exam had the form of
prof 1 asks questions of candidate, while profs 2, 3, 4 wait,
perhaps not knowing the answers themselves.
prof 2 asks questions of candidate, ....
Generally I had some connection with the candidate (topics of
interest, a course he/she had taken from me...) but typically the math
professors had not the slightest inkling or interest in that aspect of
the candidate's education.
There were a few areas, on the more elementary side of algebra or
analysis, where several math professors might jointly ask questions,
but mostly not. And as you say, these questions are not advanced, in
the scope of specialties.
Do outside examiners not "have a clue" what is going on? Certainly it
would be remarkable if the outside examiner could pass the qualifying
exam. But I suspect that some of the other faculty participants could
not answer the questions either.
I'm not sure how you count Magma as a success, since "While Magma is
a non-commercial system, we are required to recover all costs arising
from its distribution and support."
How is it a "commercial success" ?
As for the target audience for Macsyma/Maxima -- it's not just what I
am interested in -- after all, I'm more interesting in building tools
and testing / improving them. I have written a few papers on
"applications" like turbulence or celestial mechanics, but that's kind
of a side-line. There are large pieces of Macsyma that I mostly
ignore, like the various relativity packages.
To determine whether one person's research interest is worthy of
incorporation into some program or other, or not,
is either an individual decision by that person to devote time to
writing that program, or a kind of collective (or maybe even a
marketing-style) decision as to whether this program should be written
by (someone else?) to satisfy the needs of a bunch of people including
that original person.
So the audience for Maxima is whoever finds it interesting --as is --
or as a basis for building something else.
Perhaps the mathematicians referred to earlier who found Macsyma
unsatisfactory --as is -- really weren't
interested in building on it. They wanted to build their own systems,
and so they did. Some good, some bad.
Wolfram used Macsyma, but he decided he wanted to build his own
system. He wrote SMP, which did not
work out too well for technical and "property rights" reasons. Then
Mathematica. Does Mathematica do much of what
is in Magma? Or did WRI decide that the needs of Research
Mathematicians were, by and large, not
(commercially?) interesting?
RJF
William Stein
>
>
>
> On Sep 6, 9:49 am, William Stein <wst...@gmail.com> wrote:
>> On Sun, Sep 6, 2009 at 8:38 AM, rjf<fate...@gmail.com> wrote:
>>
>><snip>
>> > I was just speculating on the gcc vs. Microsoft C, which I am guessing
>> > is your problem.
>>
>> The problem is lack of developer effort and time. Little work has
>> gone into making Sage and its components work on Windows, because
>> very, very few people in the potential developer pool for Sage use
>> Windows.
>
> self perpetuating situation, I suspect.
I so wish! Unfortunately, the problem is much deeper. For starters,
compared to Linux and OS X, Microsoft Windows is simply an abysmal
platform for hobbyist open source software development. Their
standard (non-crippled) compiler has a list price of $799 (and a
street price of $549)!
http://www.amazon.com/Microsoft-Visual-Studio-2008-Professional/dp/B000WM04HU
The analogous tools for OS X and Linux are free. This specific
problem has been a major issue even for Sage.
The above price issue maybe doesn't impact commercial software
development... But for hobbyists, it is a major problem.
And that's just the beginning. Anyway, Windows versus Linux/OS X is a
wonderful topic for a mailing list devoted to flame wars! :-)
> Regarding PhD qualifying exams in Math (at Berkeley). I have attended
> quite a few.
>
> What has struck me more than anything else was the appearance that
> the math professors asking questions, serially, often had no interest,
> and likely not much knowledge of, the areas that their colleagues were
> testing the candidates about.
> That is, the exam had the form of
>
> prof 1 asks questions of candidate, while profs 2, 3, 4 wait,
> perhaps not knowing the answers themselves.
> prof 2 asks questions of candidate, ....
>
> Generally I had some connection with the candidate (topics of
> interest, a course he/she had taken from me...) but typically the math
> professors had not the slightest inkling or interest in that aspect of
> the candidate's education.
>
> There were a few areas, on the more elementary side of algebra or
> analysis, where several math professors might jointly ask questions,
> but mostly not. And as you say, these questions are not advanced, in
> the scope of specialties.
>
> Do outside examiners not "have a clue" what is going on? Certainly it
> would be remarkable if the outside examiner could pass the qualifying
> exam. But I suspect that some of the other faculty participants could
> not answer the questions either.
I'm sure you're right that in some cases some of the other
mathematicians also wouldn't have a clue. Advanced mathematics is
really really frickin' difficult.
> I'm not sure how you count Magma as a success, since "While Magma is
> a non-commercial system, we are required to recover all costs arising
> from its distribution and support."
>
> How is it a "commercial success" ?
I disagree with them describing themselves as "non-commercial".
> To determine whether one person's research interest is worthy of
> incorporation into some program or other, or not,
> is either an individual decision by that person to devote time to
> writing that program, or a kind of collective (or maybe even a
> marketing-style) decision as to whether this program should be written
> by (someone else?) to satisfy the needs of a bunch of people including
> that original person.
>
> So the audience for Maxima is whoever finds it interesting --as is --
> or as a basis for building something else.
> Perhaps the mathematicians referred to earlier who found Macsyma
> unsatisfactory --as is -- really weren't
> interested in building on it. They wanted to build their own systems,
> and so they did. Some good, some bad.
They would have loved to build on Maxima, since it would have saved
them a lot of time, but my understanding is that they decided they
just couldn't due to technical and social shortcoming of the system.
I guess it was "Lisp versus C" back then, and those people chose C out
of necessity.
Michael Stoll -- who was one of the two initial authors of CLISP --
wrote a huge amount of lisp code for computing with algebraic curves
(I have a copy of it somewhere that he gave me), but he switched to C
and Magma in the late 1990s. I gather that he didn't so much like the
Magma language, but there was simply no way to be nearly as productive
in his research program if he stuck with Lisp instead of switching to
Magma (I think because of Magma's superior library of functionality).
> Wolfram used Macsyma, but he decided he wanted to build his own
> system. He wrote SMP, which did not
> work out too well for technical and "property rights" reasons. Then
> Mathematica. Does Mathematica do much of what
> is in Magma?
No. There is almost zero overlap in functionality. Magma is streets
ahead of Mathematica at what Magma does. WRI are well aware of
these shortcomings in Mathematica, and they have made some attempts to
remedy them, e.g., by attempting to buy GAP. Fortunately, the GPL
prevented that from happening. This is an example of a concrete
situation in which the GPL turned out to be better than the BSD
license for... SAGE at least.
>Or did WRI decide that the needs of Research
> Mathematicians were, by and large, not
> (commercially?) interesting?
I think it's most likely that none of their 550 employees were unable
to implement the relevant algorithms (at nearly the same level as the
Magma group say), despite trying. As you yourself pointed out above,
advanced mathematics has the surprising property that three people on
the Ph.D. qualifying exam for a student can barely understand (let
alone answer) the questions the other people ask. There are other
social reasons that WRI would find it highly challenging to implement
say advanced number theory algorithms, since excellent relations with
the relevant communities are critical John Cannon at Magma has worked
hard over long time to develop such relationships with certain
communities that WRI has not. I remember John Cannon -- a group
theorist by training -- participating in whole computational number
theory conferences just to recruit talent to work on Magma.
I have looked at the algebraic number theory capabilities in
Mathematica, and I know the guy -- David Terr -- who implemented many
of them (I went to graduate school with him). For one guy working for
a few years, it's pretty good work. But it is hard to compete with
the combined fulltime effort of two generations of a whole "school" of
Germans (Pohst and the KANT group, Claus Fieker, Florian Hess, etc.)
who worked fulltime on algebraic number theory for nearly 20 years.
Magma incorporates all that work (and also much of Pari too at one
point). I know it is hard work, because the Sage project doesn't
get to use any of it, and we've been working for 4 years now to catch
up just in algebraic number theory, and definitely aren't there yet.
-- William
rjf
On Sep 6, 10:04 am, William Stein <wst...@gmail.com> wrote:
<snip>
> The above elitist ivory tower perspective is precisely why
> Mathematica, Maple, Matlab, etc., have had so little competition.
>
> -- William
amount of competition.
There are 51 systems listed in this article
http://en.wikipedia.org/wiki/Comparison_of_computer_algebra_systems
and that isn't counting variants which the author(S) deemed to be "the
same" with different front ends.
There are 12 more that are on hand-held calculators.
The article correctly doesn't count Matlab, which is not a CAS, though
perhaps a front end to one.
I suspect that the "elite" perspective which you malign is in fact a
partial explanation
for why there is in fact a considerable amount of competition but so
much of it
is apparently unsuccessful.
The elitist perspective: One problem with some of these systems is
that
they are built on the toes, rather than the shoulders of their
predecessors.
That is, their builders believed that their intuition, or maybe what
they learned
in elementary math classes was all they needed. Oh, and a copy of
"{programming language X} for dummies".
Persons who are naive technologically speaking have the possible
advantage of a fresh perspective.
But that is also a disadvantage. For example, Mathematica adopted a
model for approximate
(floating-point) arithmetic that was much in fashion in a few places
in the early 1960s.
But the Mathematica people probably failed to take note of (a) the
fact that they did not invent it;
and (b) it was largely discredited by subsequent numerical analysts.
So they put it in their system.
Oh, what's wrong with significance arithmetic in Mathematica?
try this
a = 1.11111111111111111111
While [a > 0, a = 2*a - a]
.....
Maybe your "random" person on the street would expect that to run
forever.
Not so. It stops almost immediately, and the value of a is 0.
Also, the value of a+1 is 0.
Now this would be startling to most people. More impressive might be
the fact
that this example was pointed out to them a few decades ago.
RJF
William Stein
>
>
>
> On Sep 6, 10:04 am, William Stein <wst...@gmail.com> wrote:
> <snip>
>>
>> The above elitist ivory tower perspective is precisely why
>> Mathematica, Maple, Matlab, etc., have had so little competition.
>>
>> -- William
>
> This would be an interesting hypothesis, but there's an enormous
> amount of competition.
>
> There are 51 systems listed in this article
> http://en.wikipedia.org/wiki/Comparison_of_computer_algebra_systems
>
> and that isn't counting variants which the author(S) deemed to be "the
> same" with different front ends.
>
> There are 12 more that are on hand-held calculators.
>
> The article correctly doesn't count Matlab, which is not a CAS, though
> perhaps a front end to one.
>
> I suspect that the "elite" perspective which you malign is in fact a
> partial explanation
> for why there is in fact a considerable amount of competition but so
> much of it
> is apparently unsuccessful.
Yes, I agree completely. I really meant to say "successful competition".
> The elitist perspective: One problem with some of these systems is
> that
> they are built on the toes, rather than the shoulders of their
> predecessors.
> That is, their builders believed that their intuition, or maybe what
> they learned
> in elementary math classes was all they needed. Oh, and a copy of
> "{programming language X} for dummies".
I think you're saying the above could indeed count as an elitist perspective.
>
> Persons who are naive technologically speaking have the possible
> advantage of a fresh perspective.
> But that is also a disadvantage. For example, Mathematica adopted a
> model for approximate
> (floating-point) arithmetic that was much in fashion in a few places
> in the early 1960s.
> But the Mathematica people probably failed to take note of (a) the
> fact that they did not invent it;
> and (b) it was largely discredited by subsequent numerical analysts.
> So they put it in their system.
>
> Oh, what's wrong with significance arithmetic in Mathematica?
> try this
>
> a = 1.11111111111111111111
>
> While [a > 0, a = 2*a - a]
Ouch.
> .....
> Maybe your "random" person on the street would expect that to run
> forever.
> Not so. It stops almost immediately, and the value of a is 0.
> Also, the value of a+1 is 0.
>
> Now this would be startling to most people. More impressive might be
> the fact
> that this example was pointed out to them a few decades ago.
>
> RJF
Hey we just completely agreed with each other back and forth. Wow!
William
rjf
> > they learned
> > in elementary math classes was all they needed. Oh, and a copy of
> > "{programming language X} for dummies".
>
> I think you're saying the above could indeed count as an elitist perspective.
>
naive
perspective. The elitist in this context (perhaps misnamed, since it
confused you?) would learn everything possible about previous
designs, programming language issues, etc. And then pontificate :)
Many of these 51 systems look more like the result of. Standing on
toes=
naive, not elite. Perhaps I should use "well-educated".
But the term I used was yours in "elitist ivory tower perspective".
Sorry to disappoint, I think we don't agree on this. You probably
won't
build a good system by ignoring past practice.
............
>
>
>
> > While [a > 0, a = 2*a - a]
>
> Ouch.
RJF
Ondrej Certik
I guess you put me and sympy also into this "naive perspective" crowd.
Sage uses maxima, so I guess Sage doesn't belong into "naive
perspective" crowd? :)
Ondrej
William Stein
I'm guessing everybody but RJF belongs to this "naive perspective" crowd?
-- William
rjf
On Sep 6, 1:29 pm, Ondrej Certik <ond...@certik.cz> wrote:
>
> I guess you put me and sympy also into this "naive perspective" crowd.
symbolic math systems?
My guess is, not much so far. That would make you naive, in my
judgment.
But that could be corrected.
> Sage uses maxima, so I guess Sage doesn't belong into "naive
> perspective" crowd? :)
naive. Here's why.
The notion of borrowing other peoples' more-or-less working/completed
systems and linking them together is an idea that, in my opinion, has
some merit. Something to seriously consider before embarking on a re-
engineering of the same ideas.
It has been explored by a number of groups, at various times in the
past, including stuff that I did myself in the early 1980s, using Lisp
as the glue to incorporate MINPACK into Macsyma, using VAX
computers.
but more recently there has been work under the label of "Problem
Solving Environments" or PSEs.
See
http://en.scientificcommons.org/43479332 for pointers into the
literature. I'm not claiming that the particular paper has
great insights, but it is a start. Rice and Houstis were big promoters
of the concept.
This PSE work was popular and got substantial funding about 10-12
years ago.
So Sage (actually its designers or implementors ) would be naive if
they were unaware of PSEs, their successes and failures.
Some PSE frameworks were considerably more ambitious in some
directions than Sage. For example, allowing for the close cooperation
of networked computers, where a task was partitioned in some clever
way. I am unaware of Sage doing this,
but maybe someone will walk in off the street and know about PSEs,
parallel computing, networking, grid computing, cloud computing, etc.
I'm not, incidentally, saying that PSEs were generally successful.
But have Sage people learned why some were successful and some were
not?
If not, I suggest that some people learn about PSEs, since they seem
like a similar kind of thing 7 years previously.
Of course those projects had substantial funding from the Dept. of
Energy, DARPA, and probably didn't have the advantage of
Python and volunteer programmers.
rjf
On Sep 6, 2:10 pm, William Stein <wst...@gmail.com> wrote:
>
> I'm guessing everybody but RJF belongs to this "naive perspective" crowd?
compilers
and programming languages would be less naive, in some respects, than
what I've seen here.
Students who've taken a (graduate) course on topics in the
implementation
of symbolic math systems would be less naive, in other respects, than
what
I've seen here.
add to that, people involved in any of several major computer algebra
systems might provide
useful guidance that would perhaps be quite specific.
Expertise in organizing bug tracking and newsgroups, and enthusiasm
from volunteers
does not strike me as an effective system design mechanism sufficient
to counter the
missteps likely from a naive approach. But that just gives you a
rationale to seek funding
for Sage-2.
RJF
Ondrej Certik
>
>
>
> On Sep 6, 2:10 pm, William Stein <wst...@gmail.com> wrote:
>
>>
>> I'm guessing everybody but RJF belongs to this "naive perspective" crowd?
>
> Certainly not. Students who've taken a decent undergraduate course in
> compilers
> and programming languages would be less naive, in some respects, than
> what I've seen here.
> Students who've taken a (graduate) course on topics in the
> implementation
> of symbolic math systems would be less naive, in other respects, than
> what
> I've seen here.
I studied theoretical physics, so I think I am totally disqualified by
your merits. :) No compilers, no programming languages and certainly
no courses on symbolic math. We had quite some numeric courses though,
but they let us use any language we wanted, so I used python + cython.
Ondrej
Ondrej Certik
>
>
>
> On Sep 6, 1:29 pm, Ondrej Certik <ond...@certik.cz> wrote:
>
>>
>> I guess you put me and sympy also into this "naive perspective" crowd.
>
> I don't know. What have you studied about past attempts to build
> symbolic math systems?
> My guess is, not much so far. That would make you naive, in my
> judgment.
Actually, I studied I think every major opensource CAS (maxima, axiom,
ginac, giac, and lots of others). So I studied them, made a personal
conclusion that they all kind of failed because they don't use a
mainstream language, so I chose Python and did my best.
But as you wrote in your second email, I have never studied any course
on symbolic math, or compilers.
> But that could be corrected.
Thanks, I will do my best. :)
Ondrej
rjf
On Sep 6, 4:33 pm, Ondrej Certik <ond...@certik.cz> wrote:
> I studied theoretical physics, so I think I am totally disqualified by
> your merits. :) No compilers, no programming languages and certainly
> no courses on symbolic math. We had quite some numeric courses though,
> but they let us use any language we wanted, so I used python + cython.
would consider
you a prime candidate to repeat the mistakes of past implementors of
symbolic math systems, some of whom were, indeed, theoretical
physicists.
At least Stephen Wolfram made a big show of reading Knuth's books on
"the Art of Computer Programming". :)
... but in your next message you say something else...
As for studying every major opensource CAS, that's nice. But in my
opinion
you came to quite a wrong conclusion (that they failed because of the
use of a mainstream language [as a user language? an implementation
language? both?]
There are papers, e.g. by Richard Jenks, Anthony Hearn, and others on
this issue
of language choice.
You (or someone) should check on PSEs and Python. E.g.
http://lacsi.rice.edu/thrusts/components/integration
a project that was funded, perhaps lavishly, until 2004.
RJF
RJf
rjf
On Sep 6, 12:08 pm, William Stein <wst...@gmail.com> wrote:
.. snip...
> I so wish! Unfortunately, the problem is much deeper. For starters,
> compared to Linux and OS X, Microsoft Windows is simply an abysmal
> platform for hobbyist open source software development. Their
> standard (non-crippled) compiler has a list price of $799 (and a
> street price of $549)!
compile stuff and distribute the binaries.
Thus the problem goes away if there is one person who compiles stuff,
every so often.
Unless you insist that everyone must be able to compile stuff. That is
your choice. Not mine.
>
><snip>
> I'm sure you're right that in some cases some of the other
> mathematicians also wouldn't have a clue. Advanced mathematics is
> really really frickin' difficult.
>
> > I'm not sure how you count Magma as a success, since "While Magma is
> > a non-commercial system, we are required to recover all costs arising
> > from its distribution and support."
>
> > How is it a "commercial success" ?
>
> I disagree with them describing themselves as "non-commercial".
with the revenues from Magma?
>
<snip... regarding 'some mathematicians'>
> They would have loved to build on Maxima, since it would have saved
> them a lot of time, but my understanding is that they decided they
> just couldn't due to technical and social shortcoming of the system.
there is a well-known "Not Invented Here"
syndrome. It is obviously hard to stop people, especially on
different continents, from doing what they want.
Even if it means they are implementing some hackish crock based on a
1960s view of languages.
> I guess it was "Lisp versus C" back then, and those people chose C out
> of necessity.
>
> Michael Stoll -- who was one of the two initial authors of CLISP --
> wrote a huge amount of lisp code for computing with algebraic curves
> (I have a copy of it somewhere that he gave me), but he switched to C
> and Magma in the late 1990s. I gather that he didn't so much like the
> Magma language, but there was simply no way to be nearly as productive
> in his research program if he stuck with Lisp instead of switching to
> Magma (I think because of Magma's superior library of functionality).
interpreter. So
I don't know if speed itself was an issue. Switching to Magma to take
advantage of other peoples' efforts sounds plausible.
>
> > Wolfram used Macsyma, but he decided he wanted to build his own
> > system. He wrote SMP, which did not
> > work out too well for technical and "property rights" reasons. Then
> > Mathematica. Does Mathematica do much of what
> > is in Magma?
>
> No. There is almost zero overlap in functionality.
> Magma is streets
> ahead of Mathematica at what Magma does. WRI are well aware of
> these shortcomings in Mathematica, and they have made some attempts to
> remedy them, e.g., by attempting to buy GAP.
> Fortunately, the GPL
> prevented that from happening. This is an example of a concrete
> situation in which the GPL turned out to be better than the BSD
> license for... SAGE at least.
>
> >Or did WRI decide that the needs of Research
> > Mathematicians were, by and large, not
> > (commercially?) interesting?
>
> I think it's most likely that none of their 550 employees were unable
> to implement the relevant algorithms (at nearly the same level as the
> Magma group say), despite trying.
numerous)
are likely engaged in marketing, sales, packaging, documentation,
graphics, testing,
designing T-shirts etc, I don't think that's the issue. Are you sure
they were trying??
> As you yourself pointed out above,
> advanced mathematics has the surprising property that three people on
> the Ph.D. qualifying exam for a student can barely understand (let
> alone answer) the questions the other people ask. There are other
> social reasons that WRI would find it highly challenging to implement
> say advanced number theory algorithms, since excellent relations with
> the relevant communities are critical John Cannon at Magma has worked
> hard over long time to develop such relationships with certain
> communities that WRI has not. I remember John Cannon -- a group
> theorist by training -- participating in whole computational number
> theory conferences just to recruit talent to work on Magma.
interested in cultivating
the communities that are keen on using Magma. After all, if they are
using
Magma, why would they buy Mathematica? And after they bought Magma,
they wouldn't have any money left.
>
> I have looked at the algebraic number theory capabilities in
> Mathematica, and I know the guy -- David Terr -- who implemented many
> of them (I went to graduate school with him). For one guy working for
> a few years, it's pretty good work.
> But it is hard to compete with
> the combined fulltime effort of two generations of a whole "school" of
> Germans (Pohst and the KANT group, Claus Fieker, Florian Hess, etc.)
> who worked fulltime on algebraic number theory for nearly 20 years.
> Magma incorporates all that work (and also much of Pari too at one
> point). I know it is hard work, because the Sage project doesn't
> get to use any of it, and we've been working for 4 years now to catch
> up just in algebraic number theory, and definitely aren't there yet.
Magma and will be (free) in Sage,
I think that's remarkable.
RJF
Ondrej Certik
>
>
>
> On Sep 6, 4:33 pm, Ondrej Certik <ond...@certik.cz> wrote:
>> I studied theoretical physics, so I think I am totally disqualified by
>> your merits. :) No compilers, no programming languages and certainly
>> no courses on symbolic math. We had quite some numeric courses though,
>> but they let us use any language we wanted, so I used python + cython.
>
> Yes, I consider you naive, if that's all you have as a background. I
> would consider
> you a prime candidate to repeat the mistakes of past implementors of
> symbolic math systems, some of whom were, indeed, theoretical
> physicists.
Thank you for your consideration. How would you suggest me to improve,
so that I am not naive and don't repeat past mistakes?
Ondrej
William Stein
>
>
>
> On Sep 6, 12:08 pm, William Stein <wst...@gmail.com> wrote:
> .. snip...
>
>> I so wish! Unfortunately, the problem is much deeper. For starters,
>> compared to Linux and OS X, Microsoft Windows is simply an abysmal
>> platform for hobbyist open source software development. Their
>> standard (non-crippled) compiler has a list price of $799 (and a
>> street price of $549)!
>
> Well, I have access to a Windows development environment, and I can
> compile stuff and distribute the binaries.
> Thus the problem goes away if there is one person who compiles stuff,
> every so often.
> Unless you insist that everyone must be able to compile stuff. That is
> your choice. Not mine.
We were discussing the difficulty of attracting developers to work on
the port of Sage to Windows. You stated that our difficulty in
getting Windows developers was "momentum". I pointed out one very
serious real reason for this, and you came back with a remark that has
absolutely nothing to do with the discussion at all! And there are
many more similar reasons I could point out.
>> > I'm not sure how you count Magma as a success, since "While Magma is
>> > a non-commercial system, we are required to recover all costs arising
>> > from its distribution and support."
>>
>> > How is it a "commercial success" ?
>>
>> I disagree with them describing themselves as "non-commercial".
>
> Can you explain this? Do you think John Cannon is furnishing his home
> with the revenues from Magma?
Several people's fulltime salaries are paid for by revenue from Magma.
They do indeed furnish their homes, so you make your own conclusions.
If you want a copy of Magma you *have* to pay > $1000 (or whatever) for it.
To me this means "commercial software". However, the term
"commercial software" is fairly recent and certainly people disagree
on what it means. For example:
* PC Mag: "Software that is designed and developed for sale to the
general public."
* TechTerms.com: "Commercial software requires payment before it can
be used, but includes all the program's features, with no restrictions
or time limits."
* FSF: "Commercial software is software being developed by a
business which aims to make money from the use of the software."
Certainly Magma is commercial software according to the first two
definitions. According to the third, it's less clear, since Magma is
developed by Univ of Sydney, which maybe (?) isn't a "business".
I do realize that the Magma group itself does not like Magma to be
called "commercial software".
>>
> <snip... regarding 'some mathematicians'>
>>
>> They would have loved to build on Maxima, since it would have saved
>> them a lot of time, but my understanding is that they decided they
>> just couldn't due to technical and social shortcoming of the system.
>
> Well, it is hard to say what motivates some people to do things, but
> there is a well-known "Not Invented Here"
> syndrome. It is obviously hard to stop people, especially on
> different continents, from doing what they want.
> Even if it means they are implementing some hackish crock based on a
> 1960s view of languages.
It may be hard to say what motivated people... if they hadn't told me
at length what actually motivated them. A lot of people love to
tell me their experiences with writing software. You're spending
your weekend doing so, and you're not the only one.
>> Magma is streets
>> ahead of Mathematica at what Magma does. WRI are well aware of
>> these shortcomings in Mathematica, and they have made some attempts to
>> remedy them, e.g., by attempting to buy GAP.
>
> Really? I hadn't heard of that. Is this well known?
No, it was not well known.
>> Fortunately, the GPL
>> prevented that from happening. This is an example of a concrete
>> situation in which the GPL turned out to be better than the BSD
>> license for... SAGE at least.
>>
>> >Or did WRI decide that the needs of Research
>> > Mathematicians were, by and large, not
>> > (commercially?) interesting?
>>
>> I think it's most likely that none of their 550 employees were unable
>> to implement the relevant algorithms (at nearly the same level as the
>> Magma group say), despite trying.
>
> since the vast majority of their employees (who, I doubt are quite so
> numerous)
> are likely engaged in marketing, sales, packaging, documentation,
> graphics, testing,
> designing T-shirts etc, I don't think that's the issue. Are you sure
> they were trying??
I'm sure that had at least one fulltime employee (David Terr -- who
was a Lenstra student at Berkeley at the same time as me) for many
years, and that he tried very hard to implement quite a lot of
algebraic number theory in Mathematica.
>> As you yourself pointed out above,
>> advanced mathematics has the surprising property that three people on
>> the Ph.D. qualifying exam for a student can barely understand (let
>> alone answer) the questions the other people ask. There are other
>> social reasons that WRI would find it highly challenging to implement
>> say advanced number theory algorithms, since excellent relations with
>> the relevant communities are critical John Cannon at Magma has worked
>> hard over long time to develop such relationships with certain
>> communities that WRI has not. I remember John Cannon -- a group
>> theorist by training -- participating in whole computational number
>> theory conferences just to recruit talent to work on Magma.
>
> This is interesting, but I find it hard to believe that WRI is
> interested in cultivating
> the communities that are keen on using Magma.
I don't know if they are interested or not. Fact is they haven't done
so, or if they have tried they have completely failed. My claim is
*only* that WRI are in no position to implement algorithms relevant to
large swaths of mathematics.
Maple has a similar problem, though I get the impression that they
have tried much, much harder to cultivate relationships with academia.
> After all, if they are
> using
> Magma, why would they buy Mathematica?
You're sneaky -- I can only answer this by becoming a Mathematica
sales shill. Mathematica has tons of interesting advantages over
Magma. Magma has no notebook, no graphics at all, no numerical
computation at all, no symbolic calculus at all, etc. etc. Magma
was far from satisfying my personal needs due to lack of
functionality. It's just way ahead in some extremely important key
areas, and doesn't compete in most areas you (=RJF) would think of.
> And after they bought Magma, they wouldn't have any money left.
Depends on "they".
>
>>
>> I have looked at the algebraic number theory capabilities in
>> Mathematica, and I know the guy -- David Terr -- who implemented many
>> of them (I went to graduate school with him). For one guy working for
>> a few years, it's pretty good work.
>
> Huh? earlier you said that Mathematica has zero overlap...
This is really just the tip of the iceberg. Both systems can compute
"2+2", so I didn't literally mean "0 overlap".
>> But it is hard to compete with
>> the combined fulltime effort of two generations of a whole "school" of
>> Germans (Pohst and the KANT group, Claus Fieker, Florian Hess, etc.)
>> who worked fulltime on algebraic number theory for nearly 20 years.
>> Magma incorporates all that work (and also much of Pari too at one
>> point). I know it is hard work, because the Sage project doesn't
>> get to use any of it, and we've been working for 4 years now to catch
>> up just in algebraic number theory, and definitely aren't there yet.
>
> Well, if WRI sees a way of making money re-implementing what is in
> Magma and will be (free) in Sage,
> I think that's remarkable.
Is that how you summarize what I just wrote? Gees. I just explained
at length why it would be incredibly difficult (maybe impossible) for
WRI to re-implement what is in Magma, but that they would like to if
they could. The only thing I think WRI is likely to do any time in
the next 5 years in the domain Magma addresses would be to buy Magma.
-- William
rjf
non-profits are not. (nor are schools or churches)
Though I am not sure what happens in Australia.
Some commercial enterprises give away software (Adobe Reader, Allegro
Common Lisp Express).
Berkeley UNIX, when distributed as a carton of magnetic tapes cost
about $200.
(after assurance that a proper ATT license was in place).
If Sage pays a clerk out of grant money, or money received from
Microsoft, does that make Sage commercial? :)
rjf
On Sep 6, 6:36 pm, Ondrej Certik <ond...@certik.cz> wrote:
> Thank you for your consideration. How would you suggest me to improve,
> so that I am not naive and don't repeat past mistakes?
lecture series.
I think this discussion should be moved off sage-flame though.
Maybe to sci.math.symbolic.
Why don't you ask your question there?
>
William Stein
For me the term "commercial software" means "software that (legally)
you have to pay to use", i.e., for which an act of *commerce* takes
place in order for one to get the software. That has the advantage
that it is crystal clear to decide whether or not a given item of
software is commercial. By that definition, Sage is certainly not
commercial software, and Magma certainly is.
Wikipedia's definition is: "Commercial software is computer software
that is produced for sale[1] or that serves commercial purposes."
That's nearly the same as mine. They cite [1], which is
dictionary.com's Computing Dictionary, which says "commercial software
software: (Or "commercial off-the-shelf software", COTS) Software
that is produced for sale."
Note that none of the definitions in the previous paragraph make any
distinction about what sort of organization is doing the selling.
William
Bjarke Hammersholt Roune
> from volunteers
> does not strike me as an effective system design mechanism sufficient
> to counter the
> missteps likely from a naive approach.
>
CAS. One is the actual implementation of algorithms, where what
matters is that the resulting program is fast, correct, consumes
little memory, has few limitations and is written in a way that makes
it straight forward to use, modify and build on - often conflicting
goals. I'm sure you believe that Sage has some issues here, such as
preferring Python, Cython and C/C++ over Lisp, but I don't think this
is your fundamental complaint in the quote above.
The way I understand you, you are talking about the overall design
decisions in building a CAS, such as how piece-wise defined functions
are dealt with (or not dealt with). These decisions are not so easily
changed a few years down the line, because such a thing as piece-wise
functions are necessarily exposed to the users of the system, and
their code might then stop working. Also, if hundreds of algorithms
has code to do something with piece-wise functions, then a fundamental
change is just really a huge amount of work to carry out throughout
the system. I think the coercion system replacement that was done in
Sage some time ago is an example of such a change, and it was already
a lot of trouble, somewhat halting most other developments for a
while, and such changes will only become harder in future.
You are advocating a careful approach, where a small team of
experienced and highly intelligent people lock themselves in a room
for a long time, discussing approaches and investigating the successes
and failures of many past systems. The way I understand it, the
original release of Sage was written by William Stein, and while he
may be the kind of person you would like to have in the locked room
above, he was just one person and was in a mode of getting as much
done as quickly as possible. Sage started there and has been improved
since then by iteration. I would call this a productive approach.
Oversimplifying, you might say that you want mostly global
optimization, while Sage practices mostly local optimization. Since
Sage is still so far from optimum, using mostly local optimization
allows it to proceed at a much faster pace. What you are pointing out
is that eventually, Sage will find itself in a local optimum, and at
that point, making the fundamental changes necessary to get out of
that optimum will be expensive in terms of work and in terms of
disrupting users. In some or even many areas (certainly not all), this
might indeed be where Mathematica, Maple and so on are now - certain
fundamental and beneficial changes are too expensive to carry out, and
so those changes will never be done.
Certainly Sage is going to encounter issues down the line that could
have been avoided by a team of experienced professional CAS developers
taking their time, and in many cases getting past those issues will be
much more trouble than it would have been to do it better the first
time - in some cases maybe so much trouble that it just isn't going to
get done. You are right - this is a disadvantage of the way Sage is
set up, and no amount of "expertise in organizing bug tracking and
newsgroups, and enthusiasm from volunteers" is going to change that.
You are right.
However, wouldn't that situation actually be quite wonderful? At that
point, certainly Sage would have reached its goal of being a viable
alternative to the M's, since you say that those systems were designed
in the same productive and less careful way. It would be wonderful to
be in that situation, and Sage is the way to get there. Sage has
technical advantages and disadvantages, but I wouldn't say that is the
primary strength it has. For one, I don't know that Python is
technically superior to Lisp, in fact I get the impression that the
toolchain for Lisp is more capable when it comes to compilation and
speedy execution. There is innovation in Sage the software system, and
I'm sure that is going to increase with time, but the real innovation,
in the world of free software CASes, is in Sage the project, a social
entity. So the people here argue that Python is socially superior to
Lisp, and you argue the technical side of the matter, and there is a
mismatch there.
Without "expertise in organizing bug tracking and newsgroups, and
enthusiasm from volunteers" and other such things, Sage would have
been whatever William Stein could have written by himself by now, and
however productive he is, that pales in comparison to what Sage is
now. Sage the project succeeds because it is able to make people show
up and increase the pace of development, and the locked room of
veterans achieves no such thing. Imagine where Wikipedia would be
today if only the kind of people who would find employment at
Encyclopædia Britannica were allowed to contribute. To underscore the
point, I just as a matter of course visited Wikipedia to find out if
the company producing Encyclopædia Britannica is actually called
Encyclopædia Britannica (it's called Encyclopædia Britannica Inc.).
A different question is, where are you going to find enough highly
intelligent veterans with a strong higher mathematics background and
excellent programming skills to build something like what Sage is
trying to be, EVEN IF you had the money to pay them? Where are you
going to find the money then? I imagine the operating expenses of,
say, Mathematica is well in excess of what any open CAS is ever going
to get in funding anytime soon, even when subtracting things like
advertising and support, and you don't seem to think that the people
at Mathematica are doing a good enough job.
This locked room of veterans of yours... well, OK, of mine that I'm
inventing for you, doesn't exist and isn't going to. The closest thing
we are going to get is for various smart people to write articles
about their experiences, and then for some of them to write books
based on that, and then for the books to be well enough argued and
written that people who read it are going to say "yes, I'll do it like
that." The impression I get is that the field of computer algebra
systems just isn't well enough established for that to have happened.
Another option is for veterans such as yourself to give advice in a
place like this, e.g. on issues such as how to implement piece-wise
functions. On the other hand then you run into the fact that people
with no experience but who are willing to write the code can get more
influence than you simply because code speaks louder than words, which
is also a common complaint on Wikipedia.
Cheers
Bjarke
PS. I recently read an interview with someone from a company called
Bioware about their upcoming computer game Dragon Age: Origins, which
I'm looking forward to play. This is a single player game, and on the
question of why there is no multiplayer option, the Bioware employee
said, from memory, that "at Bioware we have the policy that if we
can't do something to a high degree of excellence, we just don't do it
at all." This is the choice Sage has in many contexts - do something
well but not as well as might be possible, or don't do it at all. It
is often not a choice of whether to do something well or to do it
perfectly.
rjf
On Sep 7, 7:26 am, Bjarke Hammersholt Roune <bjarke.ro...@gmail.com>
wrote:
<snip> stuff I agree with. Thanks.
The small team or the large social network of people can still benefit
from education or experience. CAS that are (more or less) successful
today generally have a history of being the nth in a series of
versions and/or having developers with substantial experience.
For example, Macsyma started in 1966, but was built by people who
wrote Mathlab (Engleman), and Symbolic Math Laboratory (William
Martin) and SIN (Joel Moses), using code that went back to 1963.
Axiom was a rewrite of Scratchpad I, II ? III maybe? By Jenks,
Griesmer, others.
Mathematica was Wolfram's second CAS, after SMP. Maple, of all of
these, may have stuck to its initial system design more than the
others, but it had some forced changes, I think. I'm not aware of
them all, but there was a change from dynamic to lexical scope, at one
time. And they had to change their fundamental data structure to
accommodate objects with more than 2^16 terms. (Life was simpler when
computers were smaller).
Even so, there are lessons to learn from where the "successful"
systems fail.
Incorporating such lessons in the "social process" of Sage is a
process that, I think, deserves attention.
One technique of low complexity that might clue people in to the kind
of issues that come up:
look at the list of reported bugs for OTHER systems.
I used to keep a list of bugs that were, surprisingly, bugs in all
of Mathematica, Macsyma, and Maple.
RJF
Robert Bradshaw
> On Sep 5, 10:04 pm, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
> <snip>
>
>> My experience is that tail recursion is *very* idiomatic Lisp.
>
> Tell us more about your experience in Lisp.
I first learned Lisp by reading The Little Lisper, which as you
almost certainly know was used for MIT's intro to programming course
up until recently until (gasp) they switched to Python. I had one
other class in undergrad that used Scheme, and other than that have
rarely run into Lisp in the wild (perhaps because I never got into
programming emacs or autocad).
> Recursion is, of course, possible.
> But Common Lisp has a whole pile of iteration constructs, some of
> which I
> illustrated, and most experienced Lisp programmers would use one of
> them
> in this case.
>
> Sometimes Scheme is taught to emphasize recursion because the teacher
> or
> text wishes to make a subtle point, which is that a recursive function
> may
> in fact be implemented by an iterative process. Also Scheme in its
> simplest
> form may be taught without "do loops" -- partly an intellectual
> conceit, in my view.
Well, you reject the "common man off the street" perspective, and now
the "experts who publish papers on computer languages looking down
from their ivory tower" point of view is wrong as well, so it's
unclear what point of view should be taken.
Of course, my experience is no where near that of a Lisp enthusiast's
such as yours, but at least I've been exposed to it (and don't
consider the tiny amount of time I've spent with it a waste at all).
> I wrote other comments about the program in a previous response.
>
>>
>> OK, replace "total" by "x" and of course "AddUpElements" by
>> "DoSomething." I would still argue that each program you've listed
>> above is more obscure (for someone who doesn't know Lisp) than the
>> Python implementation (for someone who doesn't know Python). And most
>> people start out not knowing either.
>
> You could, but see my previous argument.. Do you think DoSomething
> +=i is so clear?
Not as clear, but still reasonable. For anyone who's programmed in C,
Java, or a host of other languages, they would get it by analogy.
If you recall, my random person poll was not about which language was
better, it was about which language was more readable. If I was an
expert wanting to publish a paper on the readability of various
computer programming languages, or the usability of a CAS, a large-
scale poll of the masses would be a very reasonable reasonable thing
to do. And "readability of the language for potential contributors"
is a very relevant criteria to us.
I also think the statement that Lisp is better than Python, or Python
is better than Lisp, is rather meaningless without any sense of
context. I could go and argue that assembly is better than Lisp, and
depending on what I'm doing be very right (or very wrong). That's not
to say there aren't some languages that are good for a wide variety
of things, and others that are pretty much uniformly bad, but there
comes a point when computer language debates become akin to "which
language is better, Icelandic or Sanskrit?"
- Robert
rjf
On Sep 7, 11:30 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:
>
> > On Sep 5, 10:04 pm, Robert Bradshaw <rober...@math.washington.edu>
> > wrote:
> > <snip>
>
> >> My experience is that tail recursion is *very* idiomatic Lisp.
>
> > Tell us more about your experience in Lisp.
>
> I first learned Lisp by reading The Little Lisper, which as you
> almost certainly know was used for MIT's intro to programming course
> up until recently until (gasp) they switched to Python. I had one
> other class in undergrad that used Scheme, and other than that have
> rarely run into Lisp in the wild (perhaps because I never got into
> programming emacs or autocad).
> > Recursion is, of course, possible.
> > But Common Lisp has a whole pile of iteration constructs, some of
> > which I
> > illustrated, and most experienced Lisp programmers would use one of
> > them
> > in this case.
>
> > Sometimes Scheme is taught to emphasize recursion because the teacher
> > or
> > text wishes to make a subtle point, which is that a recursive function
> > may
> > in fact be implemented by an iterative process. Also Scheme in its
> > simplest
> > form may be taught without "do loops" -- partly an intellectual
> > conceit, in my view.
>
> Well, you reject the "common man off the street" perspective, and now
> the "experts who publish papers on computer languages looking down
> from their ivory tower" point of view is wrong as well, so it's
> unclear what point of view should be taken.
written as a recursion is at least as worthwhile as, say, teaching
them about epsilon-delta proofs, or the fundamental theorem of
calculus. The use of Scheme at Berkeley for intro courses (and,
actually, the rejection of Java for similar courses) suggests to me
that students can learn Lisp fairly easily. They don't become experts
at it, though they may, in the middle of the course write programs to
do symbolic differentiation, polynomial multiplication and division,
and an implementation of unification. If you are calling this the
'ivory tower' perspective, then I think that's pretty good. There are
more appropriate books to read if you want to learn enough about Lisp
to compare it to Python. Several books by Paul Graham, and a newer
book, Practical Common Lisp, is online at
http://www.gigamonkeys.com/book/ which some people praise.
I prefer Peter Norvig's book, Paradigms of Artificial Intelligence
Programming,
but that's not free.
>
> Of course, my experience is no where near that of a Lisp enthusiast's
> such as yours, but at least I've been exposed to it (and don't
> consider the tiny amount of time I've spent with it a waste at all).
you don't have much experience.
It is also possible to miss the experience by taking a program you've
already written in some language
like Pascal or Basic, and translate it line by line into Lisp. That
doesn't make for a very good experience.
>
> > I wrote other comments about the program in a previous response.
>
> >> OK, replace "total" by "x" and of course "AddUpElements" by
> >> "DoSomething." I would still argue that each program you've listed
> >> above is more obscure (for someone who doesn't know Lisp) than the
> >> Python implementation (for someone who doesn't know Python). And most
> >> people start out not knowing either.
>
> > You could, but see my previous argument.. Do you think DoSomething
> > +=i is so clear?
>
> Not as clear, but still reasonable. For anyone who's programmed in C,
> Java, or a host of other languages, they would get it by analogy.
would be -- what -- undecipherable?
There is, by the way, a += like operation in common lisp. (setf
total (+ total i)) can be written (incf total i)
> > positions is somewhat hazardous.
>
> If you recall, my random person poll was not about which language was
> better, it was about which language was more readable.
> If I was an
> expert wanting to publish a paper on the readability of various
> computer programming languages, or the usability of a CAS, a large-
> scale poll of the masses would be a very reasonable reasonable thing
> to do. And "readability of the language for potential contributors"
> is a very relevant criteria to us.
scale testing, you would have to come up with some questions. So far
I've seen only one question, and that question involves displaying an
extremely simple python program that uses almost no features of
python, and a substantially non-idiomatic but also extremely simple
lisp program.
No construction or accessing of components, methods, dictionaries,
etc.
This is somehow supposed to have some bearing on what a programmer
would enjoy reading.
Seems to me that comparisons are useful, e.g. Norvig's web site. But
I think this poll idea is not useful.
..............
You have not shown any CAS user examples for your poll, so let me
provide one. but here's a pair
p:=(x+1)*(x-1);
expand(p); /// this, or something quite close, works for
Maxima, Axiom, Maple, Mathematica, Reduce, etc.
vs
R.<x> # is this necessary??
var('x') #/ why are apostrophes needed?
p=(x+1)*(x-1) # note that this is NOT an equation, but an
assignment. Too bad if you are just a mathematician and confused.
p.expand().show(); # huh what's with the dots and the () ?
>
> I also think the statement that Lisp is better than Python, or Python
> is better than Lisp, is rather meaningless without any sense of
> context.
better for something else.
>I could go and argue that assembly is better than Lisp, and
> depending on what I'm doing be very right (or very wrong).
registers and memory in a carefully controlled pattern so as to
optimize the sequence of parallel or pipelined operations.
> That's not
> to say there aren't some languages that are good for a wide variety
> of things, and others that are pretty much uniformly bad, but there
> comes a point when computer language debates become akin to "which
> language is better, Icelandic or Sanskrit?"
and Sanskrit.
To say that they are either "equally obscure to you" or "not worth
examining" is
unfair to them. A poor analogy.
RJF
William Stein
Or in the real life version of Sage (instead of your imaginary version of Sage):
flat:~ wstein$ sage
----------------------------------------------------------------------
| Sage Version 4.1.1, Release Date: 2009-08-14 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
Loading Sage library. Current Mercurial branch is: heegner
sage: p = (x+1)*(x-1)
sage: expand(p)
x^2 - 1
-- William
Robert Bradshaw
> On Sep 7, 11:30 am, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> On Sep 6, 2009, at 9:06 AM, rjf wrote:
>>
>>> On Sep 5, 10:04 pm, Robert Bradshaw <rober...@math.washington.edu>
>>> wrote:
>>> <snip>
>>
>>>> My experience is that tail recursion is *very* idiomatic Lisp.
>>
>>> Tell us more about your experience in Lisp.
>>
>> I first learned Lisp by reading The Little Lisper, which as you
>> almost certainly know was used for MIT's intro to programming course
>> up until recently until (gasp) they switched to Python. I had one
>> other class in undergrad that used Scheme, and other than that have
>> rarely run into Lisp in the wild (perhaps because I never got into
>> programming emacs or autocad).
>
> So I gather that you've never written a serious program in Lisp.
[...]
>
>>
>> Of course, my experience is no where near that of a Lisp enthusiast's
>> such as yours, but at least I've been exposed to it (and don't
>> consider the tiny amount of time I've spent with it a waste at all).
>
> As I said, if you have not written a program of at least modest size,
> you don't have much experience.
I'm *not* claiming much experience at all--probably more experience
then the average math grad student, and rather less than (I hope) the
average CS grad student.
> It is also possible to miss the experience by taking a program you've
> already written in some language
> like Pascal or Basic, and translate it line by line into Lisp. That
> doesn't make for a very good experience.
I totally agree, that would rather miss the point.
>> That's not
>> to say there aren't some languages that are good for a wide variety
>> of things, and others that are pretty much uniformly bad, but there
>> comes a point when computer language debates become akin to "which
>> language is better, Icelandic or Sanskrit?"
>
> I am sure that there are relevant comparison points between Icelandic
> and Sanskrit.
>
> To say that they are either "equally obscure to you" or "not worth
> examining" is unfair to them.
I never said that--I picked those particular languages because,
although I speak neither, I think they're both really cool. (No, I
don't have a Ph.D. in linguistics, but did major in that field as an
undergrad).
> A poor analogy.
OK, I guess a better analogy would be French and English--as this is
sage-flame I'm allowed choose emotionally charged examples which
would make it an even better analogy. (As crazy as it seems, I've
heard people try to argue that one or the other is clearly inferior.)
- Robert
rjf
On Sep 7, 3:20 pm, William Stein <wst...@gmail.com> wrote:
>
> > vs
> > R.<x> # is this necessary??
> > var('x') #/ why are apostrophes needed?
> > p=(x+1)*(x-1) # note that this is NOT an equation, but an
> > assignment. Too bad if you are just a mathematician and confused.
>
> > p.expand().show(); # huh what's with the dots and the () ?
>
> Or in the real life version of Sage (instead of your imaginary version of Sage):
>
> flat:~ wstein$ sage
> ----------------------------------------------------------------------
> | Sage Version 4.1.1, Release Date: 2009-08-14 |
> | Type notebook() for the GUI, and license() for information. |
> ----------------------------------------------------------------------
> Loading Sage library. Current Mercurial branch is: heegner
> sage: p = (x+1)*(x-1)
> sage:expand(p)
> x^2 - 1
I was basing my example on http://demo.sagenb.org/home/pub/1/
... clip follows....
Expanding Expressions
To expand a symbolic expression with exponents, use the expand method.
var('x,y')
f = (x+2*y)^3
f
f.expand().show() # tip -- using show makes the
output nicer
...end of clip....
If this is not accurate, what's going on? Did my browser lie to me?
(Mozilla Firefox 3.5.2)
Is Sage not supporting this browser?
Or perhaps reading the documentation online requires that Sage be
loaded? Or the
Sage notebook? There seems to be something about jsmath in the page
corner. But some of
the other tutorials look just fine.
Or is it the case that the notebook or GUI has the simple language
you show, but the REAL language, the one that is, oh,
just like Python so everyone knows it and isn't it great that we have
solved the problem of the language for computer algebra and guess
what, the answer is Python .... is the slightly uncomfortable
concoction that I found?
Just curious.
Of course, if Sage looks just like Macsyma, Maple, etc., then it is
neither better nor worse for the user. Or the "random" person off the
street, who is presumed to be some kind of mathematics buff. (OK with
me, I guess. The thread here
was comparing lisp to python, and the command language you show is
neither. )
William Stein
You might enjoy reading this blog post:
http://amca01.wordpress.com/2009/09/08/the-digital-signature-algorithm-in-maxima-and-sage/
It discusses implementing an algorithm using both Maxima and Sage.
You might find the comparisons interesting.
-- William
rjf
On Sep 8, 12:28 am, William Stein <wst...@gmail.com> wrote:
> 2009/9/7 rjf <fate...@gmail.com>:
>
>
>
>
> > On Sep 7, 3:20 pm, William Stein <wst...@gmail.com> wrote:
>
> >> > vs
> >> > R.<x> # is this necessary??
> >> > var('x') #/ why are apostrophes needed?
> >> > p=(x+1)*(x-1) # note that this is NOT an equation, but an
> >> > assignment. Too bad if you are just a mathematician and confused.
>
> >> > p.expand().show(); # huh what's with the dots and the () ?
>
> >> Or in the real life version of Sage (instead of your imaginary version of Sage):
>
> >> flat:~ wstein$ sage
> >> ----------------------------------------------------------------------
> >> | Sage Version 4.1.1, Release Date: 2009-08-14 |
> >> | Type notebook() for the GUI, and license() for information. |
> >> ----------------------------------------------------------------------
> >> Loading Sage library. Current Mercurial branch is: heegner
> >> sage: p = (x+1)*(x-1)
> >> sage:expand(p)
> >> x^2 - 1
>
> > ....
> > ... clip follows....
>
> > Expanding Expressions
>
> It discusses implementing an algorithm using both Maxima and Sage.
> You might find the comparisons interesting.
for the computation.
Maybe 80-digit numbers are just so easy to factor that you don't need
much more than
a Lisp program. Almost none of Maxima is used, and the example
program could be
written in Lisp. I think 3 programs would be needed, integer
factoring, power_mod, and inv_mod.
Some people would argue that such a suite of programs would be hard to
read, though.
Anyway...
Here is the note that I wrote to that blog:
.......................
If you use the rational function package in Maxima, your programs will
be shorter. Instead of
power_mod(a,b,p)
you could do this:
modulus:p,
a:rat(b),
and then a^b will do the job. And inverse_mod would be 1/a or a^
(-1).
The representatives of the field used by this setup are balanced
around zero -- does that matter? E.g. mod 5 you have numbers -2 -1
0 1 2, not 0 1 2 3 4.
Your blog was pointed out to me as an example of a Sage vs Maxima
comparison, because it shows Sage commands to be easier to read.
Maxima commands can be shortened using the rational function
representation.
.......................
While the use of types and overloading etc etc can provide some
neater code sometimes, if your types and overloading are simply to
support modular arithmetic, this happens to be included in Maxima
already. If you use Sage to define something more exotic (say
operations in a lattice, or group, or who-knows-what) then if Sage has
a neat way of doing this, it might truly be nicer than Maxima, syntax-
wise. Axiom pushes the CAS design more in this direction, so the
comparison to Axiom might be more illuminating than a comparison with
Maxima.
It is possible to define exotic kinds of manipulations in Maxima, but
it is relatively hard to overload + and *. It can be done
via tellsimp, but is tricky to do right.
You have not responded to my question about the "slightly
uncomfortable concoction" I listed. Is that Sage or not?
The document author seems to have been wstein, which I am guessing is
you.
RJF
Tom Boothby
the output nicer". It doesn't say, "to print out a polynomial f, you
must use f.expand().show()". One can continue your argument to make
this particular example arbitrarily ugly:
f.expand().full_simplify().expand().rational_simplify().trig_simplify().expand().show()
> Did my browser lie to me?
> (Mozilla Firefox 3.5.2)
> Is Sage not supporting this browser?
> Or perhaps reading the documentation online requires that Sage be
> loaded? Or the
> Sage notebook? There seems to be something about jsmath in the page
> corner. But some of
> the other tutorials look just fine.
f = (x+1)*(x+1)
f.expand()
works so many CAS except Sage has clearly failed, and you've resorted
to the tried-and-true "ZOMG, I'm an old man and my browser is confused
in the internets zone. It must be that because I can't have possibly
misunderstood the documentation because the only correct perspective
is mine own." Nice try, but you still fail.
rjf
On Sep 8, 10:05 am, Tom Boothby <tomas.boot...@gmail.com> wrote:
<snip>
So is it
f.expand()
That's just like mathematical notation. Not.
I think that expand(f) is more like mathematical notation.
Now if Sage doesn't care if you do
expand(f)
or
f.expand()
That's fine with me. But I didn't make up f.expand().show() .
Someone named "wstein" did.
I've got to get a better hobby.
Tom Boothby
>
>
>
> On Sep 8, 10:05 am, Tom Boothby <tomas.boot...@gmail.com> wrote:
> <snip>
>
> So is it
>
> f.expand()
>
> That's just like mathematical notation. Not.
>
> I think that expand(f) is more like mathematical notation.
>
> Now if Sage doesn't care if you do
>
> expand(f)
> or
> f.expand()
>
> That's fine with me.
> But I didn't make up f.expand().show() .
> Someone named "wstein" did.
>
> I've got to get a better hobby.
right... writing code.
>
>
>
>
> >
>
Ondrej Certik
Why don't you like wstein? I don't understand that.
Ondrej
Tom Boothby
doesn't seem to know much about Sage.
>
> Ondrej
>
> >
>
Pierre
> Now if Sage doesn't care if you do
>
> expand(f)
> or
> f.expand()
how object-oriented stuff is handled, and that's also why the first
argument in an object's method is usually called 'self'. Writing def
my_method(self, a, b, etc) within a class definition basically defines
a global function (well of course i'm over-simplifying here!! there
are also some namespace-related tricks), and when python sees
foo.my_method(a, b, etc) it calls my_method(foo, a, b, etc).
nothing specific to sage.
Harald Schilly
> well of course i'm over-simplifying here!!
In [1]: class A:
...: def f(self, x):
...: self.x = x
...:
...:
In [2]: a = A()
In [3]: a.f(123)
In [4]: a.x
Out[4]: 123
In [5]: A.f(a, 456)
In [6]: a.x
Out[6]: 456
# global f is now the same as A.f (methods are objects)
In [7]: f = A.f
In [8]: f(a, 789)
In [9]: a.x
Out[9]: 789
Pierre
my_method(self, a, b, etc) with the definition of my_class adds the
global function my_class.my_method(self, a, b, etc), and it may be
called with self= foo by foo.my_method(a, b, etc) if foo is of class
my_class.
so in the original example one can choose to write show(expand( f ) )
or show( f.expand() ) or expand( f ).show() ...
i've always found it surprisingly simple the way python does objects !
PS just realized this afternoon that trace(M) does not work in sage,
while M.trace() does! that's a definite bug isn't it ? (M being a
matrix)
Nils Bruin
> On Sep 9, 3:37 pm, Pierre <pierre.guil...@gmail.com> wrote:
>
> > well of course i'm over-simplifying here!!
> In [7]: f = A.f
Method calls are also used for dispatch:
<Pynac object>.expand() and <maxima wrapper object>.expand() probably
make incompatible assumptions about the implementation of the "self"
they get passed. There is a price you pay for object oriented
programming. A slightly better way for making "expand" available:
def expand(object):
return object.expand()
I am sure CLOS has exactly the same issue because it is a property of
the data model, not of the implementation language. I am also pretty
sure Maxima doesn't because it started out before CLOS was invented.
rjf
On Sep 9, 9:09 am, Nils Bruin <bruin.n...@gmail.com> wrote:
> On Sep 9, 8:05 am, Harald Schilly <harald.schi...@gmail.com> wrote:
>
> > On Sep 9, 3:37 pm, Pierre <pierre.guil...@gmail.com> wrote:
>
> > > well of course i'm over-simplifying here!!
> > # global f is now the same as A.f (methods are objects)
> > In [7]: f = A.f
>
> While this trick technically works, you lose polymorphism this way.
> Method calls are also used for dispatch:
> <Pynac object>.expand() and <maxima wrapper object>.expand() probably
> make incompatible assumptions about the implementation of the "self"
> they get passed.
with C++, C#, and other OO languages like Smalltalk, Self, and the
Common Lisp Object System [CLOS], etc.)
so some of what was said recently is perfectly understandable by me.
But not all is clear.
I do not know what <maxima wrapper object> is.
I expect that the assumptions made by <maxima wrapper object>.expand()
are
that self is a legitimate Sage object that is converted to a
legitimate
Maxima object -- however that is expressed, perhaps as a character
string or
some other data object. The "expand" program makes no assumptions
about what it is passed
in Maxima, other than it is a Maxima object.
>There is a price you pay for object oriented
> programming.
at compile time
there is potentially zero run-time inefficiency. A method dispatch is
no more
than a subroutine call. Even if the method cannot be resolved, it may
be quite fast,
e.g. an indirect jump to a subroutine call, where changes to methods
are
implemented by changing that branch.
>A slightly better way for making "expand" available:
>
> def expand(object):
> return object.expand()
>
> I am sure CLOS has exactly the same issue because it is a property of
> the data model, not of the implementation language.
(expand object).
It does not have syntax object.expand() so there is no need to re-
formulate anything.
What (expand object) in Lisp would be, if expand is a method... is
something roughly like this
(apply the "expand" method associated with the class of object to the
object).
if expand is just an ordinary function, it would be
(apply the "expand" function to the object)
The association of methods to classes can involve computations
involving inheritance, for example.
These associations can sometimes be computed at compile-time, or they
can be computed at
the first time the procedure is used (an idea that has been around in
lisp implementations for decades
but has been recently named and marketed as "Just In Time" compiling).
Sorry I don't see the connection to CLOS...
>I am also pretty
> sure Maxima doesn't because it started out before CLOS was invented.
element of object-orientation that
pervades the Maxima evaluator and simplifier, as well as a number of
other components.
Example: (This is not Lisp, so you should be able to read it :)
define simplify(X) ...
if X is an atomic symbol or number then it is simplified. Return
X.
since X is a compound object, it has a head H, which could be
something like +, *, cosine, besselj, F
X also has arguments, e.g. in cos(3*pi), the argument would be
3*pi.
Simplify, recursively, all the arguments of X. Call the list of
simplified arguments A.
Look up (on the "property list" of H), the simplifier method S for
objects of with head H.
return the result of invocation of the method S on A.
Efficiency hacks and messy little details change it from this outline
in various ways.
Changing the method for a given head H is done by commands like
tellsimp, which
do not alter the simplifier code at all.
Now this is not full-blown OO as in CLOS. I would call it data-
directed programming.
But it has been in Maxima from the very beginning. Indeed, it was
used in 1963 by
Knut Korsvold, who wrote the initial version of the simplifier in Lisp
1.5, and whose
Norwegian? variable names persist in a few parts of the Maxima
simplifier code.
There are problems associated with this kind of local organization of
a simplifier that require some sort of global view to be effective,
and I expect that any tree traversal version of a simplifier would
probably share these problems.
RJF
William Stein
>
>
>
> On Sep 9, 9:09 am, Nils Bruin <bruin.n...@gmail.com> wrote:
>> On Sep 9, 8:05 am, Harald Schilly <harald.schi...@gmail.com> wrote:
>>
>> > On Sep 9, 3:37 pm, Pierre <pierre.guil...@gmail.com> wrote:
>>
>> > > well of course i'm over-simplifying here!!
>> > # global f is now the same as A.f (methods are objects)
>> > In [7]: f = A.f
>>
>> While this trick technically works, you lose polymorphism this way.
>> Method calls are also used for dispatch:
>> <Pynac object>.expand() and <maxima wrapper object>.expand() probably
>> make incompatible assumptions about the implementation of the "self"
>> they get passed.
>
> Well, I know a little about Python itself (and maybe more by analogy
> with C++, C#, and other OO languages like Smalltalk, Self, and the
> Common Lisp Object System [CLOS], etc.)
> so some of what was said recently is perfectly understandable by me.
> But not all is clear.
>
> I do not know what <maxima wrapper object> is.
> I expect that the assumptions made by <maxima wrapper object>.expand()
> are
> that self is a legitimate Sage object that is converted to a
> legitimate
> Maxima object --
That is *definitely* not a valid assumption.
<maxima wrapper object> is just a Ptyhon class with two attributes:
(1) a pointer to a Maxima session
(2) the name of a variable in that session.
That's it. There's no character string. It can point to absolutely
anything Maxima can represent.
> however that is expressed, perhaps as a character
> string or
> some other data object. The "expand" program makes no assumptions
> about what it is passed
> in Maxima, other than it is a Maxima object.
>
>
>
>
>>There is a price you pay for object oriented
>> programming.
>
> If you are referring to efficiency, [...]
I think he wasn't...
William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
rjf
On Sep 9, 10:26 am, William Stein <wst...@gmail.com> wrote:
snip..
> >>There is a price you pay for object oriented
> >> programming.
>
> > If you are referring to efficiency, [...]
>
> I think he wasn't...
not make sense to the man on the street?
This thread is getting too long.
groups.google takes too long to run to the end.
Some questions will, apparently, be left hanging.
Bye.
Tom Boothby
>
> Bye.
>
>
>
>
> >
>
William Stein
William
>
> Bye.
rjf
date, in a column on the left.
So the length of the thread is no longer an issue -- I don't have to
wade to the end!
I can just click on the last item or so.
So why respond? Because my browser is Firefox, which is written in C/C
++, I gather.
The delay was getting all that text from Google, including the full
text of so many repeated messages which the authors did not snip out,
as I try to do.
So don't you can't blame Lisp.
There are browsers written in Lisp, but that's not something covered
by the ANSI standard, so different implementations do it different
ways. There are web servers written in Lisp; I've written one myself
using one set of the excellent tools available (free).
Since someone said "there is a price to be paid for objected oriented
programming"
and wstein says that it is not efficiency, can I conclude that you are
too embarrassed to say what that price might be?
Yet another enduring flame that no one can quench..
RJF
On Sep 9, 11:13 am, William Stein <wst...@gmail.com> wrote:
Robert Bradshaw
> So I gather that you've never written a serious program in Lisp.
However I have, almost certainly, written more Lisp more than you've
written Python.
- Robert
rjf
On Sep 9, 5:55 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
other
direction before noon today. If I cared.
William Stein
> On Sep 6, 9:49 am, William Stein <wst...@gmail.com> wrote:
>> On Sun, Sep 6, 2009 at 8:38 AM, rjf<fate...@gmail.com> wrote:
>>
>><snip>
>> > I was just speculating on the gcc vs. Microsoft C, which I am guessing
>> > is your problem.
>>
>> The problem is lack of developer effort and time. Little work has
>> gone into making Sage and its components work on Windows, because
>> very, very few people in the potential developer pool for Sage use
>> Windows.
>
> self perpetuating situation, I suspect.
I received an email today from a major open source developer who does
software development on Windows. He says:
"I might add that I am more than a bit miffed with Microsoft right now!
I am not academic but a retired government scientist who
now works closely with many academics across the world on open source
software for Windows. And, not being an academic, I have to purchase
all my software at full retail prices.
I now find that, in order to move my machines from Windows Vista
Ultimate x64 to Windows 7 Ultimate x64, I will have to buy high cost
Windows 7 versions because, in contrast to the Home and Professional
versions of Windows 7, there is no low cost introductory upgrade path
for Ultimate users!
As a private open source developer with no income from what I do, I am
also now finding it excessively costly to keep all my MS development
software up to date.
My apologies for the rant, but if I don't find a way of reducing
these costs, I will have no option but give up what I do on Windows."
This is yet another good description of one of the big underlying
reasons that there is so far no good native port of Sage to Windows...
William