[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.
Martin
--
forwarded from http://page.axiom-developer.org/zope/mathaction/address@hidden
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Axiom-developer] [#8 (Savannah bug #9297) output misses some parenthesis] additional info,
Tim Daly <=