[Top][All Lists]

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

[Axiom-developer] [#270 integrating UTS] (new) integrating UTS

From: Bill Page
Subject: [Axiom-developer] [#270 integrating UTS] (new) integrating UTS
Date: Sat, 18 Feb 2006 10:35:26 -0600


-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
-Message-ID: <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,
-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:
integrate((1/x)::UTS(FRAC POLY INT, x,0),x)

  Cannot find a definition or applicable library operation named
  integrate with argument type(s)
  UnivariateTaylorSeries(Fraction Polynomial Integer,x,0)
  Variable z


-    _______________________________________________________
-Reply to this item at:
-  <>
-  Message sent via/by Savannah

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

reply via email to

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