Correcting priority issues in mactex.lisp

Just a comment on the mactex discussion - 

I've read some of R. Fateman's papers involving mathematical 
prettyprinting, and
found them clear and instructive.  The bottom line seems to be that this 
is an area that people
will disagree about.  The standard conventions are occasionally ambiguous, 
and
resolving the ambiguity can become a  matter of taste.  And I agree with 
Dr.
Fateman that the tex output nearly always needs some hand tweaking anyway.
Of course, those tweaks are a matter of taste as well... 

This discussion seems to be about appearances (which people can have 
different
opinions about) and not about mathematical correctness.

I think that this issue cannot  be resolved by the use of flags.
I get mine, and you get yours, ad infinitum -- and someone
actually has to do the programming work to support and document (!!)
them all -- seems unworkable and not likely to happen.   The interaction 
of all
these flags becomes an n^2 problem... 

I've always found mactex to be very easy  to hack for my own purposes,
and my lisp skills are within epsilon of nil.    My current version 
includes
the ability to literally quote, so that arbitrary text can be pushed into 
the
output file.  This allows the entire paper to be written in Maxima.
(A crude version of Knuth's literate programming concept).  If I can do 
it,
anyone on this list can -- and this approach -- hacking mactex to match 
your
own taste -- avoids burdening the group, and keeps clutter out of the 
distributed
code.

The bottom line -- certainly, if obvious errors can be fixed, they should 
be.
The usual mathematical conventions should of course be followed. 
But adding more than (say) a couple of supported flags to tweak
appearance, seems counterproductive to me... 

Steve










Richard Fateman <fateman at cs.berkeley.edu> 
Sent by: maxima-bounces at math.utexas.edu
05/26/2009 02:46 PM

To
Robert Dodier <robert.dodier at gmail.com>, Maxima List 
<maxima at math.utexas.edu>, Yasuaki Honda <yhonda at mac.com>
cc

Subject
Re: [Maxima] Correcting priority issues in mactex.lisp






Robert Dodier wrote: 
On Tue, May 26, 2009 at 10:19 AM, Richard Fateman
<fateman at cs.berkeley.edu> wrote:

 
If we start putting in extra parentheses each time someone claims to be
confused, it may not end here.
 

Sure. That's why it's a good idea to consider each change case-by-case,
as we are doing now.

 
I think that there are principles for display that at play here.  One of 
them is that using mactex for the sole output form ( as in imaxima ?) is 
probably not an adequate solution for interactive display. 
I think this is an imaxima problem, not a mactex problem, as illustrated 
by the Mathematica variations in display.
Time for a flag?  Perhaps something like add_extra_parens:   all    or 
some
   or none {situation now}.
 

Another flag? Ugh.

 
The alternatives seem to be
(a) reach a consensus.  Sometimes this is possible because only one 
person, the one making the change, is the only one with an opinion, and 
everyone else goes along with it. 
(b) fork the project. 
(c) add a flag.
(d) reject the change.
(e) impose the change without a consensus. [e.g. just insert a "bug fix" 
even if it is wrong]
(f) do what Mathematica does and have TraditionalForm, InputForm, 
FullForm, TeXForm  functions.  (there may be more..)
(g) fork mactex for imaxima.

anything else?
 All things considered, (c) and (g) seem most plausible.
Imposing full disambiguity on every use of mactex is going to result in 
lots of parentheses, most of which interfere with the most-compact 
conventional display.  By the way, looking at old integral tables, there 
are several conventions on display that have faded from common practice, 
but as I recall, in the table by Bierens de Haan there are two 
multiplication operators (at least). One is adjacency as in x y  and 
another is \centerdot.   They have different precedences.  Do we want 
that, too?  We could also campaign for different parentheses, e.g. {} [] 
to be used in display. I think that is potentially very very helpful.

I suggest that imaxima do as many of these things as the authors of 
imaxima wish.  So perhaps forking mactex is appropriate.

My own experience in taking the output from Macsyma/Maxima 's  mactex and 
putting it in to papers is that it almost always needs some editing by 
hand to get the desired "natural" display.   For example $b+a$ might be 
better as $a+b$. Adding parentheses is not something I recall ever doing.


RJF 


not what I see.    I see  (  sum(a[n]+b[n],n,1,k)    ) + ....
not                               sum(   ( a[n]+b[n]  )  , n,1,k) + ... if
that is clear :)
 

Are you using wxMaxima? I mean the 2-d display in command line Maxima.
What does build_info say?

 
Maxima version: 5.17.0
Maxima build date: 19:8 12/4/2008
host type: i686-pc-mingw32
lisp-implementation-type: GNU Common Lisp (GCL)
lisp-implementation-version: GCL 2.6.8

in wxmaxima, try
'sum(b[n]+a[n],n,1,k)+a[n]$

RJF
_______________________________________________
Maxima mailing list
Maxima at math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima