Ralf,

I am continuing to test the rendering of existing axiom-wiki pages
using the new tex formatter.  There are numerous cases where breqn
fails to break the output generated by FriCAS which was properly
processed by texbreaker. Maybe this is not too surprising since
texbreaker was specifically written for the tex generated by the old
Axiom tex formatter and tuned by the author specifically from the
production of the original Axiom book, while breqn is in principle
more general. But I am beginning to think that the number of cases
where breqn fails is making it seem rather impractical to convert
axiom-wiki to the new format.  One experiment that I might try is to
use both texbreaker and the new format with breqn.  But in the new
format there is a lot of FriCAS-specific markup of I don't know how it
is going to turn out.

I did find one case so far of new format tex output from FriCAS that
LaTeX refuses to compile. The following axiom-wiki page source:

\begin{axiom}
Expr ==> Expression Integer
zt:=operator 'zt
ztransrules :=  ruleset([                                            _
  suchThat(rule zt(a^n,n,z) == z/(z-a),                              _
                [a, n], l +-> freeOf?(l.1, l.2)),                    _
  suchThat(rule zt(cos(a*n),n,z) == z*(z-cos(a))/(1-2*z*cos(a)+z^2), _
                [a, n], l +-> freeOf?(l.1, l.2)),                    _
  suchThat(rule zt(sin(a*n),n,z) == z*sin(a)/(1-2*z*cos(a)+z^2),     _
                [a, n], l +-> freeOf?(l.1, l.2))                     _
])$Ruleset(Integer, Integer, Expr)
\end{axiom}

Looks OK at http://axiom-wiki.newsynthesis.org/SandBoxZtransform#eq2

Using the new tex format I get the following generated LaTeX:

\documentclass[12pt,notitlepage]{article}
\newenvironment{latex}{}{}
\usepackage{fricasmath}
\begin{document}
\pagestyle{empty}
\relax
\begin{fricasmath}{2}
\SYMBOL{zt}%
\end{fricasmath}\newpage
\begin{fricasmath}{3}
\BRACE{\FUN{zt}\PAREN{\SUPER{\SYMBOL{a}}{\SYMBOL{n}},\SYMBOL{n},\SYMBOL{z}}%
\SYMBOL{\ ==\ }\frac{\SYMBOL{z}}{\SYMBOL{z}-{\SYMBOL{a}}}\COMMA \FUN{zt}%
\PAREN{\cos{\PAREN{\SYMBOL{a}\TIMES \SYMBOL{n}}},\SYMBOL{n},\SYMBOL{z}}%
\SYMBOL{\ ==\ }\frac{\SYMBOL{z}\TIMES \cos{\SYMBOL{a}}-{\SUPER{\SYMBOL{z}}{2}%
}}{2\TIMES \SYMBOL{z}\TIMES \cos{\SYMBOL{a}}-{\SUPER{\SYMBOL{z}}{2}}-{1}}%
\COMMA \FUN{zt}\PAREN{\sin{\PAREN{\SYMBOL{a}\TIMES \SYMBOL{n}}},\SYMBOL{n},%
\SYMBOL{z}}\SYMBOL{\ ==\ }-{\frac{\SYMBOL{z}\TIMES \sin{\SYMBOL{a}}}{2\TIMES %
\SYMBOL{z}\TIMES \cos{\SYMBOL{a}}-{\SUPER{\SYMBOL{z}}{2}}-{1}}}}%
\end{fricasmath}
\end{document}

and the wikicomplains that:

Some or all expressions may not have rendered properly, because Latex
returned the following error:

This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
 \write18 enabled.
 %&-line parsing enabled.
entering extended mode
(./4143450100878697082-16.0px.tex
LaTeX2e <2005/12/01>
Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, arabic, farsi, croatian, ukrainian, russian, bulgarian, czech, slov
ak, danish, dutch, finnish, basque, french, german, ngerman, ibycus, greek, mon
ogreek, ancientgreek, hungarian, italian, latin, mongolian, norsk, icelandic, i
nterlingua, turkish, coptic, romanian, welsh, serbian, slovenian, estonian, esp
eranto, uppersorbian, indonesian, polish, portuguese, spanish, catalan, galicia
n, swedish, ukenglish, pinyin, loaded.
(/usr/share/texmf-texlive/tex/latex/base/article.cls
Document Class: article 2005/09/16 v1.4f Standard LaTeX document class
(/usr/share/texmf-texlive/tex/latex/base/size12.clo))
(/usr/local/lib/fricas/emacs/fricasmath.sty
(/usr/share/texmf-texlive/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(/usr/share/texmf-texlive/tex/latex/amsmath/amstext.sty
(/usr/share/texmf-texlive/tex/latex/amsmath/amsgen.sty))
(/usr/share/texmf-texlive/tex/latex/amsmath/amsbsy.sty)
(/usr/share/texmf-texlive/tex/latex/amsmath/amsopn.sty))
(/usr/share/texmf-texlive/tex/latex/breqn/breqn.sty
(/usr/share/texmf-texlive/tex/latex/breqn/flexisym.sty
(/usr/share/texmf-texlive/tex/latex/breqn/cmbase.sym))
(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty))
(/usr/local/lib/fricas/emacs/tensor.sty)) (./4143450100878697082-16.0px.aux)
Underfull \hbox (badness 10000) in paragraph at lines 13--13
$[][]|$

Underfull \hbox (badness 10000) detected at line 13
$[][]|$

Underfull \hbox (badness 10000) detected at line 13
$[][]|$
[1]
 Bad mathchar (32768).
<to be read again>
                   \relax
l.22 ...\SYMBOL{a}}-{\SUPER{\SYMBOL{z}}{2}}-{1}}}}
                                                  %
 Bad mathchar (32768).
<to be read again>
                   \relax
l.22 ...\SYMBOL{a}}-{\SUPER{\SYMBOL{z}}{2}}-{1}}}}
                                                  %
 Bad mathchar (32768).
<to be read again>
                   \relax
l.22 ...\SYMBOL{a}}-{\SUPER{\SYMBOL{z}}{2}}-{1}}}}
                                                  %
[2] (./4143450100878697082-16.0px.aux) )
(see the transcript file for additional information)
Output written on 4143450100878697082-16.0px.dvi (2 pages, 1124 bytes).
Transcript written on 4143450100878697082-16.0px.log.

--

I am at a loss to know what is going wrong here.


On 18 October 2014 06:16, Ralf Hemmecke <[email protected]> wrote:
> ...
>>> That texbreak can handle this looks nice, but I'm still not in
>>> favour of texbreak.
>>
>> You mean because it is written in C ?
>
> No, because it doesn't calculate the width with true tex width of the
> current font etc. It has its own approximate width of certain things
> hardcoded inside.
>

Yet in spite of the approximation it seems to usually make a good
choice.  This suggests that knowing the true tex width is not so
important.

>>
>> I significant part of texbreak is concerned exactly with this sort of
>> calculation.
>
> Well, since TeX is a programming language that's Turing complete, it
> could also be done in TeX,

It seems that nobody is very interested in maintaining this kind of
coding in TeX.  As a programming language it seem simply impossible to
me even if theoretically it is complete.

> but the question is where to break numerator
> and denominator. If the width of both is known, drawing a line between
> numerator and denominator should be doable, but for
>
>   \frac{a}{b} + \frac{c}{d}
>
> it's hard to decide whether it's better to break a or at + or maybe at
> c, if just a and c are too long to fit on one line.
>

If I recall the code correctly I think texbreak makes this decision
based on a heuristic that always gives priority to breaking at the
outter-most + and then if still necessary it applies the same
heuristic to the numer and denominator of the first term and then the
2nd term etc.

Regards,
Bill Page.

-- 
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.

Reply via email to