Dylan Thurston wrote:
>Furthermore, I think there's a bug here:
>
>
>(8) > partialFraction((2*x^3), (1x^2))
> There are 1 exposed and 1 unexposed library operations named=20
> partialFraction having 2 argument(s) but none was determined to=20
> be applicable. [snippage]
>(8) > partialFraction((2*x^3)::UP(x, FRAC INT), (1x^2))
>
> 2x
> (8)  2x  
> 2
> x  1
> Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
>r)
>(9) > partialFraction((2*x^3), (1x^2)::UP(x, FRAC INT))
>
> 1 1
> (9)  2x    
> x  1 x + 1
> Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
>r)
>
>
>Why didn't input (8) above actually do the partial fraction expansion?
Dylan,
(1) > )d op partialFraction
There is one exposed function called partialFraction :
[1] (D1,Factored D1) > PartialFraction D1 from PartialFraction D1
if D1 has EUCDOM
There are 2 unexposed functions called partialFraction :
[1] (Fraction Polynomial D4,Symbol) > Any from
PartialFractionPackage D4
if D4 has Join(EuclideanDomain,CharacteristicZero)
[2] (Polynomial D5,Factored Polynomial D5,Symbol) > Any
from PartialFractionPackage D5
if D5 has Join(EuclideanDomain,CharacteristicZero)
First, I make a couple variables to hold the expressions.
This lets me figure out what the interpreter type is by default:
(1) > a:=2*x^3
3
(1) 2x
Type: Polynomial Integer
(2) > b:=1x^2
2
(2)  x + 1
Type: Polynomial Integer
The signature listed above requires that the first argument type
must be a EuclideanDomain (EUCDOM):
(3) > Polynomial(Integer) has EUCDOM
(3) false
Type: Boolean
POLY(INT) is not a EUCDOM.
However, the type you provided is a EUCDOM.
(4) > UP(x,FRAC INT) has EUCDOM
(4) true
Type: Boolean
So we can make variables that are the correct type:
(5) > aa:UP(x,FRAC INT):=2*x^3
3
(5) 2x
Type: UnivariatePolynomial(x,Fraction Integer)
(6) > bb:UP(x,FRAC INT):=1x^2
2
(6)  x + 1
Type: UnivariatePolynomial(x,Fraction Integer)
And the call succeeds:
(7) > partialFraction(aa,bb)
1 1
(7)  2x    
x  1 x + 1
Type: PartialFraction UnivariatePolynomial(x,Fraction Integer)
So partialFraction can create the correct call signature. I suspect the
interpreter created some intermediate type that it couldn't coerce to
the required target type. I agree that it should have been able to
give the factored output but did not.
