Thanks for the message about Julia. I am very familiar with R and Maxima,
and it would be great if we could somehow keep the "good stuff" from those
systems while moving to a more consistent, modern framework.
It seems to me that there are four main kinds of challenge:
- Design philosophy. R was designed by statisticians for statisticians.
Maxima was developed (largely) for physicists. The languages' semantic
peculiarities support important user behaviors. The user communities tend
to be very pragmatic, and generally don't seem to care much about computer
scientist language designers' notions of semantic consistency as long as
they can get their work done.
- Both R and Maxima have many extension packages written in their own
languages which depend heavily on the current semantics. How would those
be moved to or interface with to another system?
- Maxima in particular has a lot of global state (assumptions, flag
settings, patterns, etc.) which needs to persist and presumably be shared
across parallel processes. How would that be done?
- Simple inertia. People use R because everyone else in statistics uses
R, there are lots of books and articles on R, there is an active user
community, etc. The Maxima community is much smaller and might be more open
to moving.
In more detail:
- There are many valuable extension packages for R which depend on the
current peculiar R class semantics. I wonder how they could be moved to
another system without actually modifying each package or writing a custom
wrapper for each one?
- One of the things that makes R so handy for statistical manipulation
is the way arguments are passed -- both the unevaluated and the evaluated
form are available to the called function, so (e.g) a plot function can
label axes. Presumably this would be handled in Julia using macros, but
Julia macros have different syntax than normal function calls
(why?). Maxima's
handling of unassigned variables as formal variables is really convenient.
This all makes semantics messy, but users seem to find it handy.
- One of the things that makes the Maxima language convenient and easy
to use is the blurring of the line between formal (mathematical)
expressions and evaluated expressions. I suspect this would be difficult to
support in a language not designed for symbolic algebra. The clean
solution is presumably to use Julia's :x syntax, so you'd write e.g. diff(
:(x^2), :x) instead of diff(x^2, x). Though this makes for much cleaner
and simpler semantics, I don't think our users would appreciate it.
- Julia's current semantics for sqrt(4), sqrt(2), sqrt(-1),
(1+im)/(1-im), etc. aren't acceptable for a symbolic system. sqrt(4)
should be the *integer* 2, not the float 2.0; sqrt(2) should remain as
the formal object sqrt(2) == 2^(1/2); sqrt(-1) and (1+im)/(1-im) should
return 1im (an exact Gaussian integer), and certainly not 0.0+1.0im (or
NaN). Would the user have to explicitly write e.g. sqrt(:2) or and
sqrt(:-1) to force a symbolic result?
- I suspect users will also have more trouble with a Julia-type
treatment of nouns/verbs than with the current Maxima approach -- although
admittedly the current system is confusing, too. The Julia notation would
presumably be :(diff(y,x)) (currently written as 'diff(y,x) : a formal
differential) and diff(:y,:x) (currently written as diff(y,x): evaluates to
0). But actually that isn't quite right, either. In Maxima, you can write
q:sin(x) and then 'diff(q,x) evaluates to 'diff(sin(x),x) -- that is, the
*arguments* are evaluated, though the operator remains formal.
- Arguments about semantic consistency etc. don't seem to impress the R
community -- witness the bizarre and inconsistent treatment of factors in
various parts of the *core *packages (let alone user contributions); or
of lists vs. vectors. Witness the ugly (but handy!) S3 object system, and
the profusion of other object systems (S4, proto, R.oo), none of which
has displaced S3. Over the years, there have been cleaner alternatives
proposed, e.g. (x)Lisp-Stat <http://www.jstatsoft.org/v13/i09>;, but none
have succeeded. Similarly, Maxima, though designed by computer scientists,
was designed for the convenience of its mathematician users. More formally
clean systems like the Scheme-based
Scmutils<http://groups.csail.mit.edu/mac/users/gjs/6946/refman.txt>;
haven't
been as successful. cf. "Worse is
Better<http://www.jwz.org/doc/worse-is-better.html>";.
- How would other kinds of arithmetic objects -- arbitrary-precision
integers (bigfloat), extended-precision floats (bfloat), etc. -- be
integrated into Julia? Would it be possible to have literals for them?
Can overflow of fixed-point integers generate arbitrary-precision numbers?
Is there anything preventing them from being in the right place in the type
hierarchy, e.g. Real <: Bigfloat <: Float ? Can exact numbers like 2^(1/2)
be between Number and Complex?
>From what I've read on the Julia web site, it seems that its biggest
advertised strength is highly optimized numerical compilation and a clean
language. I don't think either of those are big enough advantages to
overcome the challenges above. But I really really *would* like to see
both Maxima and R become cleaner and more consistent. Then again, I'm a
computer scientist, not a statistician or physicist....
-s
PS What is meant in the Julia blurb by "Julia... provides... numerical
accuracy"? Does it do something other than standard IEEE floating-point?
On Sat, Apr 28, 2012 at 09:27, Manuel Pedrinero rossetil <pdx7l1 at yahoo.es>wrote:
> The people of julia language are trying to make a language that can
> replace R and Matlab. Lisp is used to manipulate the AST, there is
> a small Lisp developed by one of the core members of the group (femlisp)
> available in github.
>
> I think that julia could be a good replacement for the maxima language.
> Julia can use LAPLACK and other libraries, and recently
> in the list there has been some talks about CPYTHON developers trying to
> link with julia.
>
> For julia developers adding symbolics capabilities could be very
> interesting.
> For maxima developers, being able to interface with R, C and fortran could
> be also very interesting,
> so I think this is a win-win situation.
>
> Best., gluemath.
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>