axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Re: coerce, cast, partial fractions


From: Dylan Thurston
Subject: Re: [Axiom-developer] Re: coerce, cast, partial fractions
Date: Sat, 11 Oct 2003 11:32:37 -0400
User-agent: Mutt/1.5.4i

On Sat, Oct 11, 2003 at 03:34:46AM -0400, William Sit wrote:
> Dylan Thurston wrote:
> > 
> > On Thu, Oct 09, 2003 at 10:31:55AM -0400, Tim Daly wrote:
> > > If I understand the partialFraction answer (perhaps I don't) the
> > > result given is a partial fraction as far as Axiom is concerned.
> > > Partial fractions work on the factored equation and it appears
> > > that Axiom doesn't think it can factor the equation over the
> > > target domain so the partial fraction uses the "fully factored"
> > > value. The issue appears to be that the target domain chosen by
> > > the interpreter is one in which there are no factors. Or perhaps
> > > it is just a street-level bug :-)
> > 
> > But how could x^2-1 not be factorizable in any reasonable domain?
> > 
> > I can see that AXIOM might pick a domain where it doesn't know how to
> > factor, but I would be very surprised to see one coming from an
> > expression like this!
> > 
> Surely, x^2 -1 can be factored in POLY INT and Axiom behaves correctly. So the
> problem is not with factoring.
> 
> Remember that algorithms in Axiom are categorical. From the documentation in
> partialFraction:
> 
> "For a general euclidean domain, it is not known how to factor the 
> denominator.
> Thus the function partialFraction takes as its second argument an element of
> Factored(R)."
> 
> It also states that the requirement for R to be a euclidean domain is to
> normalize the denominator.

Sure, that's why the second argument is supposed to be factored _before_
partialFraction is called.  It's not being factored; this is not a bug
in partialFraction, but a bug someplace else.

Specifically, from the output with ')lisp (setq |$monitorNewWorld| t)',
the problem probably lies in whatever is going on in this stanza:
----------
---->Factored UnivariatePolynomial(x,Fraction Integer)----> searching op table 
for:
   coerce : UnivariatePolynomial(x,Fraction Integer) -> % from  Factored 
UnivariatePolynomial(x,Fraction Integer)
<----#<compiled-function 
|FR;coerce;R$;43|>(Factored,UnivariatePolynomial(x,Fraction Integer))
----------
This looks like it should be calling the standard 'coerce' from
UP(x, FRAC INT) to FR UP(x, FRAC INT), which should do the factorization
(according to all the documentation I read), but doesn't!  (Or maybe the
coercion function from the 'Factored' domain doesn't actually do the
factorization itself?)

Compare this to what happens when we try to do this coercion explicitly:
----------
(4) -> aa:UP(x, FRAC INT) := x^2-1

   (4)  x  - 1
                               Type: UnivariatePolynomial(x,Fraction Integer)

(5) -> aa::FR UP(x, FRAC INT)
---->RationalFactorize UnivariatePolynomial(x,Fraction Integer)----> searching 
op table for:
   factor : UnivariatePolynomial(x,Fraction Integer) -> Factored 
UnivariatePolynomial(x,Fraction Integer) from  RationalFactorize 
UnivariatePolynomial(x,Fraction Integer)
<----#<compiled-function 
|RATFACT;factor;RPF;1|>(RationalFactorize,UnivariatePolynomial(x,Fraction 
Integer))

---->Factored UnivariatePolynomial(x,Fraction Integer)----> searching op table 
for:
   coerce : % -> OutputForm from  Factored UnivariatePolynomial(x,Fraction 
Integer)
<----#<compiled-function 
|FR;coerce;$Of;35|>(Factored,UnivariatePolynomial(x,Fraction Integer))
   (5)  (x - 1)(x + 1)
                      Type: Factored UnivariatePolynomial(x,Fraction Integer)
----------
Somehow, a different routine ('RationalFactorize') is being called.

Peace,
        Dylan

Attachment: signature.asc
Description: Digital signature


reply via email to

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