[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] [#8 (Savannah bug #9297) output misses some parenthesi

From: Tim Daly
Subject: [Axiom-developer] [#8 (Savannah bug #9297) output misses some parenthesis] additional info
Date: Thu, 27 Jan 2005 23:59:03 -0600

Dear Bill,

"Bill Page" <address@hidden> 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.

> >  > #3148:  bug #9216 differentiating sums with respect to a 
> > bound is wrong [A]
> > 
> > in my opinion correct beyond doubt.
> In the patch report you wrote:
> "Mathematically axiom produces correct output now, however
> I'm not sure whether my patch is best possible.
> Maybe there should be a function D in OutputForm that displays
> unevaluated differentiation. Also, I find it ugly to use the
> raw %diff operator in COMBF. Furthermore, is it necessary to
> substitute a dummy variable for the variable of differentiation?"
> I am concerned that this is another case of a "quick fix" for
> which we should consider a more general solution of the kind
> that you suggest above.

In this case the situation is a tiny little bit different, since here also 
Axioms internal representation is wrong. Worse: the design of Axioms Algebra 
currently doesn't provide "unevaluated differentiation". Obviously, it was 
thought that anything can be differentiated. In fact, I'm almost sure that 
attempting to differentiate a sum by one of its bound should signal an error, 
because it is impossible to assign a mathematically correct meaning to it. In 
this sense, I'd suggest that we aim to reach consensus until end of January.

> >  > #3161:  any? and every? should exit when the result is clear [A]
> > 
> > I don't have the time to look it up right now, whether the 
> > "mixed" behaviour TREE would vanish with this patch or not.
> > In any case, this "bug" will never produce mathematically
> > incorrect results. It will only waste cpu cycles.
> Can we be sure that functions applied during evaluating 'any?'
> and 'every?' are not being executed for their side-effects?
> I worry that changing the semantics here could have unexpected
> effects in other places in Axiom where 'any?' and 'every?' are
> used.
> > In fact, I included the comment regarding TREE only to document 
> > that if there would be code that depends on the "evaluate all"
> > code, it wouldn't work with TREE anyway, so it would be broken
> > already. Bottom line: no danger.
> I am not convinced. I think this needs more analysis, i.e. look
> at each case were 'any?' and 'every?' are actually used or else
> we have to be prepared to do a lot of testing.

I did some analysis and I'm quite sure that no code will be broken. However, 
this is a patch I won't push, since it won't produce incorrect results. 


forwarded from

reply via email to

[Prev in Thread] Current Thread [Next in Thread]