[Top][All Lists]

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

[Axiom-developer] RE: Savannah patches

From: Bill Page
Subject: [Axiom-developer] RE: Savannah patches
Date: Wed, 29 Dec 2004 01:25:47 -0500

On Tuesday, December 28, 2004 2:43 PM Martin Rubey wrote:
> Bill Page writes:
>  > #2074:  Bug #4733 (rounding of negative numbers) [AS]
>  > #3089:  bug #6357 sqrt(-1/abs(x))-1/sqrt(-abs(x))=>0 [A]
>  > #3121:  [bugs #9057] product over product or sum fail [A]
>  > #3349:  bug #10312 Problems raising a UTS to a negative 
> integer power  [A]
> What does [A] and [AS] mean?

[A] means assigned to me, [S] means submitted by me. This was
copied from my summary page on Savannah. Each developer can
maintain such a list if this wish.

>  > I do have some questions about the status of some others. From
>  > the comments it is not clear to me that the proposed patches are
>  > complete:
>  > 
>  > #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?
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". In my experience
quick-and-dirty has a habbit of becoming almost permanent.
I think one can see evidence of this having happened to
Axiom in the past.
>  > #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.

My philosphy is something like this: While I agree that
mathematical correctness should have a very high priority
in Axiom, that correctness should always be achieved in the
most generally applicable manner as possible. Otherwise one
runs the risk of becoming trapped by many "little decisions"
that never let the "grand ideas" achieve their full potential.
I think this has already happened to most other computer
algebra systems.

>  > #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

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

Bill Page.

reply via email to

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