bugAxiom Computer Algebra System - Bugs: bug #10350, integrating UTS

 
 

You are not allowed to post comments on this tracker with your current authentification level.

bug #10350: integrating UTS

Submitted by:  Martin Rubey <kratt6>
Submitted on:  Sat 11 Sep 2004 12:34:23 PM UTC  
 
Category: algebraSeverity: 3 - Normal
Item Group: code bugStatus: transferred
Privacy: PublicAssigned to: None
Originator Name: Martin RubeyOpen/Closed: Open
Release: Reproducibility: None
Fixed Release: 
Error message: 
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)

Internal cause: 

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 02 Oct 2004 12:09:22 PM UTC, 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 (dpt@math.harvard.edu)

Anonymous
Sat 02 Oct 2004 08:33:01 AM UTC, 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 (wyscc@cunyvm.cuny.edu)

Anonymous
Sat 11 Sep 2004 12:34:23 PM UTC, original submission:

integrate((1/x)::UTS(FRAC POLY INT, x, 0),x)

1
(11) - x
x
Type: UnivariateTaylorSeries(Fraction Polynomial Integer,x,0)

integrate((1/y)::UTS(FRAC POLY INT, x, 0),z)

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

Martin Rubey <kratt6>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sat 18 Feb 2006 12:56:17 PM UTCbillpage1StatusNone=>transferred
  Example of code trigerring the bugintegrate((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) integrate((1/y)::UTS(FRAC POLY INT, x, 0),z)

Back to the top


Powered by Savane 3.1-cleanup