| 1 | ||
|
Editor:
Time: 2007/11/18 18:31:25 GMT-8 |
||
| Note: | ||
changed: - Francois Maltey wrote: \begin{verbatim} Subject: [Axiom-developer] about Expression Integer Date: 16 Feb 2006 21:33:45 +0100 From: Francois Maltey <fmaltey@nerim.fr> To: axiom-developer@nongnu.org, fmaltey@nerim.fr I play with expressions and I have these questions : 1/ Can I (or cannot) remain Expressions as x+1/(y+1) y+1/(x+1) and do not have a single denominator. \end{verbatim} You can use Fraction Polynomial Integer as their common domain. \begin{axiom} a:=x + 1/(y+1) b:=y + 1/(x+1) \end{axiom} \begin{verbatim} 2/ Can I go back from (xy+x+1)/(y+1) to x+1/(y+1) ? Other cas have normal or partfrac function, or remain fraction as. \end{verbatim} Axiom also has a package called 'PartialFractionPackage' '(PFRPAC)', but you should package call it. \begin{axiom} c:=partialFraction(a,y)$PFRPAC(INT) d:=partialFraction(b,x)$PFRPAC(INT) \end{axiom} The reason for the package call is that Axiom Interpreter will find the wrong 'partialFraction' from the domain 'PartialFraction' '(PFR)' otherwise, giving a seemingly wrong answer: \begin{axiom} partialFraction(a,y) \end{axiom} This is NOT a bug, but rather a wrong use. The routine 'partialFraction' from 'PFR' expects two arguments: the first is the numerator, and the second the factored denominator! Unfortunately, the function requires the numerator domain to be a 'EuclideanDomain', and 'POLY INT' does not have this property. So we are forced to use 'FRAC POLY INT', but there, partial fraction decomposition does not make much sense: \begin{axiom} partialFraction(numerator a, factor denominator a) \end{axiom} Partial fraction can only be done with respect to a single variable at a time, with all other variables considered in a coefficient domain. So in this sense, it is not possible to retain the two expresssions 'c', 'd' in partial fraction form within the same domain. That is one reason why the target domain where 'c' and 'd' live is 'ANY'. An alternative way could be (but this coercion is really not a true partial fraction decomposition): \begin{axiom} e:= a:: PFR UP(x, FRAC UP(y, FRAC INT)) f:= b:: PFR UP(y, FRAC UP(x, FRAC INT)) \end{axiom} \begin{verbatim} 3/ When I expand a trig formula I cut x+1/(y+1) in x and 1/(y+1) not in xy/(y+1) and x/(y+1) and 1/(y+1). But perhaps my ideas aren't right ? \end{verbatim} At present the codomain of 'partialFraction' is 'ANY', which does not have 'ORDSET'. Even the actual domain 'PFR UP(y, FRAC POLY INT)' of 'c' does not have 'ORDSET'. So it is not possible to form 'EXPR' over these two domains to apply trigonometric functions. Since 'FRAC POLY INT' has 'ORDSET', it should be possible to modify 'PFR R' to give it 'ORDSET' if 'R' has 'ORDSET', since mathematically speaking, 'PFR R' is the same as 'FRAC R'. However, even after modifying 'pfr.spad' to make it into 'ORDSET' if 'R has ORDSET', the interpreter would not allow computations in 'EXPR PFR R' when 'R' is 'UP(y, FRAC POLY INT)'. My guess is it would be quite difficult to add trigonometric functions to 'PFR R' in general. \begin{verbatim} 4/ I'm not sure that the results (xy+x+1)/(y+1) and ((x+1)y+1)/(x+1) are fine : First the order of the variable is important, and the user (almost) can't force it, if he uses "n" and "x" variables. Second the result is longer if the denominator is big. 5/ Of course there is no problem in expand (cos (4*x+5y)), but small problems appear with expand (cos (4*x+5*y/2)) and a lot with expand (cos (4*x+5*y/(2+t+t^2+t^3))). What is the better expand in the 3 cases. Perhaps cos^4 x ... cos^5 y ... cos^4 x ... cos^5 (y/2) ... cos^4 x ... cos^5 (y/(2+t+t^2+t^3)) ... but I'm not sure. I will be very happy if you can give me your advice, and tell me if one or an other way of computation is impossible/not natural/too complex with axiom. \end{verbatim} You can try something like this: \begin{axiom} )clear all fraction:=FRAC POLY INT dom:=UP(y,fraction) bdom:=PFR dom a:=x + 1/(y+1) b:=partialFraction(a,y)$PFRPAC(INT) c:=b::bdom cw:=(wholePart c)::EXPR INT m:=numberOfFractionalTerms(c) crList:= [nthFractionalTerm(c,i) for i in 1..m] cc:=reduce(+,crList) ccx:=cc::(FRAC dom)::(EXPR INT) sin(cw)*cos(ccx)+sin(ccx)*cos(cw) \end{axiom} I would like to add that attempting to create a 'sin' function with source 'bdom' was not successful. The call ends up with an error message:: >> Error detected within library code: reducing over an empty list needs the 3 argument form \begin{axiom} sin(f:bdom):EXPR INT == fw:=(wholePart f)::EXPR INT n:=numberOfFractionalTerms(f) frList:= [nthFractionalTerm(f,i) for i in 1..n] ff:=reduce(+,frList) ffx:=ff::(FRAC dom)::(EXPR INT) sin(fw)*cos(ffx)+sin(ffx)*cos(fw) sin(c) \end{axiom} William
Francois Maltey wrote:

You can use Fraction Polynomial Integer as their common domain.
a:=x + 1/(y+1)
| (1) |
b:=y + 1/(x+1)
| (2) |
![]()
Axiom also has a package called PartialFractionPackage (PFRPAC), but you should package call it.
c:=partialFraction(a,y)$PFRPAC(INT)
| (3) |
d:=partialFraction(b,x)$PFRPAC(INT)
| (4) |
The reason for the package call is that Axiom Interpreter will find the wrong partialFraction from the domain PartialFraction (PFR) otherwise, giving a seemingly wrong answer:
partialFraction(a,y)
| (5) |
This is NOT a bug, but rather a wrong use. The routine partialFraction from PFR expects two arguments: the first is the numerator, and the second the factored denominator! Unfortunately, the function requires the numerator domain to be a EuclideanDomain, and POLY INT does not have this property. So we are forced to use FRAC POLY INT, but there, partial fraction decomposition does not make much sense:
partialFraction(numerator a, factor denominator a)
| (6) |
Partial fraction can only be done with respect to a single variable at a time, with all other variables considered in a coefficient domain. So in this sense, it is not possible to retain the two expresssions c, d in partial fraction form within the same domain. That is one reason why the target domain where c and d live is ANY.
An alternative way could be (but this coercion is really not a true partial fraction decomposition):
e:= a:: PFR UP(x, FRAC UP(y, FRAC INT))
| (7) |
f:= b:: PFR UP(y, FRAC UP(x, FRAC INT))
| (8) |

At present the codomain of partialFraction is ANY, which does not have ORDSET. Even the actual domain PFR UP(y, FRAC POLY INT) of c does not have ORDSET. So it is not possible to form EXPR over these two domains to apply trigonometric functions. Since FRAC POLY INT has ORDSET, it should be possible to modify PFR R to give it ORDSET if R has ORDSET, since mathematically speaking, PFR R is the same as FRAC R. However, even after modifying pfr.spad to make it into ORDSET if R has ORDSET, the interpreter would not allow computations in EXPR PFR R when R is UP(y, FRAC POLY INT). My guess is it would be quite difficult to add trigonometric functions to PFR R in general.

You can try something like this:
)clear all
All user variables and function definitions have been cleared. fraction:=FRAC POLY INT
| (9) |
dom:=UP(y,fraction)
| (10) |
bdom:=PFR dom
| (11) |
a:=x + 1/(y+1)
| (12) |
b:=partialFraction(a,y)$PFRPAC(INT)
| (13) |
c:=b::bdom
| (14) |
cw:=(wholePart c)::EXPR INT
| (15) |
m:=numberOfFractionalTerms(c)
| (16) |
crList:= [nthFractionalTerm(c,i) for i in 1..m]
| (17) |
cc:=reduce(+,crList)
| (18) |
ccx:=cc::(FRAC dom)::(EXPR INT)
| (19) |
sin(cw)*cos(ccx)+sin(ccx)*cos(cw)
| (20) |
I would like to add that attempting to create a sin function with source bdom was not successful. The call ends up with an error message:
>> Error detected within library code:
reducing over an empty list needs the 3 argument form
sin(f:bdom):EXPR INT == fw:=(wholePart f)::EXPR INT n:=numberOfFractionalTerms(f) frList:= [nthFractionalTerm(f,i) for i in 1..n] ff:=reduce(+,frList) ffx:=ff::(FRAC dom)::(EXPR INT) sin(fw)*cos(ffx)+sin(ffx)*cos(fw)
Function declaration sin : PartialFraction UnivariatePolynomial(y, Fraction Polynomial Integer) -> Expression Integer has been added to workspace.
sin(c)
Compiling function sin with type PartialFraction
UnivariatePolynomial(y,Fraction Polynomial Integer) -> Expression
Integer
>> Error detected within library code:
reducing over an empty list needs the 3 argument formWilliam