login  home  contents  what's new  discussion  bug reports     help  links  subscribe  changes  refresh  edit

Edit detail for #8 (Savannah bug #9297) output misses some parenthesis revision 1 of 3

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.

Submitted by : (unknown) at: 2007-11-17T23:04:00-08:00 (17 years ago)
Name :
Axiom Version :
Category : Severity : Status :
Optional subject :  
Optional comment :

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
summation(i^2, i=a..b)^(d-c+1)
b d - c + 1 --+ 2 (1) > i --+ i= a
\begin{equation} \label{eq1}{\left(\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i^2}\right)}^{\left(d - c + 1 \right)}\end{equation}
Type: Expression(Integer)
axiom
summation(i^2^(d-c+1),i=a..b)
b d - c + 1 --+ 2 (2) > i --+ i= a
\begin{equation} \label{eq2}\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i^{2^{\left(d - c + 1 \right)}}}\end{equation}
Type: Expression(Integer)
axiom
sum(operator(f)(i)+1,i=1..n)
n --+ (3) > f(i) + 1 --+ i= 1
\begin{equation} \label{eq3}\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{{f \left({i}\right)}+ 1}\end{equation}
Type: Expression(Integer)
axiom
sum(operator(f)(i),i=1..n)+1
n --+ (4) > f(i) + 1 --+ i= 1
\begin{equation} \label{eq4}{\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{f \left({i}\right)}}+ 1\end{equation}
Type: Expression(Integer)
axiom
sum(operator(f)(i)+1,i=1..n)^3
n 3 --+ (5) > f(i) + 1 --+ i= 1
\begin{equation} \label{eq5}{\left(\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{{f \left({i}\right)}+ 1}\right)}^3\end{equation}
Type: 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 reply
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

axiom
product(summation(i*j, i=a..b),j=c..d)
d b ++-++ --+ (6) | | > i j | | --+ j= c i= a
\begin{equation} \label{eq6}\prod_{ \displaystyle {j = c}}^{ \displaystyle d}{\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i \ j}}\end{equation}
Type: Expression(Integer)

should be fixed in axiom--main--1--patch-25.

Martin

also Tex needs patching --kratt6, Thu, 20 Jan 2005 07:41:50 -0600 reply
Note that there is a tiny bug in Tex too
in axioms domain, of course:

axiom
product(product(i*j, i=a..b),j=c..d)
d b ++-++ ++-++ (7) | | | | i j | | | | j= c i= a
\begin{equation} \label{eq7}\prod_{ \displaystyle {j = c}}^{ \displaystyle d}{\prod_{ \displaystyle {i = a}}^{ \displaystyle b}{i \ j}}\end{equation}
Type: Expression(Integer)

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

fixed in February build
Thu, 20 Jan 2005 13:44:30 -0600 reply
Status: open => closed

Only the patch for the TeX? coding will be in next release --billpage, Thu, 20 Jan 2005 21:18:28 -0600 reply
Status: closed => open

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} \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:

axiom
)set output algebra off
product(summation(i*j, i=a..b),j=c..d)
\begin{equation} \label{eq9}\prod_{ \displaystyle {j = c}}^{ \displaystyle d}{\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i \ j}}\end{equation}
Type: Expression(Integer)

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:

axiom
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*}
Type: SExpression?
axiom
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}
Type: SExpression?

and

axiom
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}
Type: SExpression?
axiom
(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}
Type: SExpression?

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.

interpreting sums, quick fix --Bill Page, Sun, 23 Jan 2005 14:01:47 -0600 reply
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.

additional info --Tim Daly, Thu, 27 Jan 2005 23:59:00 -0600 reply
------------------------------------------------------------------------------------------------------------------- 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.


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