[dev] a suckless computer algebra system
A.J. Gardner
are ill-formed and mostly ignorant. Does anyone else here have an
interest in this topic, broadly speaking? If so, do you have any
preferences for one package over another? Have you found any math
software that seem to follow the worse-is-better design model?
How is gnuplot? gmp bignum library? Maxima? Sympy? Octave? Ever used
any of these?
I'm too much of a n00b (and I'm still trying to wrap my mind around
what it means for software to suck less) to actually tell if some code
does, in fact, suck less.
tl;dr: Anyone know of any suckless math software out there in the tubes?
Best,
A.J.
Joseph Xu
> I'm interested in math and CASs, but my opinions on available software
> are ill-formed and mostly ignorant. Does anyone else here have an
> interest in this topic, broadly speaking? If so, do you have any
> preferences for one package over another? Have you found any math
> software that seem to follow the worse-is-better design model?
>
> How is gnuplot? gmp bignum library? Maxima? Sympy? Octave? Ever used
> any of these?
You might also want to check out Pari/GP (algebra) and R (statistics). I
understand those are highly respected software packages. I've only used
octave before. Personally I think matlab and hence octave syntax is
really ugly.
Ammar James
Kris Maglione
>are ill-formed and mostly ignorant. Does anyone else here have an
>interest in this topic, broadly speaking? If so, do you have any
>preferences for one package over another? Have you found any math
>software that seem to follow the worse-is-better design model?
Don't be silly. There's nothing like a "suckless" CAS, at least
nothing remotely approaching the simplicity of suckless.org
software. Computer algebra and calculus are complex and
computationally intensive. They can't (and arguably shouldn't)
be simplified beyond a point.
>How is gnuplot? gmp bignum library? Maxima? Sympy? Octave? Ever used
>any of these?
Maxima is pretty much the gold standard among open source CASs.
Sage is a bit more featureful in some areas, but it's a
ridiculously huge, self-contained distro including an entire
Python runtime, and it pretty much requires that you use the web
interface to do anything useful. Sympy is the basis of Sage, and
it works, but it's a bit slow and lacks a few features.
gnuplot is not a CAS, it's a plotting system. It's generally
pretty god awful, but it's usable with Maxima as a frontend. gmp
is just what you've labeled it as: a bignum library. It handles
arbitrary precision arithmetic, not algebra.
Scipy and Numpy are useful for certain CAS features, and will at
the least replace Matlab (which really isn't that useful,
anyway). The TI and HP calculators have decent CASs, too, if
you don't need anything too fancy. I know that there are a few
other simple CASs laying around, but they're generally pretty
weak, and probably won't do what you want them to (for pretty
much any realistic value of 'what you want them to').
There are also some nice libs in Haskell, which have the benefit
that Haskell is pretty much tailor made for mathematics, but I
really can't speak to their full-featuredness.
Use Maxima, try Sage, but if you want suckless, prepare to be
disappointed by the latter.
>I'm too much of a n00b (and I'm still trying to wrap my mind around
>what it means for software to suck less) to actually tell if some code
>does, in fact, suck less.
Maxima's code is more or less brilliant, but it's Lisp, which is
a completely different world.
--
Kris Maglione
Organizations which design systems are constrained to produce designs
which are copies of the communication structures of these
organizations. (For example, if you have four groups working on a
compiler, you’ll get a 4-pass compiler)
--Conway’s Law
Alex Ghitza
> Don't be silly. There's nothing like a "suckless" CAS, at least
> nothing remotely approaching the simplicity of suckless.org
> software. Computer algebra and calculus are complex and
> computationally intensive. They can't (and arguably shouldn't) be
> simplified beyond a point.
>
I tend to agree with this.
>
> Maxima is pretty much the gold standard among open source CASs. Sage
> is a bit more featureful in some areas, but it's a ridiculously
> huge, self-contained distro including an entire Python runtime, and
> it pretty much requires that you use the web interface to do
> anything useful. Sympy is the basis of Sage, and it works, but it's
> a bit slow and lacks a few features.
>
Sage is indeed ridiculously huge and will probably get bigger as
libraries from other areas of mathematics get added.
However, it is simply not true that it "requires you to use the web
interface to do anything useful". I have been using Sage extensively
for teaching and research for the past two years and I spend 95% of my
time in the command-line interface. I only use the Sage notebook
(i.e. the web interface) when I need to use graphics in a class, or
during talks (most students, but also a lot of mathematicians seem to
get a blank stare when they look at the command line).
>
> Use Maxima, try Sage, but if you want suckless, prepare to be
> disappointed by the latter.
Again, I agree that Sage is nowhere near suckless. And it still lacks
many features that people want, although it's still a fairly young
project insofar as CAS's go (5 years), so I'm certain that lots of new
features will be added.
In the end, it depends on what you want to do with your CAS. If you
want something very precise, there is good specialised software around
(Pari was already mentioned for number theory, GAP is the way to go
for group theory, Macaulay2 for algebraic geometry, Singular for
commutative algebra, mpmath for special functions, R for statistics,
etc.)
Best,
Alex
--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/
Christoph Dibak
> However, it is simply not true that it "requires you to use the web
> interface to do anything useful". I have been using Sage extensively
> for teaching and research for the past two years and I spend 95% of my
> time in the command-line interface. I only use the Sage notebook
> (i.e. the web interface) when I need to use graphics in a class, or
> during talks (most students, but also a lot of mathematicians seem to
> get a blank stare when they look at the command line).
Seems like I should have a look at sage. Im useing octave for simple
algebra computation and gnuplot for plotting. Gnuplot is realy nice and
octave has the benefit that you dont have to open a graphical interface
(like with matlab) to get e.g. the rank of a matrix.
But is there a sort of replacement for maple? Does any less-sucking or
open-source software support the maple-worksheet (.mw) format?
Kris Maglione
>But is there a sort of replacement for maple? Does any less-sucking or
>open-source software support the maple-worksheet (.mw) format?
Don't Maple worksheets, by definition, suck more? At least,
that's my impression of anything based on a Java UI (with an
admittedly nice lispy core). The Sage notebook is meant as a
replacement for a Maple-ish UI, and there's always wxMaxima
along with the TeXmacs and emacs frontends to Maxima. I
occasionally use TeXmacs or wxMaxima, but not in any way
resembling a Maple worksheet.
--
Kris Maglione
It is best to read the weather forecast before praying for rain.
--Mark Twain
Szabolcs Nagy
On 11/20/09, Alex Ghitza <agh...@gmail.com> wrote:
> In the end, it depends on what you want to do with your CAS. If you
> want something very precise, there is good specialised software around
> (Pari was already mentioned for number theory, GAP is the way to go
> for group theory, Macaulay2 for algebraic geometry, Singular for
> commutative algebra, mpmath for special functions, R for statistics,
> etc.)
+1 for pari/gp and gap system
R and octave are for numerical calculations (float64) so i would not
call them cas
they tend to use lots of other libs
optimization: lpsolve, glpk, cvxopt, sedumi
computational geometry: qhull, cgal
..
David Tweed
> On Thu, Nov 19, 2009 at 02:23:35PM -0600, A.J. Gardner wrote:
>>
>> I'm interested in math and CASs, but my opinions on available software
>> are ill-formed and mostly ignorant. Does anyone else here have an
>> interest in this topic, broadly speaking? If so, do you have any
>> preferences for one package over another? Have you found any math
>> software that seem to follow the worse-is-better design model?
>
> Don't be silly. There's nothing like a "suckless" CAS, at least nothing
> remotely approaching the simplicity of suckless.org software. Computer
> algebra and calculus are complex and computationally intensive. They can't
> (and arguably shouldn't) be simplified beyond a point.
There's a related issue: often the task you want to perform inherently
has too high a computational complexity as "generic problem" (at least
the complexity is too high if you're working on problems that tend to
come up), so you either want multiple different algorithms (or
different systems) which employ approaches which might be have
different problems they solve quickly. (For instance, the Fermat
system (http://home.bway.net/lewis/) uses an algorithm that's not used
by other CAS for some polynomial manipulations, and apparently
succeeds on some problems they out-of-memory on, whilst failing on
problems that others can solve. So if you only care about acheiving
your mathematical task and not on only using "aesthetically righteous
software" you might well try both systems.). Contast this with, eg, a
typesetting system where you can have one "best" algorithm that does
everything.
I have a lot of sympathy with you on the UI front: I dislike intensely
the "programmer personal" GUI choices each CAS I've used seems to make
and in an ideal world there would be a common GUI (and syntax would be
modified for consistency where the system's semantic representation
makes it possible). But I don't think anyone (me included) actually
wants to do the work to do that.
Incidentally, one system I haven't seen mentioned so far is axiom
http://www.axiom-developer.org/
Not compellingly brilliant but not bad either.
--
cheers, dave tweed__________________________
computer vision reasearcher: david...@gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
Jukka Ruohonen
As for algebra, the king of the hill is without doubt LAPACK. But since
Fortran is nowadays seldom used, few people can tell if it "sucks in the
sense of suckless" (?). But it is still the fastest language in it's own
area; this may or may not be important.
As others have said, Maxima is a good choice for a CAS. Unfortunately the
commercial alternatives are quite far ahead in many things, albeit these
might "suck more". R is really good for statistics; a good amount of serious
research is carried out with it. It is also my personal favourite. If you
are into Python, Numpy and Scipy are relatively good. Sage is a kitchen sink
and definitely "sucks".
Finally, something that has not been mentioned yet. As much as I despise the
use of GPL (with libraries...), I have to admit that GSL is quite "suckless"
(i.e. clean, well-designed, and relatively simple) general purpose math
library written in plain C. I could even say that it "sucks less", at least
when compared to ever-so many C++ libraries in the field.
- Juka.
David Tweed
> On Thu, Nov 19, 2009 at 02:23:35PM -0600, A.J. Gardner wrote:
>> Anyone know of any suckless math software out there in the tubes?
>
> As for algebra, the king of the hill is without doubt LAPACK. But since
> Fortran is nowadays seldom used, few people can tell if it "sucks in the
> sense of suckless" (?). But it is still the fastest language in it's own
> area; this may or may not be important.
FWIW, my understanding is that the LAPACK library must have an API
which conforms with a reference Fortran implementation, but there are
various versions implemented in various languages (Fortran, C, CUDA,
etc).
As for the code "quality", I can see the code driving certain people
on this list mad because it deliberately doesn't compute things in the
simplest way and fewest lines in order to do things like acheive close
to optimal cache blocking on modern multicore machines. A comparison
of how much performance can vary depending on how it's coded can be
glimpsed in the graphs in this paper:
Jukka Ruohonen
> FWIW, my understanding is that the LAPACK library must have an API
> which conforms with a reference Fortran implementation, but there are
> various versions implemented in various languages (Fortran, C, CUDA,
> etc).
This is true. But the LAPACK itself is a stand-alone Fortran library;
typically it is used via things like f2c.
> As for the code "quality", I can see the code driving certain people
> on this list mad because it deliberately doesn't compute things in the
> simplest way and fewest lines in order to do things like acheive close
> to optimal cache blocking on modern multicore machines. A comparison
> of how much performance can vary depending on how it's coded can be
> glimpsed in the graphs in this paper:
This is again true, IMO. I'd say that in the sense of traditional software
engineering, the code quality of numerical software is generally terrible.
But as for validity and reliability of numerical algorithms, the thing that
really matters in this context, LAPACK is again without doubt the most
respected library. In fact, it is intriguing to follow the history of
numerical matrix algebra and the close correspondence of it with the
development of ALGOL, LINPACK, and later LAPACK.
LAPACK is also the backbone in most of the mentioned, open or closed,
software.
- Jukka.
David Tweed
> On Fri, Nov 20, 2009 at 01:53:47PM +0000, David Tweed wrote:
>> FWIW, my understanding is that the LAPACK library must have an API
>> which conforms with a reference Fortran implementation, but there are
>> various versions implemented in various languages (Fortran, C, CUDA,
>> etc).
>
> This is true. But the LAPACK itself is a stand-alone Fortran library;
> typically it is used via things like f2c.
>
>> As for the code "quality", I can see the code driving certain people
>> on this list mad because it deliberately doesn't compute things in the
>> simplest way and fewest lines in order to do things like acheive close
>> to optimal cache blocking on modern multicore machines. A comparison
>> of how much performance can vary depending on how it's coded can be
>> glimpsed in the graphs in this paper:
>
> This is again true, IMO. I'd say that in the sense of traditional software
> engineering, the code quality of numerical software is generally terrible.
I was pointing out more how the simple-minded software metrics would
condemn you to around about the level of performance acheived by the
reference LAPACK (white bars) in the paper referenced, which to my
mind suggests there's a flaw in the software metrics. I'd also query
that the code quality is terrible in most numerical software: what I'd
say is that they've got a task to acheive (ie, using as much of the
computing power as possible) and make the software as simple and
maintainable as it can be given the task. (What they don't generally
do is say "if we reduce what portion of the task we'll implement for
users, we get wonderfully simple code".)
> But as for validity and reliability of numerical algorithms, the thing that
> really matters in this context, LAPACK is again without doubt the most
> respected library. In fact, it is intriguing to follow the history of
> numerical matrix algebra and the close correspondence of it with the
> development of ALGOL, LINPACK, and later LAPACK.
This is probably splitting hairs, but my understanding is that LAPACK
(and BLAS below it) are more "specifications of library functionality
(in the form of a reference implementation)" rather than a single
library. The development history is certainly interesting,
particularly the adapation from old-style computer assumptions (memory
is memory is memory) to taking active steps to optimise for the
multi-level memory hierarchy in modern machines with starting around
the time of Goto-BLAS.
Szabolcs Nagy
> On Thu, Nov 19, 2009 at 02:23:35PM -0600, A.J. Gardner wrote:
>> Anyone know of any suckless math software out there in the tubes?
>
> As for algebra, the king of the hill is without doubt LAPACK. But since
LAPACK is about floating point computations, it has nothing to do with algebra
numerical linear algebra != abstract algebra
(ieee floats aren't even a group: eg Nans have no additive inverse)
Jukka Ruohonen
> I was pointing out more how the simple-minded software metrics would
> condemn you to around about the level of performance acheived by the
> reference LAPACK (white bars) in the paper referenced, which to my
> mind suggests there's a flaw in the software metrics. I'd also query
> that the code quality is terrible in most numerical software: what I'd
> say is that they've got a task to acheive (ie, using as much of the
> computing power as possible) and make the software as simple and
> maintainable as it can be given the task. (What they don't generally
> do is say "if we reduce what portion of the task we'll implement for
> users, we get wonderfully simple code".)
I think there is no misunderstanding here; the "suckless metrics" do not
apply here. But given that this is a suckless list, with the "terrible code
quality" I meant that numerical software is often terrible against
conventional metrics of code quality; cryptic, hard to read and understand,
full of little "hacks", difficult to change and maintain, badly formatted,
etc.
Take the aspects of software quality mentioned in ISO 9126-1:
* Functionality (suitability, accuracy, compliance, security, etc.)
* Reliability (maturity, recoverability, fault tolerance, etc.)
* Usability (learnability, understandability, operability, etc.)
* Efficiency (time and space performance, etc.)
* Maintainability (stability, analyzability, testability, etc.)
* Portability (installability, replaceability, adaptability, etc.)
Against these abstract concepts of general software quality, I'd say that
numerical software is generally par excellence in some aspects, but terrible
in others.
- Jukka.
David Tweed
I think it's just a difference in when we'd use words like terrible.
It sounds like if code is difficult to read on some absolute scale
you'd call that terrible but say that it's justified in being terrible
in order to acheive efficiency. I'd rate difficulty of reading
relative to other ways of acheiving _exactly the same_ programming
goal (including efficiency level targets), so if there's not a simpler
way of programming it I'd rate that as having good readability. (Of
course, if there is a simpler way of coding to acheive the exact goal
then it has poor readability.) Likewise, portability is relative to
the goal: if the goal is to extract as much performance from the
particular processor the code is running on, then portability implies
different things than a portable implementation of "wc", etc, etc.
It's a difference in when we would use particular terms rather than a
real difference.
The other thing is that the only code I've looked at in depth is ATLAS
and Goto-BLAS, which both seem quite readable given their targets.
Mayber there's a corpus of much worse numerical code I just haven't
seen.
(In case it confused people, the comment in my original mail about
sending some people on this list mad was more a comment on those
people's software values than a criticism of numerical code.)
Jukka Ruohonen
> I think it's just a difference in when we'd use words like terrible.
Well, being on a suckless list, I tend to agree with suckless' definitions
of "terrible".
Perhaps all this could be elaborated from a different angle. Most of the
people who write numerical software are respected hardcore academics in
their fields. But most of these people are *not* programmers per se. I
believe this is the general reason for the "sucks more" aspects of numerical
software. Would you agree?
As a personal anecdote: I was reading a good book about numerical
computation the other day. Everything was nicely derived and all that. But
when it came to the C library that the respected professor had developed, I
couldn't but think: this is absolutely terrifying. I mean, the code examples
violated practically every idiom of C; several functions took well over
twenty parameters, numerous libc-functions were severely misused, the type
system was a mess, and so on.
- Jukka.
Kris Maglione
>on this list mad because it deliberately doesn't compute things in the
>simplest way and fewest lines in order to do things like acheive close
>to optimal cache blocking on modern multicore machines. A comparison
>of how much performance can vary depending on how it's coded can be
>glimpsed in the graphs in this paper:
If the programmer can simulate a construct faster than a compiler can
implement the construct itself, then the compiler writer has blown it
badly.
--Guy Steele
--
Kris Maglione
The object-oriented model makes it easy to build up programs by
accretion. What this often means, in practice, is that it provides a
structured way to write spaghetti code.
--Paul Graham
A.J. Gardner
> computation the other day. Everything was nicely derived and all that. But
> when it came to the C library that the respected professor had developed, I
> couldn't but think: this is absolutely terrifying. I mean, the code examples
> violated practically every idiom of C; several functions took well over
> twenty parameters, numerous libc-functions were severely misused, the type
> system was a mess, and so on.
>
> - Jukka.
Do you remember which book?
You've gotten me interested in which aspects of particular software
packages you think are terrible. I'd like to take a look at them to
see if I can learn what *not* to do.
@Kris: What is it about Gnuplot that's generally awful? Plotting and
graphing seem like they'd be less complex than operations like, say,
factorization, integration, or solving systems of DEs; do you think it
would be possible to write a less-sucking plotting package? Any
thoughts on what such an undertaking would involve? I ask because you
mentioned CASs being in a class of software which might not take well
to simplification.
Best,
A.J.
Anselm R Garbe
> On Thu, Nov 19, 2009 at 02:23:35PM -0600, A.J. Gardner wrote:
>>
>> I'm interested in math and CASs, but my opinions on available software
>> are ill-formed and mostly ignorant. Does anyone else here have an
>> interest in this topic, broadly speaking? If so, do you have any
>> preferences for one package over another? Have you found any math
>> software that seem to follow the worse-is-better design model?
>
> Don't be silly. There's nothing like a "suckless" CAS, at least nothing
> remotely approaching the simplicity of suckless.org software. Computer
> algebra and calculus are complex and computationally intensive. They can't
> (and arguably shouldn't) be simplified beyond a point.
Why not? I think it should be possible to have very minimalist and
specialized CAS', they managed to do that in the 50s and 60s, why not
today?
Cheers,
Anselm
Szabolcs Nagy
> Why not? I think it should be possible to have very minimalist and
> specialized CAS', they managed to do that in the 50s and 60s, why not
> today?
>
ah good old reduce
Preben Randhol
Anselm R Garbe <ans...@garbe.us> wrote:
> Why not? I think it should be possible to have very minimalist and
> specialized CAS', they managed to do that in the 50s and 60s, why not
> today?
We are not living in the 50's nor 60's... If the suckless approach is to
not include a feature (read mathematical algorithem in this case)
because the source code gets bigger or more complex, then IMHO
suckless approach is not the correct approach for CAS.
CAS is used to solve a multitude of problems that
you cannot define into a narrow problem space.
Of course you can make x applications that each solve a spesific
mathematical problem, but what a mess it creates when you have to
combine applications. I have work with such systems and the time wasted
in transfering data from one to the other is a big problem. Not to say
the errors this can introduce...
--
Preben Randhol
«Violence is the last refuge of the incompetent.»
- Isaac Asimov
hiro
combined easily by definition.
Ammar James
(probably slow and crappy compared to some huge mainframe) and just
use WolframAlpha's. Check www.wolframalpha.com
Anselm R Garbe
> On Fri, 20 Nov 2009 18:39:04 +0000
> Anselm R Garbe <ans...@garbe.us> wrote:
>
>> Why not? I think it should be possible to have very minimalist and
>> specialized CAS', they managed to do that in the 50s and 60s, why not
>> today?
>
> We are not living in the 50's nor 60's... If the suckless approach is to
Mankind was able to visit the moon based on these very simple systems
at the end of that era, but hasn't ever been since (the modern excuse
is lack of money, but I disagree). I don't think that they did
everything wrong in the past or that most of the past technology has
no value to learn from.
> because the source code gets bigger or more complex, then IMHO
> suckless approach is not the correct approach for CAS.
>
> CAS is used to solve a multitude of problems that
> you cannot define into a narrow problem space.
>
> Of course you can make x applications that each solve a spesific
> mathematical problem, but what a mess it creates when you have to
> combine applications. I have work with such systems and the time wasted
> in transfering data from one to the other is a big problem. Not to say
> the errors this can introduce...
I never said that a suckless CAS' main objective would be LOC. But I'd
say that a suckless CAS would create one program for each specific
mathematical problem and define a uniform interface to combine these
programs using pipes to solve a complex problem. This also has the
advantage that one can easily distribute and scale each of these
programs onto separate cpus or even servers and hence increase the
overall performance. I would say that Go sounds like an interesting
language to start such a project.
Cheers,
Anselm
Yoshi Rokuko
Fernan Bolando
> 2009/11/24 Preben Randhol <ran...@pvv.org>:
>> On Fri, 20 Nov 2009 18:39:04 +0000
>> Anselm R Garbe <ans...@garbe.us> wrote:
>>
>>> Why not? I think it should be possible to have very minimalist and
>>> specialized CAS', they managed to do that in the 50s and 60s, why not
>>> today?
>>
>> We are not living in the 50's nor 60's... If the suckless approach is to
>
> Mankind was able to visit the moon based on these very simple systems
> at the end of that era, but hasn't ever been since (the modern excuse
> is lack of money, but I disagree). I don't think that they did
> everything wrong in the past or that most of the past technology has
> no value to learn from.
>
I think the main problem in going suckless for mathematics software,
is a whole bunch of code
written by some of the most briliant matematicians. Those poeple
however are not always good coders. So you end up with thousands of
fortran code accumulated through the years. Fortran codes that still
works, but nobody understands anymore.
fernan