[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiomdeveloper] [#270 integrating UTS] (new) integrating UTS
From: 
Bill Page 
Subject: 
[Axiomdeveloper] [#270 integrating UTS] (new) integrating UTS 
Date: 
Sat, 18 Feb 2006 10:35:26 0600 
Changes http://wiki.axiomdeveloper.org/270IntegratingUTS/diff

??changed:


From BillPage Sat Feb 18 06:56:34 0600 2006
From: Bill Page
Date: Sat, 18 Feb 2006 06:56:34 0600
Subject: (new) integrating UTS
MessageID: <address@hidden>


Update of bug #10350 (project axiom):

 Status: None => transferred
Example of code trigerring the bug: integrate((1/x)::UTS(FRAC POLY INT, x,
0),x)
integrate((1/y)::UTS(FRAC POLY INT, x, 0),z) => integrate((1/x)::UTS(FRAC
POLY INT, x, 0),x)
Originally Savannah bug 10350.
Example of code trigerring the bug:
\begin{axiom}
integrate((1/x)::UTS(FRAC POLY INT, x,0),x)
\end{axiom}
Result::
Cannot find a definition or applicable library operation named
integrate with argument type(s)
UnivariateTaylorSeries(Fraction Polynomial Integer,x,0)
Variable z
\begin{axiom}
??changed:


 _______________________________________________________

Reply to this item at:

 <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=10350>

_______________________________________________
 Message sent via/by Savannah
 http://savannah.nongnu.org/

\end{axiom}
The first bug is an indication that '1/x' should not be of type
'UTS(x, FRAC POLY INT)', 'UP(x, FRAC POLY INT)' and so on. The
second is an indication that QFCAT should have a function
'variables: % > List Symbol'.
**Sat 10/02/04 at 08:09, comment #2:**
I disagree with the previous comment; x should be captured and
not allowed in the FRAC POLY INT. (I agree that the second example
in the original report is not a bug.)
But surely we can all agree that
'integrate((1/x)::ULS(FRAC POLY INT, x, 0),x)'
is a bug? The problem is the same: the '1/x' is being treated in
the coefficient domain. Note that
'integrate(1/(x::ULS(FRAC POLY INT, x, 0)),x)'
produces a correct result.
Dylan (address@hidden)
**Sat 10/02/04 at 04:33, comment #1:**
Neither of these is a bug. In the first one, Axiom coerced
'1/x' into 'FRAC POLY INT' correctly: the only / operation
available in UTS is one induced from the coefficient domain,
which requires the denominator to be in the coefficient domain,
and the division is done termwise to the coefficients of the
series. So '1/x' ends up in 'FRAC POLY INT'. Note that to
obtain a Taylor series at 'x = 0' is mathematically is wrong,
since '1/x' is not defined at 'x=0'. Also the way to obtain a
Taylor series is 'taylor(func, x=a)'. If you do
'integrate(taylor(1/x,x=1),x)', that would cause no problems.
Note that the domain of this command is 'UTS(EXPR INT, x,1)',
so such towers are valid and necessary in Axiom. Note also
there are only two 'exported[coerce]' in UTS and they do NOT
apply to '1/x'. The 'x' in UTS is like the 'x' in UP and is
different from the 'x' in 'FRAC POLY INT'. The representation
is 'Stream Coef' (no variable specified because it is univariate).
For the same reason, in the second command, '1/y' is correctly
coerced into 'FRAC POLY INT'. However, in 'UTS(*,x,*)', the only
integrations allowed are with respect to 'x'. If you want to do
integration in 'FRAC POLY INT', then you should do so without
coercing '1/y' into UTS.
So your examples do not illustrate the problem about mixed up
variables. In fact, it supports use of towers like
'UTS(EXPR INT, x, a)'.
William (address@hidden)

forwarded from http://wiki.axiomdeveloper.org/address@hidden