Martin Baker wrote:
>
> On 11/04/14 06:06, Waldek Hebisch wrote:
> >
> > 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.
Concerning competing: I worked on Fortran output which you did
not want to do. Ralf worked on 'outputTran' which you somewhat
ignored. You wanted change structure of OutputForm. Three
weeks ago substantial change in representation of OutputForm
would break all formatters. Now several formatters access
OutputForm completely via an abstraction layer so in principle
they no longer care how OutputForm is represented. AFAICS
this is complementary to what you wanted to do.
Concerning design: old formater is hard to modify and sometimes
produces ugly output but actual formating errors are rare.
This is critical part of system, so any replacement should
aim at reducing errors. Basic principles (using boxes) are
well-known now. But devil is in details. For example,
formater must have ASCII art for all construct, must calculate
sizes, etc. And there is about 70 constructs to handle.
so there a lot of details which must play well together.
So, reconstructing design of old formater should help
get the details right.
Also, there is question of testing: IME requiering new
formatter to produce exactly the some output as old one
is quite effective at finding problems with new formater
(it may also find problems with old one). Of course,
we may want new formater to produce different output.
But the point is that change should be deliberate.
If new formater from the start produces different output,
than it hard to test: eyeballing thousends lines of output
is not pleasent and it is easy to miss problems. OTOH
once new formater is verfied to produce the same output
as old one (possibly correcting some bugs in old formater)
changes have smaller chance to introduce breakage.
Concerning 'interested': I simply have doubts if your
approach of ignoring details of old formater will
work. Maybe things are realy simple and it will
work. But there is good chance that there are complications
which authors of old formater investigated and can
handle.
Concerning putting formater into new release: I do not
undersand why you insist(ed). I mean, if formater works
fine, then it can go in. But releasing very rough
developement code does not make much sense. You wrote
that this will help you develop it. But you found
good workaround, and anyway rebuilding FriCAS from
sources is not that hard, a lot of folks manage that
and it does not take much time.
>
> >> 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).
Html formater from the start was different than other -- it was
less regular and more ad hoc. That is why I left it out when
I updated other formaters. I wrote about the change, so you
probably forgot. This time I have updated it to use
'OutputFormTools' but this took significantly more time
than for other formaters (something like 30 minutes per
other formater and abut 3 hours for html). And stil, I did
just minimal change and more should be done.
> 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).
I am not sure different organization would be simpler. There is about
70 construct in OutputForm that need handling. Typically each contructs
needs 1-2 special strings plus some logic. So, each formater has about
100 special strings. Trying to put it into common framework puting
tree walking in category would require each formater to provide
(override) of of order of 100 routines. Possibly more, because
MathML needs special end marker for almost any construct, and
other formaters have slightly differents rules. Common framework
would be forced to call routines from formater at any place
we something special is going on in _any_ of formaters. So,
Formaters based on common framework would have similar size
to current formaters. Actually I looke
Concerning parenthesis, core logic is very simple: just use
'opPrec < prec' test, where 'opPrec' is precision of current
operator and 'prec' is passed from outside. But there are
irregularities (at least fractions need a bit more extra)
and they depend on formater (fraction using '/' has different
property than 2D fraction, and formater may replace one by
another).
--
Waldek Hebisch
[email protected]
--
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.
