|
|
last edited 10 years ago by test1 |
1 2 3 | ||
Editor:
Time: 2007/11/17 23:04:00 GMT-8 |
||
Note: |
changed: - The text mode output of Axiom appears to be incorrect, although internally everything is correct, as can be seen by the LaTeX formatted output. \begin{axiom} )set output algebra on summation(i^2, i=a..b)^(d-c+1) summation(i^2^(d-c+1),i=a..b) sum(operator(f)(i)+1,i=1..n) sum(operator(f)(i),i=1..n)+1 sum(operator(f)(i)+1,i=1..n)^3 \end{axiom} Expressions (1) and (2) above appear to be indistinquishable in the native Axiom text mode output. In expressions (3) and (4) the scope of the summation is ambiguous in both the text mode and formatted outputs. A proposed [patch to combfunc.spad] adds parenthesis to the sum and product outputForm:: ddprod l == - prod(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O) + paren(prod(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O)) ddsum l == - sum(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O) + paren(sum(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O)) From kratt6 Thu Jan 20 06:45:15 -0600 2005 From: kratt6 Date: Thu, 20 Jan 2005 06:45:15 -0600 Subject: different patch difficult Message-ID: <20050120064515-0600@page.axiom-developer.org> I'm now pretty confident that a better fix will be rather difficult. In OUTFORM, "+" takes two arguments, each of type OUTFORM. Hence, at this stage we cannot check anymore whether the first would be a sum or a product. I also would like to add that the obvious mathematical blunder in \begin{axiom} product(summation(i*j, i=a..b),j=c..d) \end{axiom} should be fixed in axiom--main--1--patch-25. Martin From kratt6 Thu Jan 20 07:41:50 -0600 2005 From: kratt6 Date: Thu, 20 Jan 2005 07:41:50 -0600 Subject: also Tex needs patching Message-ID: <20050120074150-0600@page.axiom-developer.org> Note that there is a tiny bug in Tex too -- in axioms domain, of course: \begin{axiom} product(product(i*j, i=a..b),j=c..d) \end{axiom} The offending code is in tex.spad, here is a patch:: --- tex.spad 2005-01-03 18:14:33.000000000 +0100 +++ /home/rubey/martin/Axiom/tex.spad 2005-01-20 15:35:45.000000000 +0100 @@ -144,8 +144,8 @@ 0, 0, 0]\$(L I) naryNGOps : L S := ["ROW","&"]\$(L S) - plexOps : L S := ["SIGMA","SIGMA2","PI","INTSIGN","INDEFINTEGRAL"]\$(L S) - plexPrecs : L I := [ 700, 800, 700, 700]\$(L I) + plexOps : L S := ["SIGMA","SIGMA2","PI","PI2", "INTSIGN","INDEFINTEGRAL"]\$(L S) + plexPrecs : L I := [ 700, 800, 700, 800, 700]\$(L I) specialOps : L S := ["MATRIX","BRACKET","BRACE","CONCATB","VCONCAT", _ "AGGLST","CONCAT","OVERBAR","ROOT","SUB","TAG", _ @@ -456,8 +456,9 @@ (n ^= 2) and (n ^= 3) => error "wrong number of arguments for plex" s : S := op = "SIGMA" => "\sum" - op = "SIGMA2" => "\sum" + op = "SIGMA2" => "\sum" op = "PI" => "\prod" + op = "PI2" => "\prod" op = "INTSIGN" => "\int" op = "INDEFINTEGRAL" => "\int" "????" Tex transforms OutputForm to TeX, so it translates literally. OutputForm displays "PI2" as a definite products, so we have to add it here, analogously to "SIGMA2". Note however, that I don't really understand plexPrecs, so I'm not sure what's the correct value there... Martin From unknown Thu Jan 20 13:44:30 -0600 2005 From: Date: Thu, 20 Jan 2005 13:44:30 -0600 Subject: fixed in February build Message-ID: <20050120134430-0600@page.axiom-developer.org> Status: open => closed From billpage Thu Jan 20 21:18:28 -0600 2005 From: billpage Date: Thu, 20 Jan 2005 21:18:28 -0600 Subject: Only the patch for the TeX coding will be in next release Message-ID: <20050120211828-0600@page.axiom-developer.org> Status: closed => open From kratt6 Fri Jan 21 04:37:30 -0600 2005 From: kratt6 Date: Fri, 21 Jan 2005 04:37:30 -0600 Subject: Why? Message-ID: <20050121043730-0600@page.axiom-developer.org> Dear Bill, did you read my latest comment rearding this bug? I really don't understand why you think that it could be improved. (OK, certainly it can be improved, but only with *a lot* of work, including possibly a rewrite of the way OUTFORM works. Currently, OUTFORM is coded in a decentral fashion: every object "knows" how to display itself, by setting the property '%specialDisp':: setProperty(opdsum, SPECIALDISP, ddsum@(List F -> O) pretend None) setProperty(opdprod, SPECIALDISP, ddprod@(List F -> O) pretend None) Only some common operations, such as '+' are coded in OUTFORM itself. However, the routine displaying '+' does not know anything about the semantics of its arguments anymore, since they are already in OUTFORM then. So, you could only introduce an ugly *hack*, parsing the first argument of '+\$OUTFORM' and looking wether it is a sum or a product or a limit or ... Well, any time a new operator is introduced, '+\$OUTFORM' (and of course, also '-\$OUTFORM', '*\$OUTFORM', ...) would have to be readjusted. Currently the design is very clean, hacking this would be a nightmare, and on top of all, what for? Please provide an example where you dislike the result using the patched version! I find \begin{equation} \left(\sum \sb{\displaystyle {i=1}} \sp{\displaystyle n} f \left(i\right)+1\right) \end{equation} perfectly alright. Bill Page wrote: Why is it that the LaTeX output for this example: \begin{axiom} )set output algebra off product(summation(i*j, i=a..b),j=c..d) \end{axiom} gets the parenthesis right but the text output version does not? Martin Rubey wrote: Ok, I looked at it more closely. Consider the two example-pairs: \begin{axiom} product(summation(i*j, i=a..b),j=c..d)::OUTFORM::SEX summation(i^2^(d-c+1),i=a..b)::OUTFORM::SEX \end{axiom} and \begin{axiom} sum(operator(f)(i)+1,i=1..n)::OUTFORM::SEX (sum(operator(f)(i),i=1..n)+1)::OUTFORM::SEX \end{axiom} So in both cases, the OUTFORM internally is different. The domain Tex works on OUTFORM, and in the case of exponentiation "^" it seems to work well, in the case of "+" this is not the case. I don't understand the algorithm. I don't really understand how the interpreter converts OUTFORM to something which is displayed on the screen. Very probably, this is done in src/interp/i-output.boot, however, I find the code very difficult to read. So I have to agree that OUTFORM is not simply broken. However, I still think that my patch is better than none. I would never release Axiom without fixing this somehow. There is another issue. What would you like as output? It seems to me, that the only exceptional case is, if nothing appears to the right of sum or product. Only in this case, parenthesis might be unnecessary. On the other hand, how would you intuitively interpret an output like:: n --+ > f(i) + 1 ? --+ i= 1 Is it $(\sum_{i=1}^n f(i) ) + 1$ or $\sum_{i=1}^n (f(i) + 1)$ ? Could we agree on adopting the quick fix for the first public release, but leaving the issue open? It's important to me, since my guessing program will very often produce this ambigouus output. From BillPage Sun Jan 23 14:01:47 -0600 2005 From: Bill Page Date: Sun, 23 Jan 2005 14:01:47 -0600 Subject: interpreting sums, quick fix Message-ID: <20050123140147-0600@page.axiom-developer.org> I think most people would agree only with the first interpretation $(\sum_{i=1}^n f(i) ) + 1$ Since $\sum_{i=1}^n$ is an unary operator, e.g. like '-' in $-f(i)+1$, it has higher precedence than any binary operator. I have explained why I am (usually) very strongly opposed to "quick fixes" - because then have a habbit of collecting and never being really fixed. As soon as you do something expedient it removes the pressure to find the proper solution and your efforts are diverted by other "more important" things. If this happens many times over, then all of these "quick fixes" become frozen-in because to change any one of them means a major re-design. My point of view is that better not to fix something until you are quite sure that you have the most general solution. But of course it is important to make such "errata" publically available. Once an error like this is recognized, it can be handled in the short term simply by giving a brief warning of the problem. From TimDaly Thu Jan 27 23:59:00 -0600 2005 From: Tim Daly Date: Thu, 27 Jan 2005 23:59:00 -0600 Subject: additional info Message-ID: <20050127235900-0600@page.axiom-developer.org> ------------------------------------------------------------------------------------------------------------------- Dear Bill, "Bill Page" <address@bogus.example.com> wrote: > > > #3127: bug #9297 -- output misses parenthesis in COMBF [A] > > > > the patch does the straightforward thing: it always adds > > parentheses around a sum and a product. In certain cases, > > the parentheses might not be strictly necessary, but with the > > patch the output is always mathematically correct. I'd > > say that it could be a *future* project to improve output. > > > > I am still not clear about this one. Are you saying that > the output is ambiguous in some cases because of missing > parenthesis but that internally the result is correct? Internally, the result is correct, however, the output is not only ambiguous, but wrong in some cases. > If so, then I think I would prefer to wait for someone to > come up with a general solution rather than to do now > what seems like a "quick-and-dirty fix". The fix is not dirty. It is quick and simple. It is not that easy to come up with a really good version, but I'd say that wrong output is unacceptable.
The text mode output of Axiom appears to be incorrect, although internally everything is correct, as can be seen by the LaTeX formatted output.axiom)set output algebra on\begin{equation} \label{eq1}{\left(\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i^2}\right)}^{\left(d - c + 1 \right)}\end{equation}
summation(i^2, i=a..b)^(d-c+1)
b d - c + 1 --+ 2 (1) > i --+ i= aType: Expression(Integer)axiomsummation(i^2^(d-c+1),i=a..b)\begin{equation} \label{eq2}\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i^{2^{\left(d - c + 1 \right)}}}\end{equation}
b d - c + 1 --+ 2 (2) > i --+ i= aType: Expression(Integer)axiomsum(operator(f)(i)+1,i=1..n)\begin{equation} \label{eq3}\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{{f \left({i}\right)}+ 1}\end{equation}
n --+ (3) > f(i) + 1 --+ i= 1Type: Expression(Integer)axiomsum(operator(f)(i),i=1..n)+1\begin{equation} \label{eq4}{\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{f \left({i}\right)}}+ 1\end{equation}
n --+ (4) > f(i) + 1 --+ i= 1Type: Expression(Integer)axiomsum(operator(f)(i)+1,i=1..n)^3\begin{equation} \label{eq5}{\left(\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{{f \left({i}\right)}+ 1}\right)}^3\end{equation}
n 3 --+ (5) > f(i) + 1 --+ i= 1Type: Expression(Integer)Expressions (1) and (2) above appear to be indistinquishable in the native Axiom text mode output.
In expressions (3) and (4) the scope of the summation is ambiguous in both the text mode and formatted outputs.
A proposed [patch to combfunc.spad]? adds parenthesis to the sum and product outputForm:
ddprod l == - prod(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O) + paren(prod(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O)) ddsum l == - sum(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O) + paren(sum(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O))different patch difficult --kratt6, Thu, 20 Jan 2005 06:45:15 -0600 replyI'm now pretty confident that a better fix will be rather difficult. In OUTFORM, "+" takes two arguments, each of type OUTFORM. Hence, at this stage we cannot check anymore whether the first would be a sum or a product.I also would like to add that the obvious mathematical blunder in
axiomproduct(summation(i*j, i=a..b),j=c..d)\begin{equation} \label{eq6}\prod_{ \displaystyle {j = c}}^{ \displaystyle d}{\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i \ j}}\end{equation}
d b ++-++ --+ (6) | | > i j | | --+ j= c i= aType: Expression(Integer)should be fixed in axiom--main--1--patch-25.
Martin
product(product(i*j, i=a..b),j=c..d)\begin{equation} \label{eq7}\prod_{ \displaystyle {j = c}}^{ \displaystyle d}{\prod_{ \displaystyle {i = a}}^{ \displaystyle b}{i \ j}}\end{equation}
d b ++-++ ++-++ (7) | | | | i j | | | | j= c i= a
The offending code is in tex.spad, here is a patch:
--- tex.spad 2005-01-03 18:14:33.000000000 +0100 +++ /home/rubey/martin/Axiom/tex.spad 2005-01-20 15:35:45.000000000 +0100 @@ -144,8 +144,8 @@ 0, 0, 0]$(L I) naryNGOps : L S := ["ROW","&"]$(L S) - plexOps : L S := ["SIGMA","SIGMA2","PI","INTSIGN","INDEFINTEGRAL"]$(L S) - plexPrecs : L I := [ 700, 800, 700, 700]$(L I) + plexOps : L S := ["SIGMA","SIGMA2","PI","PI2", "INTSIGN","INDEFINTEGRAL"]$(L S) + plexPrecs : L I := [ 700, 800, 700, 800, 700]$(L I) specialOps : L S := ["MATRIX","BRACKET","BRACE","CONCATB","VCONCAT", _ "AGGLST","CONCAT","OVERBAR","ROOT","SUB","TAG", _ @@ -456,8 +456,9 @@ (n ^= 2) and (n ^= 3) => error "wrong number of arguments for plex" s : S := op = "SIGMA" => "\sum" - op = "SIGMA2" => "\sum" + op = "SIGMA2" => "\sum" op = "PI" => "\prod" + op = "PI2" => "\prod" op = "INTSIGN" => "\int" op = "INDEFINTEGRAL" => "\int" "????"
Tex transforms OutputForm? to TeX?, so it translates literally. OutputForm? displays "PI2" as a definite products, so we have to add it here, analogously to "SIGMA2".
Note however, that I don't really understand plexPrecs, so I'm not sure what's the correct value there...
Martin
did you read my latest comment rearding this bug?
I really don't understand why you think that it could be improved. (OK, certainly it can be improved, but only with a lot of work, including possibly a rewrite of the way OUTFORM works.
Currently, OUTFORM is coded in a decentral fashion: every object "knows" how to display itself, by setting the property '%specialDisp':
setProperty(opdsum, SPECIALDISP, ddsum@(List F -> O) pretend None) setProperty(opdprod, SPECIALDISP, ddprod@(List F -> O) pretend None)
Only some common operations, such as +
are coded in OUTFORM itself. However, the routine displaying +
does not know anything about the semantics of its arguments anymore, since they are already in OUTFORM then. So, you could only introduce an ugly hack, parsing the first argument of +$OUTFORM
and looking wether it is a sum or a product or a limit or ... Well, any time a new operator is introduced, +$OUTFORM
(and of course, also -$OUTFORM
, *$OUTFORM
, ...) would have to be readjusted.
Currently the design is very clean, hacking this would be a nightmare, and on top of all, what for?
Please provide an example where you dislike the result using the patched version! I find
\begin{equation} \label{eq8} \left(\sum \sb{\displaystyle {i=1}} \sp{\displaystyle n} f \left(i\right)+1\right) \end{equation}
perfectly alright.
Bill Page wrote:
Why is it that the LaTeX? output for this example:
)set output algebra off\begin{equation} \label{eq9}\prod_{ \displaystyle {j = c}}^{ \displaystyle d}{\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i \ j}}\end{equation}
product(summation(i*j, i=a..b),j=c..d)
gets the parenthesis right but the text output version does not?
Martin Rubey wrote:
Ok, I looked at it more closely. Consider the two example-pairs:
product(summation(i*j, i=a..b),j=c..d)::OUTFORM::SEX\begin{equation} \label{eq10}\left(PI 2 \ {\left(= \ j \ c \right)}\ d \ {\left(\hbox{\axiomType{SIGMA}\ } 2 \ {\left(= \ i \ a \right)}\ b \ {\left( \ i \ j \right)}\right)}\right)\end{equation*}
summation(i^2^(d-c+1),i=a..b)::OUTFORM::SEX\begin{equation} \label{eq11}\left(\hbox{\axiomType{SIGMA}\ } 2 \ {\left(= \ i \ a \right)}\ b \ {\left(^\ i \ {\left(^\ 2 \ {\left(+ \ d \ {\left(+ \ {\left(- \ c \right)}\ 1 \right)}\right)}\right)}\right)}\right)\end{equation}
and
sum(operator(f)(i)+1,i=1..n)::OUTFORM::SEX\begin{equation} \label{eq12}\left(\hbox{\axiomType{SIGMA}\ } 2 \ {\left(= \ i \ 1 \right)}\ n \ {\left(+ \ {\left(f \ i \right)}\ 1 \right)}\right)\end{equation}
(sum(operator(f)(i),i=1..n)+1)::OUTFORM::SEX\begin{equation} \label{eq13}\left(+ \ {\left(\hbox{\axiomType{SIGMA}\ } 2 \ {\left(= \ i \ 1 \right)}\ n \ {\left(f \ i \right)}\right)}\ 1 \right)\end{equation}
So in both cases, the OUTFORM internally is different. The domain Tex works on OUTFORM, and in the case of exponentiation "^" it seems to work well, in the case of "+" this is not the case. I don't understand the algorithm.
I don't really understand how the interpreter converts OUTFORM to something which is displayed on the screen. Very probably, this is done in src/interp/i-output.boot, however, I find the code very difficult to read.
So I have to agree that OUTFORM is not simply broken. However, I still think that my patch is better than none. I would never release Axiom without fixing this somehow.
There is another issue. What would you like as output? It seems to me, that the only exceptional case is, if nothing appears to the right of sum or product. Only in this case, parenthesis might be unnecessary. On the other hand, how would you intuitively interpret an output like:
n --+ > f(i) + 1 ? --+ i= 1
Is it $(\sum_{i=1}^n f(i) ) + 1$ or $\sum_{i=1}^n (f(i) + 1)$ ?
Could we agree on adopting the quick fix for the first public release, but leaving the issue open?
It's important to me, since my guessing program will very often produce this ambigouus output.
I think most people would agree only with the first interpretation $(\sum_{i=1}^n f(i) ) + 1$Since $\sum_{i=1}^n$ is an unary operator, e.g. like -
in $-f(i)+1$,
it has higher precedence than any binary operator.
I have explained why I am (usually) very strongly opposed to "quick fixes" - because then have a habbit of collecting and never being really fixed. As soon as you do something expedient it removes the pressure to find the proper solution and your efforts are diverted by other "more important" things. If this happens many times over, then all of these "quick fixes" become frozen-in because to change any one of them means a major re-design. My point of view is that better not to fix something until you are quite sure that you have the most general solution. But of course it is important to make such "errata" publically available. Once an error like this is recognized, it can be handled in the short term simply by giving a brief warning of the problem.
------------------------------------------------------------------------------------------------------------------- Dear Bill,"Bill Page"
wrote:> #3127: bug #9297 -- output misses parenthesis in COMBF [A]?the patch does the straightforward thing: it always adds parentheses around a sum and a product. In certain cases, the parentheses might not be strictly necessary, but with the patch the output is always mathematically correct. I'd say that it could be a future project to improve output.
I am still not clear about this one. Are you saying that the output is ambiguous in some cases because of missing parenthesis but that internally the result is correct?
Internally, the result is correct, however, the output is not only ambiguous, but wrong in some cases.
If so, then I think I would prefer to wait for someone to come up with a general solution rather than to do now what seems like a "quick-and-dirty fix".
The fix is not dirty. It is quick and simple. It is not that easy to come up with a really good version, but I'd say that wrong output is unacceptable.
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) \write18 enabled. %&-line parsing enabled. entering extended mode (./6355555849654217548-18.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/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/amsfonts/amsfonts.sty) (/usr/share/texmf-texlive/tex/latex/amsfonts/amssymb.sty) (/usr/share/texmf-texlive/tex/latex/amscls/amsthm.sty) (/usr/share/texmf-texlive/tex/latex/setspace/setspace.sty Package: `setspace
6.7 <2000/12/01> ) (/usr/share/texmf-texlive/tex/generic/xypic/xy.sty (/usr/share/texmf-texlive/tex/generic/xypic/xy.tex Bootstrap'ing: catcodes, docmode, (/usr/share/texmf-texlive/tex/generic/xypic/xyrecat.tex) (/usr/share/texmf-texlive/tex/generic/xypic/xyidioms.tex)Xy-pic version 3.7 <1999/02/16> Copyright (c) 1991-1998 by Kristoffer H. Rose <krisrose@ens-lyon.fr> Xy-pic is free software: see the User's Guide for details.
Loading kernel: messages; fonts; allocations: state, direction, utility macros; pictures: \xy, positions, objects, decorations; kernel objects: directionals, circles, text; options; algorithms: directions, edges, connections; Xy-pic loaded) (/usr/share/texmf-texlive/tex/generic/xypic/xyall.tex Xy-pic option: All features v.3.3 (/usr/share/texmf-texlive/tex/generic/xypic/xycurve.tex Xy-pic option: Curve and Spline extension v.3.7 curve, circles, loaded) (/usr/share/texmf-texlive/tex/generic/xypic/xyframe.tex Xy-pic option: Frame and Bracket extension v.3.7 loaded) (/usr/share/texmf-texlive/tex/generic/xypic/xycmtip.tex Xy-pic option: Computer Modern tip extension v.3.3 (/usr/share/texmf-texlive/tex/generic/xypic/xytips.tex Xy-pic option: More Tips extension v.3.3 loaded) loaded) (/usr/share/texmf-texlive/tex/generic/xypic/xyline.tex Xy-pic option: Line styles extension v.3.6 loaded) (/usr/share/texmf-texlive/tex/generic/xypic/xyrotate.tex Xy-pic option: Rotate and Scale extension v.3.3 loaded) (/usr/share/texmf-texlive/tex/generic/xypic/xycolor.tex Xy-pic option: Colour extension v.3.3 loaded) (/usr/share/texmf-texlive/tex/generic/xypic/xymatrix.tex Xy-pic option: Matrix feature v.3.4 loaded) (/usr/share/texmf-texlive/tex/generic/xypic/xyarrow.tex Xy-pic option: Arrow and Path feature v.3.5 path, \ar, loaded) (/usr/share/texmf-texlive/tex/generic/xypic/xygraph.tex Xy-pic option: Graph feature v.3.7 loaded) loaded)) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty (/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty) (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty) (/etc/texmf/tex/latex/config/graphics.cfg) (/usr/share/texmf-texlive/tex/latex/graphics/dvips.def))) (/usr/share/texmf-texlive/tex/latex/graphics/color.sty (/etc/texmf/tex/latex/config/color.cfg) (/usr/share/texmf-texlive/tex/latex/graphics/dvipsnam.def)) (/usr/share/texmf-texlive/tex/latex/tools/verbatim.sty) (/usr/share/texmf/tex/latex/graphviz/graphviz.sty (/usr/share/texmf-texlive/tex/latex/psfrag/psfrag.sty)) (/usr/share/texmf/tex/latex/sagetex.sty Writing sage input file 6355555849654217548-18.0px.sage (./6355555849654217548-18.0px.sout)) (/usr/share/texmf-texlive/tex/latex/gnuplottex/gnuplottex.sty (/usr/share/texmf-texlive/tex/latex/base/latexsym.sty) (/usr/share/texmf-texlive/tex/latex/moreverb/moreverb.sty)) (./6355555849654217548-18.0px.aux) (/usr/share/texmf-texlive/tex/latex/amsfonts/umsa.fd) (/usr/share/texmf-texlive/tex/latex/amsfonts/umsb.fd) (/usr/share/texmf-texlive/tex/latex/base/ulasy.fd) [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] Missing { inserted. <to be read again> \ l.139 ...eft(= \ i \ a \right)}\ b \ {\left(^\ i \ {\left(^\ 2 \ {\left...
Missing { inserted. <to be read again> \ l.139 ... \right)}\ b \ {\left(^\ i \ {\left(^\ 2 \ {\left(+ \ d \ {\lef...
Missing } inserted. <inserted text> } l.139 ... \ c \right)}\ 1 \right)}\right)}\right )}\right)}\right)\end{equa...
Missing } inserted. <inserted text> } l.139 ...ight)}\ 1 \right)}\right)}\right)}\right )}\right)\end{equation*} [11] [12] [13] [14] [15] [16] [17] [18] (./6355555849654217548-18.0px.aux) ) (see the transcript file for additional information) Output written on 6355555849654217548-18.0px.dvi (18 pages, 5572 bytes). Transcript written on 6355555849654217548-18.0px.log.