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
Type: Expression(Integer)fricas summation(i^2^(d-c+1),
Type: Expression(Integer)fricas sum(operator(f)(i)+1,
Type: Expression(Integer)fricas sum(operator(f)(i),
Type: Expression(Integer)fricas sum(operator(f)(i)+1,
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)) I also would like to add that the obvious mathematical blunder in fricas product(summation(i*j,
Type: Expression(Integer)should be fixed in axiom--main--1--patch-25. Martin - Note that there is a tiny bug in Tex too
- in axioms domain, of course:
fricas product(product(i*j,
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 Only the patch for the TeX coding will be in next release --billpage, Thu, 20 Jan 2005 21:18:28 -0600 replydid 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 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 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
perfectly alright. Bill Page wrote: Why is it that the LaTeX output for this example: fricas )set output algebra off
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,
Type: Expression(Integer)fricas summation(i^2^(d-c+1),
Type: Expression(Integer)fricas )set output tex off fricas )set output algebra on fricas )set output tex on fricas )set output algebra off and fricas sum(operator(f)(i)+1,
Type: Expression(Integer)fricas (sum(operator(f)(i),
Type: Expression(Integer)fricas )set output tex off fricas )set output algebra on 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 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 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]? 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. Status: open => closed |

different patch difficult--kratt6, Thu, 20 Jan 2005 06:45:15 -0600 reply