MathAction #8 (Savannah bug #9297) output misses some parenthesis

Topics

FrontPage
- IssueTracker
  - #8 (Savannah bug #9297) output misses some parenthesis <-- You are here.

The text mode output of Axiom appears to be incorrect, although internally everything is correct, as can be seen by the LaTeX formatted output.

fricas

)set output algebra on

summation(i^2, i=a..b)^(d-c+1)

         b      d - c + 1
        --+    2
   (1)  >     i
        --+
        i= a

$\label{eq1}{\left(\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{{i}^{2}}\right)}^{d - c + 1}$

(1)

Type: Expression(Integer)

fricas

summation(i^2^(d-c+1),i=a..b)

         b      d - c + 1
        --+    2
   (2)  >     i
        --+
        i= a

$\label{eq2}\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{{i}^{{2}^{d - c + 1}}}$

(2)

Type: Expression(Integer)

fricas

sum(operator(f)(i)+1,i=1..n)

         n
        --+
   (3)  >     f(i) + 1
        --+
        i= 1

$\label{eq3}\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{\left({f \left({i}\right)}+ 1 \right)}$

(3)

Type: Expression(Integer)

fricas

sum(operator(f)(i),i=1..n)+1

         n
        --+
   (4)  >     f(i) + 1
        --+
        i= 1

$\label{eq4}{\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{f \left({i}\right)}}+ 1$

(4)

Type: Expression(Integer)

fricas

sum(operator(f)(i)+1,i=1..n)^3

         n            3
        --+
   (5)  >     f(i) + 1
        --+
        i= 1

$\label{eq5}{\left(\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{\left({f \left({i}\right)}+ 1 \right)}\right)}^{3}$

(5)

Type: Expression(Integer)

Expressions (1) and (2) above appear to be indistinguishable 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

fricas

product(summation(i*j, i=a..b),j=c..d)

          d     b
        ++-++  --+
   (6)   | |   >     i j
         | |   --+
        j= c   i= a

$\label{eq6}\prod_{ \displaystyle {j = c}}^{ \displaystyle d}{\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i \ j}}$

(6)

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:

fricas

product(product(i*j, i=a..b),j=c..d)

          d      b
        ++-++  ++-++
   (7)   | |    | |   i j
         | |    | |
        j= c   i= a

$\label{eq7}\prod_{ \displaystyle {j = c}}^{ \displaystyle d}{\prod_{ \displaystyle {i = a}}^{ \displaystyle b}{i \ j}}$

(7)

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

Why? --kratt6, Fri, 21 Jan 2005 04:37:30 -0600 reply

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

$\label{eq8} \left(\sum \sb{\displaystyle {i=1}} \sp{\displaystyle n} f \left(i\right)+1\right)$

(8)

perfectly alright.

Bill Page wrote:

Why is it that the LaTeX output for this example:

fricas

)set output algebra off

product(summation(i*j, i=a..b),j=c..d)

$\label{eq9}\prod_{ \displaystyle {j = c}}^{ \displaystyle d}{\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i \ j}}$

(9)

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:

fricas

product(summation(i*j, i=a..b),j=c..d)

$\label{eq10}\prod_{ \displaystyle {j = c}}^{ \displaystyle d}{\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{i \ j}}$

(10)

Type: Expression(Integer)

fricas

summation(i^2^(d-c+1),i=a..b)

$\label{eq11}\sum_{ \displaystyle {i = a}}^{ \displaystyle b}{{i}^{{2}^{d - c + 1}}}$

(11)

Type: Expression(Integer)

fricas

)set output tex off

fricas

)set output algebra on

product(summation(i*j, i=a..b),j=c..d)::OUTFORM::SEX

   Cannot convert from type OutputForm to SExpression for value
     d     b
   ++-++  --+
    | |   >     i j
    | |   --+
   j= c   i= a

summation(i^2^(d-c+1),i=a..b)::OUTFORM::SEX

   Cannot convert from type OutputForm to SExpression for value
    b      d - c + 1
   --+    2
   >     i
   --+
   i= a

fricas

)set output tex on

fricas

)set output algebra off

and

fricas

sum(operator(f)(i)+1,i=1..n)

$\label{eq12}\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{\left({f \left({i}\right)}+ 1 \right)}$

(12)

Type: Expression(Integer)

fricas

(sum(operator(f)(i),i=1..n)+1)

$\label{eq13}{\sum_{ \displaystyle {i = 1}}^{ \displaystyle n}{f \left({i}\right)}}+ 1$

(13)

Type: Expression(Integer)

fricas

)set output tex off

fricas

)set output algebra on

sum(operator(f)(i)+1,i=1..n)::OUTFORM::SEX

   Cannot convert from type OutputForm to SExpression for value
    n
   --+
   >     f(i) + 1
   --+
   i= 1

(sum(operator(f)(i),i=1..n)+1)::OUTFORM::SEX

   Cannot convert from type OutputForm to SExpression for value
    n
   --+
   >     f(i) + 1
   --+
   i= 1

fricas

)set output tex on

fricas

)set output algebra off

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

... --test1, Fri, 09 May 2014 18:57:58 +0000 reply

Status: open => closed

Subject: (replying) Be Bold !!

	( 14 subscribers )