

last edited 8 years ago by test1 
1 2 3  
Editor: test1
Time: 2014/05/09 18:57:58 GMT+0 

Note: 
added:
From test1 Fri May 9 18:57:58 +0000 2014
From: test1
Date: Fri, 09 May 2014 18:57:58 +0000
Subject:
MessageID: <20140509185758+0000@axiomwiki.newsynthesis.org>
Status: open => closed
The text mode output of Axiom appears to be incorrect, although internally everything is correct, as can be seen by the LaTeX formatted output.
)set output algebra on
summation(i^2,i=a..b)^(dc+1)
b d  c + 1 + 2 (1) > i + i= a
(1) 
summation(i^2^(dc+1),i=a..b)
b d  c + 1 + 2 (2) > i + i= a
(2) 
sum(operator(f)(i)+1,i=1..n)
n + (3) > f(i) + 1 + i= 1
(3) 
sum(operator(f)(i),i=1..n)+1
n + (4) > f(i) + 1 + i= 1
(4) 
sum(operator(f)(i)+1,i=1..n)^3
n 3 + (5) > f(i) + 1 + i= 1
(5) 
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))
I also would like to add that the obvious mathematical blunder in
product(summation(i*j,i=a..b), j=c..d)
d b ++++ + (6)   > i j   + j= c i= a
(6) 
should be fixed in axiommain1patch25.
Martin
product(product(i*j,i=a..b), j=c..d)
d b ++++ ++++ (7)     i j     j= c i= a
(7) 
The offending code is in tex.spad, here is a patch:
 tex.spad 20050103 18:14:33.000000000 +0100 +++ /home/rubey/martin/Axiom/tex.spad 20050120 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
(8) 
perfectly alright.
Bill Page wrote:
Why is it that the LaTeX output for this example:
)set output algebra off
product(summation(i*j,i=a..b), j=c..d)
(9) 
gets the parenthesis right but the text output version does not?
Martin Rubey wrote:
Ok, I looked at it more closely. Consider the two examplepairs:
product(summation(i*j,i=a..b), j=c..d)
(10) 
summation(i^2^(dc+1),i=a..b)
(11) 
)set output tex off
)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^(dc+1),i=a..b)::OUTFORM::SEX
Cannot convert from type OutputForm to SExpression for value b d  c + 1 + 2 > i + i= a
)set output tex on
)set output algebra off
and
sum(operator(f)(i)+1,i=1..n)
(12) 
(sum(operator(f)(i),i=1..n)+1)
(13) 
)set output tex off
)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
)set output tex on
)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/ioutput.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 or ?
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 interpretationSince 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 frozenin because to change any one of them means a major redesign. 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 "quickanddirty 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.
Status: open => closed