On 11/04/14 06:06, Waldek Hebisch wrote:
Martin Baker wrote:
Please could you add this formatter to the next release:
https://github.com/martinbaker/multivector/blob/master/monospace.spad.pamphlet
The documentation is here:
http://www.euclideanspace.com/maths/standards/program/mycode/output/monospace/
(this contains diagrams that I can't put in the pamphlet)
Its just an optional output formatter with the same structure as the
other formatters. This is designed to output to a monospace device such
as the command line console.
Martin, have you tried to run 'src/input/of.input' trough
your formater? When I tried I see a lot of errors.
Sorry for waiting long, but I wanted to have time for
serious tests. Unfortunatly, ATM it is failing the
first test -- 'of.input' contains several constructs,
but only simplest examples of each construct.
I wrote the code in a few days and I did not go on to systematically
test it for all conditions. If I had done so I am reasonably confident
that, by now, it could have been fully working in a reliable way. You
did not seem interested so I did not go on to do so.
I don't know the best thing for me to do? I think that open source
programming should be enjoyable but I don't like working on things that
seem to be competing with what other people are doing and I don't like
reworking low level code when the high level design seems to need
replacing anyway.
I would much rather agree a top level design and that write it properly
once only. But, perhaps you are right, I don't think we will ever agree
on the correct approach to documentation so perhaps we would not agree
on the best design for output formatters either.
The aim of this is to use as the template for more specialist monospace
formatters. It would really help me develop this if you could put it in
the next release.
Well, the tree walkinig part certainly should _not_ be used
as template for other formaters. You use string matching
and ad hoc trick, which lead to errors. Other formaters
(except for Html) were converted to match symbols, that
avoids many problems. Also, decision to put (or not)
parenthesis around a construct should be based on priorities.
The formater responsible for given construct knows
priority of operator (construct) it handles and
is given priority of operator at higher level, so
it has all information needed to make decision about
parenthesis. Trying to do it in other place, like
you do in 'formatBinary' leads to unnecesary complications.
Comparte your formater with TeX of MathML, the logic
to insert parenthesis is much simpler in both of them
(and both use almost the same logic for this).
I based this on the html formatter, I deliberately did not change these
because I thought it better if it had the same structure as the other
formatters (I did not know that you had changed all the other formatters
without changing html).
If the tree structure were changed, as I suggested, then the tree
walking would be much more regular and simple. Also, with all this
duplication of code, it is not surprising that the formatters get out of
step. Perhaps, when you add a common category for the formatters, the
common code could be put in that. Although I think it would be better if
some of the processing were done before it even gets to the individual
formatters. For instance parenthesis logic would be done and then just a
binary flag needs to be passed to the formatter to say if parenthesis
needs to be added (this looks like it may be the way SALLI/Aldor is
intended to work).
Concerning 2D formatting it looks that in your formater
simple matrices work OK,
I have only put a single horizontal space between cells in a matrix
rather that two used be current formatter. I find a more compact matrix
looks better and, in some cases, it avoids overflow onto two lines.
However these details are all very easy to change when written in high
level code.
> but subscripts/superscripts
nested in other constructs cause trouble.
For example:
(exp(x^2/3) + log(1/(x+1)))^10
has problem (this may be because it needs to be split
between lines).
This would be very easy to fix. In addition to the rectangle of
characters there is a need to hold a 'base index' then, when
concatenating horizontally, it would make sure that subscripts are
always below the baseline and superscripts are always above the baseline.
Martin
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
