This example is from Ulrich Schwardmann: Computeralgebra-Systeme, Addison-Wesley, 1995, p127f. It tries to compute a partial fraction of a fraction with unknown constants. The result is not the expected partial fraction decomposition, and does not seem to have any other senseful interpretation (it is q/x).

Following is a verification of the partial fraction that macsyma computes.

(1) -> q:=(x+a)/(x*(x**3+(b+c)*x**2+b*c*x))

   There are no library operations named ** 
      Use HyperDoc Browse or issue
                                 )what op **
      to learn if there is any operation containing " ** " in its name.

   Cannot find a definition or applicable library operation named ** 
      with argument type(s) 
                                 Variable(x)
                               PositiveInteger

      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.

it seems that it is better to use partialFraction$PartialFraction. I did it as follows:

SUP FRAC POLY INT has EUCDOM

(1)

den := univariate((x*(x**3+(b+c)*x**2+b*c*x)),x)::SUP FRAC POLY INT

   There are no library operations named ** 
      Use HyperDoc Browse or issue
                                 )what op **
      to learn if there is any operation containing " ** " in its name.

   Cannot find a definition or applicable library operation named ** 
      with argument type(s) 
                                 Variable(x)
                               PositiveInteger

      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.

Does this suggest that the bug is in PartialFractionPackage?

The reason for the behaviour described above is quite simple to explain - unfortunately...

There are two operations partialFraction with two arguments:

    partialFraction: (R, FRR) -> %
      ++ partialFraction(numer,denom) is the main function for
      ++ constructing partial fractions. The second argument is the
      ++ denominator and should be factored.

from the exposed domain PartialFraction and:

      partialFraction: (FPR, Symbol) -> Any
         ++ partialFraction(rf, var) returns the partial fraction decomposition
         ++ of the rational function rf with respect to the variable var.

from the unexposed package PartialFractionPackage. Of course, the interpreter chooses the exposed domain, which produced the surprising result.

This shows that overloading should be done very carefully. I think we should rename the operations in PartialFractionPackage.

Martin

Martin

(Sorry for not first testing a simpler example...)

I came to the same result this weekend. It seems to me from first tests that it would suffice to just also expose PartialFractionPackage?. However I don't know axiom good enough to see if there are any unwanted side effects.

)expose PFRPAC

   PartialFractionPackage is now explicitly exposed in frame initial 
partialFraction((x+a)/(x*(x**3+(b+c)*x**2+b*c*x)),x)

   There are no library operations named ** 
      Use HyperDoc Browse or issue
                                 )what op **
      to learn if there is any operation containing " ** " in its name.

   Cannot find a definition or applicable library operation named ** 
      with argument type(s) 
                                 Variable(x)
                               PositiveInteger

      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.

Category: Axiom Mathematics => Axiom User Interface Status: open => fix proposed

there are in fact two (different) fixes proposed... Should be reconsidered

Category: Axiom User Interface => Axiom Library