[Axiom-math] Curious behavior of Taylor series

Post by Igor Khavkine
Can someone explain the following behavior of Taylor series in Axiom?
(113) -> y := taylor x
(113) x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(114) -> x*y
(114) x x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(115) -> coefficient(%,1)
(115) x
Type: Expression Integer

The reason is that Axiom cannot really know whether you meant x in (114) to be
an element of the coefficient Ring EXPR INT, or to be a univariate Taylor
series. In case of doubt, it usually chooses the wrong possibility :-)

Thus, you should help Axiom by saying

monomial(1,1)$UTS(EXPR INT,x,0) * y

Post by Igor Khavkine
I've been trying to write a routine that takes some expression f(x,y), but
possibly containing other symbolic constants, and then solves the implicit
equation f(x,y)=0 for y as a Taylor series in x. The above behavior has
proved to be an obstacle.

I think such a routine already exists - at least if f(x, y) involves only
powers and derivatives of y. Look at seriesSolve. If you need more help or
examples, ask again. If I'm wrong, tell me so :-)

Martin

Igor Khavkine

2006-08-20 22:22:50 UTC

I think such a routine already exists - at least if f(x, y) involves only
powers and derivatives of y. Look at seriesSolve. If you need more help or
examples, ask again. If I'm wrong, tell me so :-)

Not that I could find. The only package that defines seriesSolve is
ExpressionSpaceODESolver and it complains if you give it an "ODE"
without derivatives.

Igor

Jay Belanger

2006-08-21 01:38:58 UTC

When multiplying two elements, shouldn't Axiom try to coerce them to
be in the same structure? (I realize it doesn't, particularly here,
but wouldn't that be reasonable behavior?)

Jay

Ralf Hemmecke

2006-08-21 07:37:46 UTC

When multiplying two elements, shouldn't Axiom try to coerce them to
be in the same structure? (I realize it doesn't, particularly here,
but wouldn't that be reasonable behavior?)

But Axiom coerced the two x to the same domain!!! The first x is a
coefficient, and the second x is the variable from the Taylor series. So
you cannot complain.

The only problem is that it is terribly confusing. Unfortunately, I
cannot even blame that the user did anything wrong since Axiom came up
with this strange type UnivariateTaylorSeries(Expression Integer,x,0).

But I could blame the user for trying to do "x * y". Here you instruct
the compiler to guess since there is no function

*: (Symbol, UTS(Expression Integer,x,0))->UTS(Expression Integer,x,0)

so the interpreter has to do something with the x. It coerces it to
Expression(Integer). That is perfectly legal. But it is probably not
what you want. Once again. The result "x x" for "x*y" shows two DIFFERENT x.

Ralf

Jay Belanger

2006-08-21 16:27:22 UTC

When multiplying two elements, shouldn't Axiom try to coerce them to
be in the same structure? (I realize it doesn't, particularly here,
but wouldn't that be reasonable behavior?)

But Axiom coerced the two x to the same domain!!!

Not in any meaningful way. What I think should have happened is
something like

(1) -> y := taylor x

(1) x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(2) -> (x::UnivariateTaylorSeries(Expression Integer,x,0))*y

2
(2) x
Type: UnivariateTaylorSeries(Expression Integer,x,0)

(without the cast having to be explicit).
The only real experience I have with domains is in MuPAD, and this is
roughly how MuPAD handles it.

Post by Ralf Hemmecke
The first x is a coefficient, and the second x is the variable from
the Taylor series. So you cannot complain.

Oh, I can always complain. The only question is whether or not my
complaints are justified.

Post by Ralf Hemmecke
The only problem is that it is terribly confusing. Unfortunately, I
cannot even blame that the user did anything wrong since Axiom came up
with this strange type UnivariateTaylorSeries(Expression Integer,x,0).
But I could blame the user for trying to do "x * y". Here you instruct
the compiler to guess since there is no function
*: (Symbol, UTS(Expression Integer,x,0))->UTS(Expression Integer,x,0)
so the interpreter has to do something with the x. It coerces it to
Expression(Integer). That is perfectly legal.

But not perfectly reasonable, I think. And it isn't coercing x to be
in the same domain as the other x, which is what I think should happen.

Jay

Ralf Hemmecke

2006-08-21 16:57:17 UTC

When multiplying two elements, shouldn't Axiom try to coerce them to
be in the same structure? (I realize it doesn't, particularly here,
but wouldn't that be reasonable behavior?)

But Axiom coerced the two x to the same domain!!!

Not in any meaningful way.

Well, but how can you tell this to Axiom? It should be impossible to
construct the domain UnivariateTaylorSeries(Expression Integer,x,0).
I guess the Axiom designers thought that returning that domain for
taylor x would be reasonable. I must say, I question that.
UTS(Fraction Integer, x, 0) would have been sufficient and you wouldn't
have the trouble.

Post by Jay Belanger
What I think should have happened is something like
(1) -> y := taylor x
(1) x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(2) -> (x::UnivariateTaylorSeries(Expression Integer,x,0))*y
2
(2) x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(without the cast having to be explicit).

Oh, interesting! Then the interpreter is to blame for chosing the wrong
coerce function.

But see, x is a symbol which should be coerce into a Taylor series. The
interpreter has several choices. So assuming the ideal that the
interpreter should have no mathematical knowledge itself, it can only
take the available information from the library. But there are several
available ways to go from x to UTS(Expression Integer,x,0). So how can
the interpreter ever know that it does the wrong thing?

Post by Ralf Hemmecke
The first x is a coefficient, and the second x is the variable from
the Taylor series. So you cannot complain.

Oh, I can always complain. The only question is whether or not my
complaints are justified.

But not perfectly reasonable, I think.

A program like Axiom does not "reason". Is simply follows "stupid"
instructions.

Post by Jay Belanger
And it isn't coercing x to be in the same domain as the other x, which
is what I think should happen.

Well, what should happen is, that Axiom users should not be confronted
with such terribly confusing stuff. First the user should learn that
Expression Integer is very very dangerous (as you can see) if used in
connection with a polynomial or powerseries domain.

One cannot ban Expression(Integer) from Axiom since it is quite powerful
in general, but Expression(Integer) is also a bit like trying to avoid
types in a strongly typed system. To my taste, working with
Expression(Integer) is like working in Mma or Maple. So one shoudn't be
surprised.

Ralf

Martin Rubey

2006-08-21 17:18:14 UTC

Well, but how can you tell this to Axiom? It should be impossible to construct
the domain UnivariateTaylorSeries(Expression Integer,x,0).
I guess the Axiom designers thought that returning that domain for taylor x
would be reasonable. I must say, I question that.
UTS(Fraction Integer, x, 0) would have been sufficient and you wouldn't have
the trouble.

No, I disagree. As long as we don't have domains UnivariateExpression and
MultivariateExpression that take variables as parameters, things like UTS(EXPR
INT, x, 0) are necessary.

Otherwise you cannot create series like

(67) -> series(sin(y+x), x=0)

(67)
sin(y) 2 cos(y) 3 sin(y) 4 cos(y) 5
sin(y) + cos(y)x - ------ x - ------ x + ------ x + ------ x
2 6 24 120
+
sin(y) 6 cos(y) 7 sin(y) 8 cos(y) 9 sin(y) 10 11
- ------ x - ------ x + ------ x + ------ x - ------- x + O(x )
720 5040 40320 362880 3628800
Type: UnivariatePuiseuxSeries(Expression Integer,x,0)

I agree that taking EXPR INT as the default domain is a bad idea though.

I think there is one important point for MMA, Maple and MuPAD to make: as long
as the mathematics of a particular topic is unclear, good expression domains
are useful and sometimes maybe even necessary. Of course, once the mathematics
is well understood, for example, as is the case with DFinite functions (as is
the case with sin(x+y), an appropriate domain should be created and used. But
for the discovery, I believe that "insecure" domains are very useful. In my
opinion, especially MuPAD got this very right.

By the way, just today I was led to use the domain SUP SUP INT. (In code, of
course)

As soon as one realizes that different things may generate the same output
(printed representation), most of the problems go away.

I had very long discusssions with William Sit about that topic on this list,
and I have to admit that I now agree with him :-)

Martin

Ralf Hemmecke

2006-08-21 20:00:13 UTC

Well, but how can you tell this to Axiom? It should be impossible to construct
the domain UnivariateTaylorSeries(Expression Integer,x,0).
I guess the Axiom designers thought that returning that domain for taylor x
would be reasonable. I must say, I question that.
UTS(Fraction Integer, x, 0) would have been sufficient and you wouldn't have
the trouble.

Looking at this thing I would say that if you take

R = Q[s,c] -- polynomial ring in two variables over rationals
I = (s^2+c^2-1)R -- ideal in R
A = R/I -- factor structure
S = A[[x]] -- formal power series

then S would be a perfect candidate for the result type of the above
expression. And there is no "Expression Integer".
While constructing the result of "series", Axiom should try hard to get
a reasonable (in some sense minimal) type for the result.
Note that you get "PositiveInteger if you just type 1 on the axiom

Post by Martin Rubey
I agree that taking EXPR INT as the default domain is a bad idea though.

I think, we are on the same side anyway. ;-)

Post by Martin Rubey
I think there is one important point for MMA, Maple and MuPAD to make: as long
as the mathematics of a particular topic is unclear, good expression domains
are useful and sometimes maybe even necessary.

Good point and I agree wholeheatedly. But Axiom allows after
understanding the structure of things to encode even that structure
(into the type system). The latter is THE feature of Axiom and should
not be forgotten due to laziness.

Post by Martin Rubey
By the way, just today I was led to use the domain SUP SUP INT. (In code, of
course)

What is so special about that? It is just Z[x][y], only that the names
of x an y are not given. If you, however, think of a univariate
polynomial ring over a ring R as the collection of functions N -> R with
finite support, you don't even see the x or y.

Ralf

Igor Khavkine

2006-08-21 20:14:51 UTC

Post by Martin Rubey
(67) -> series(sin(y+x), x=0)
(67)
sin(y) 2 cos(y) 3 sin(y) 4 cos(y) 5
sin(y) + cos(y)x - ------ x - ------ x + ------ x + ------ x
2 6 24 120
+
sin(y) 6 cos(y) 7 sin(y) 8 cos(y) 9 sin(y) 10 11
- ------ x - ------ x + ------ x + ------ x - ------- x + O(x )
720 5040 40320 362880 3628800
Type: UnivariatePuiseuxSeries(Expression Integer,x,0)

Looking at this thing I would say that if you take
R = Q[s,c] -- polynomial ring in two variables over rationals
I = (s^2+c^2-1)R -- ideal in R
A = R/I -- factor structure
S = A[[x]] -- formal power series
then S would be a perfect candidate for the result type of the above
expression. And there is no "Expression Integer".
While constructing the result of "series", Axiom should try hard to get
a reasonable (in some sense minimal) type for the result.

That is in deed a very nice way to characterize the coefficients of of
this power series. But how exactly would you coax Axiom into producing
a power series with coefficients of this type starting with sin(x+y)?
It'd also be nice if the variables s and c printed as sin(y) and
cos(y) and behaved the same under operations like, say, taking
derivatives with respect to y.

Igor

Ralf Hemmecke

2006-08-21 21:11:31 UTC

Post by Igor Khavkine

10 11

Post by Martin Rubey
- ------ x - ------ x + ------ x + ------ x - ------- x +

O(x )

Post by Martin Rubey
720 5040 40320 362880 3628800
Type: UnivariatePuiseuxSeries(Expression

Integer,x,0)
Looking at this thing I would say that if you take
R = Q[s,c] -- polynomial ring in two variables over rationals
I = (s^2+c^2-1)R -- ideal in R
A = R/I -- factor structure
S = A[[x]] -- formal power series
then S would be a perfect candidate for the result type of the above
expression. And there is no "Expression Integer".
While constructing the result of "series", Axiom should try hard to get
a reasonable (in some sense minimal) type for the result.

I certainly could not, because all you have given me is the string of 7
letters "sin(x+y)". It is already a GUESS to interpret this as the
mathematical sine function applied to a sum of two indeterminates. So,
unless you give me the type of that thing, I cannot do anything without
guessing. And please, not Expression(Integer), because that basically
says nothing.

And by the way, I would probably also fail if you give me a proper type,
since that stuff is not my main field and I have no algorithm for it.

Post by Igor Khavkine
It'd also be nice if the variables s and c printed as sin(y) and
cos(y) and behaved the same under operations like, say, taking
derivatives with respect to y.

I somehow have the suspicion that you still think in terms of expressions.

Suppose I take the rational numbers Q considered as a Ring.

)abbrev domain Q Q
Q: Ring == Fraction Integer add
foo(): Integer == 1

Put these 3 lines into qqq.spad and say
)co qqq.spad

Now if you take

a: Q := 1
c: Q := a/a

then... right! that gives an error because there is no operation

/: (Q, Q) -> Q

What I want to say is, that having a type of a thing imposes a certain
structure on that thing and also restricts on what you can to with it.
So although you know that Q (from above) is the set of rational numbers,
you cannot divide two elements of Q. Same for c an s from my example
above. They are just indeterminates. If you want something else, then
you have to make that obvious.

OK, I would agree that for the enduser all this type stuff must be made
easier and more transparent. In some cases it probably even hinders the
exploration of the mathematics behind the stuff, but when it comes to
code your ideas into an algorithm then types are quite useful. Then you
should not "lie" anymore, but make it explicit what you actually mean.

Ralf

Jay Belanger

2006-08-21 19:43:11 UTC

When multiplying two elements, shouldn't Axiom try to coerce them to
be in the same structure? (I realize it doesn't, particularly here,
but wouldn't that be reasonable behavior?)

But Axiom coerced the two x to the same domain!!!

Looking back, it didn't. One of the x's is in Expression Integer, and
the other is UTS.

Post by Jay Belanger
Not in any meaningful way.

Well, but how can you tell this to Axiom?

Axiom could try to coerce x to be the same type as y, or y to be the
same type as x. The latter would lose structure, and should fail.
So x should be coerced to the same domain as y.

Post by Ralf Hemmecke
It should be impossible to construct the domain
UnivariateTaylorSeries(Expression Integer,x,0). I guess the Axiom
designers thought that returning that domain for taylor x would be
reasonable. I must say, I question that. UTS(Fraction Integer, x,
0) would have been sufficient and you wouldn't have the trouble.

Yes. I obviously need to learn more to find out what's going on
here.

Post by Ralf Hemmecke
But see, x is a symbol which should be coerce into a Taylor
series. The interpreter has several choices. So assuming the ideal
that the interpreter should have no mathematical knowledge itself,
it can only take the available information from the library. But
there are several available ways to go from x to UTS(Expression
Integer,x,0). So how can the interpreter ever know that it does the
wrong thing?

The problem is that it didn't even try to go from x to UTS; x ends up
as an Expression Integer. I think it should have tried coercing x
before multiplying x and y.

Post by Jay Belanger
And it isn't coercing x to be in the same domain as the other x, which
is what I think should happen.

It is dangerous to use Expression Integer as above, but I don't think
it should be. I think the commands at the beginning of this thread
were reasonable and should work.

Jay

Ralf Hemmecke

2006-08-21 20:21:03 UTC

Post by Igor Khavkine
(113) -> y := taylor x
(113) x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(114) -> x*y
(114) x x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(115) -> coefficient(%,1)
(115) x

But Axiom coerced the two x to the same domain!!!

Looking back, it didn't. One of the x's is in Expression Integer, and
the other is UTS.

In some sense you are rigth, BUT, for that to claim you would have to
know the internal representation of
UnivariateTaylorSeries(Expression Integer,x,0).
What if you are a poor Axiom user who doesn't have access to the source
code? How could you justify your statement. All you see is ONE type and
that is UnivariateTaylorSeries(Expression Integer,x,0) and nothing else.

Post by Ralf Hemmecke
Well, but how can you tell this to Axiom?

Axiom could try to coerce x to be the same type as y, or y to be the
same type as x. The latter would lose structure, and should fail.
So x should be coerced to the same domain as y.

As I said, Axiom does exactly that. But it has (at least two)
incompatible ways to do it. Maybe someone familiar with tracing the
search of the interpreter for the right coerce function could explain
that better than me.

The problem is that it didn't even try to go from x to UTS; x ends up
as an Expression Integer. I think it should have tried coercing x
before multiplying x and y.

Let's abbreviate U := UnivariateTaylorSeries(Expression Integer,x,0) and
E := Expression(Integer).

That's what Axiom does. It tries to coerce to U, there is no such coerce
function. Then maybe after checking some other coerce functions that
fail, it finds a coercion to Expression(Integer), furthermore there is
function *: (E, U) -> U. So Axiom does a minimal thing: it interprets

x*y as (x::E)*y

note that the coercion to U would go like

(x::E::U) * y

and would then be more costly. You surely also consider that
unreasonable to go the long way if there is a shorter path. No?

Post by Jay Belanger
It is dangerous to use Expression Integer as above, but I don't think
it should be. I think the commands at the beginning of this thread
were reasonable and should work.

You are talking to a computer not a human. Have mercy.

Ralf

Jay Belanger

2006-08-22 16:17:36 UTC

...

Post by Igor Khavkine

Post by Ralf Hemmecke
But Axiom coerced the two x to the same domain!!!

Looking back, it didn't. One of the x's is in Expression Integer, and
the other is UTS.

I was looking at the Type: part of the output in (113) and (115).

Post by Igor Khavkine
Well, but how can you tell this to Axiom?

Axiom could try to coerce x to be the same type as y, or y to be the
same type as x. The latter would lose structure, and should fail.
So x should be coerced to the same domain as y.

As I said, Axiom does exactly that.

Did you? Well, I guess I need to be told several times before it
sinks in. Maybe if I learned to read, I could have saved up both
some typing. But thanks for your patience.

Post by Igor Khavkine
But see, x is a symbol which should be coerce into a Taylor
series. The interpreter has several choices. So assuming the ideal
that the interpreter should have no mathematical knowledge itself,
it can only take the available information from the library. But
there are several available ways to go from x to UTS(Expression
Integer,x,0). So how can the interpreter ever know that it does the
wrong thing?

The problem is that it didn't even try to go from x to UTS; x ends up
as an Expression Integer. I think it should have tried coercing x
before multiplying x and y.

Let's abbreviate U := UnivariateTaylorSeries(Expression Integer,x,0) and
E := Expression(Integer).
That's what Axiom does. It tries to coerce to U, there is no such coerce
function.

But x::U works just fine.

Post by Ralf Hemmecke
Then maybe after checking some other coerce functions that
fail, it finds a coercion to Expression(Integer), furthermore there is
function *: (E, U) -> U. So Axiom does a minimal thing: it interprets
x*y as (x::E)*y
note that the coercion to U would go like
(x::E::U) * y

So x::U is equivalent to x::E::U?

Post by Ralf Hemmecke
and would then be more costly. You surely also consider that
unreasonable to go the long way if there is a shorter path. No?

I'm just wondering why it doesn't try x::U right off.
I'm getting the (probably wrong) impression that it looks at x::U,
decides that that's too long, then goes for x::E. I would think that
deciding x::U is too long would be too long.

Jay

Ralf Hemmecke

2006-08-22 16:58:02 UTC

Post by Ralf Hemmecke
Let's abbreviate U := UnivariateTaylorSeries(Expression Integer,x,0) and
E := Expression(Integer).
That's what Axiom does. It tries to coerce to U, there is no such coerce
function.

But x::U works just fine.

Try the same thing in a .spad file and the compiler will complain.
(Better use a .as file and compile with Aldor. I cannot say much about
SPAD, since I don't know for sure.)

x::U on a command line is given to the interpreter. The interpreter
tries to be smart and tries hard to find a way to achieve what it
believes you meant.

So x::U is equivalent to x::E::U?

I cannot say for sure. Some other Axiom gurus know how to ask axiom what
exact function call the interpreter actually finds. I don't. Keep
waiting or write to the axiom-developer mailing list. I am sure someone
is listening.

Post by Ralf Hemmecke
and would then be more costly. You surely also consider that
unreasonable to go the long way if there is a shorter path. No?

I'm just wondering why it doesn't try x::U right off.

Maybe it does. But as I said. There is no function coerce: Symbol->U.
So it fails and has to look for something else.

Post by Jay Belanger
I'm getting the (probably wrong) impression that it looks at x::U,
decides that that's too long, then goes for x::E. I would think that
deciding x::U is too long would be too long.

Try to write an interpreter then you (maybe) appreciate what it
currently does and have some mercy with it. ;-)

Ralf

Igor Khavkine

2006-08-21 09:49:33 UTC

The reason is that Axiom cannot really know whether you meant x in (114) to be
an element of the coefficient Ring EXPR INT, or to be a univariate Taylor
series. In case of doubt, it usually chooses the wrong possibility :-)
Thus, you should help Axiom by saying
monomial(1,1)$UTS(EXPR INT,x,0) * y

OK, but the following definitely looks like a bug.

(279) -> monx := monomial(1,1)$UTS(EXPR INT,x,0)
(279) x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(281) -> sqrt(monx*monx)
(281) ->
(281) 1
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(282) -> serx := series x
(282) ->
(282) x
Type: UnivariatePuiseuxSeries(Expression Integer,x,0)
(283) -> sqrt(serx*serx)
(283) ->
(283) x
Type: UnivariatePuiseuxSeries(Expression Integer,x,0)

It looks like sqrt(), when applied to UTS, shifts the coefficients so
that the leading term is always O(1). In the example above, it should
be O(x). The UPXS domain doesn't seem to suffer from the same problem.

Igor

Martin Rubey

2006-08-21 10:01:55 UTC

Post by Igor Khavkine
OK, but the following definitely looks like a bug.
(279) -> monx := monomial(1,1)$UTS(EXPR INT,x,0)
(279) x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(281) -> sqrt(monx*monx)
(281) ->
(281) 1
Type: UnivariateTaylorSeries(Expression Integer,x,0)

Yes, that's a bug. Please submit a report and fix it :-)

you can see what's going on by saying

)tr UTS )ma

However, it seems that sqrt is not defined in UTS itself. So you'll have to
find out where it is defined and that trace that constructor.

If you need more support, please ask for it.

By the way, the bug even occurs if you work in UTS(FRAC INT, x, 0) :-(

Martin

Igor Khavkine

2006-08-21 19:13:02 UTC

Yes, that's a bug. Please submit a report and fix it :-)
you can see what's going on by saying
)tr UTS )ma
However, it seems that sqrt is not defined in UTS itself. So you'll have to
find out where it is defined and that trace that constructor.
If you need more support, please ask for it.

I've filed a bug report (#312) and I have a tentative fix for it. But
I'm having trouble testing it. I've copied the culprit file
algebra/sttaylor.spad into my current working dir and modified it.
Issuing the command )compile sttaylor compiled the file. However, the
old definition of sqrt is still being invoked. How do I force the code
from sttaylor.spad in my working directory to take priority?

Thanks.

Igor

Martin Rubey

2006-08-21 19:21:36 UTC

I've filed a bug report (#312) and I have a tentative fix for it. But I'm
having trouble testing it. I've copied the culprit file algebra/sttaylor.spad
into my current working dir and modified it. Issuing the command )compile
sttaylor compiled the file. However, the old definition of sqrt is still
being invoked. How do I force the code from sttaylor.spad in my working
directory to take priority?

That's very strange, usually, after compilation, the new definition replaces
the old. You can also say

)lib CONSTRUCTORNAME

to load it explicitely.

Are you sure you modified the right operation? Using

)tr STTAYLOR )ma

I get the trace below. I suspect you modified powern?

Maybe you could send me the modification, then I can look at it.

BTW: Thanks a lot for looking at this!

Martin

(5) -> sqrt(monx*monx)
1<enter StreamTaylorSeriesOperations.*,27 :
arg1= [...]
arg2= [...]
1>exit StreamTaylorSeriesOperations.*,27 :
[...]
1<enter StreamTaylorSeriesOperations.powern,117 :
1
arg1= -
2
arg2= [...]
1<enter StreamTaylorSeriesOperations.*,26 :
arg1= 0
arg2= [...]
1>exit StreamTaylorSeriesOperations.*,26 :
[]
1<enter StreamTaylorSeriesOperations.*,27 :
arg1= [...]
arg2= [...]
1>exit StreamTaylorSeriesOperations.*,27 :
[...]
1<enter StreamTaylorSeriesOperations.+,17 :
arg1= []
arg2= [...]
1>exit StreamTaylorSeriesOperations.+,17 :
[...]
1<enter StreamTaylorSeriesOperations.*,26 :
arg1= 1
arg2= [...]
1>exit StreamTaylorSeriesOperations.*,26 :
[...]
1<enter StreamTaylorSeriesOperations.*,27 :
arg1= []
arg2= [...]
1>exit StreamTaylorSeriesOperations.*,27 :
[...]
1<enter StreamTaylorSeriesOperations.+,17 :
arg1= [...]
arg2= [...]
1>exit StreamTaylorSeriesOperations.+,17 :
[...]
1>exit StreamTaylorSeriesOperations.powern,117 :
[...]

1<enter StreamTaylorSeriesOperations.deriv,62 :
arg1= [...]
1<enter StreamTaylorSeriesOperations.int,59 :
arg1= 1
1>exit StreamTaylorSeriesOperations.int,59 :
[...]
1<enter StreamTaylorSeriesOperations.mapmult,60 :
arg1= [...]
arg2= []
1>exit StreamTaylorSeriesOperations.mapmult,60 :
[...]
1>exit StreamTaylorSeriesOperations.deriv,62 :
[...]
1<enter StreamTaylorSeriesOperations.*,27 :
arg1= [...]
arg2= [...]
1>exit StreamTaylorSeriesOperations.*,27 :
[...]
1<enter StreamTaylorSeriesOperations.*,27 :
arg1= []
arg2= [...]
1>exit StreamTaylorSeriesOperations.*,27 :
[...]
1<enter StreamTaylorSeriesOperations.-,23 :
arg1= [...]
arg2= [...]
1>exit StreamTaylorSeriesOperations.-,23 :
[...]
(5) 1
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(6) ->

Igor Khavkine

2006-08-21 19:55:10 UTC

I've filed a bug report (#312) and I have a tentative fix for it. But I'm
having trouble testing it. I've copied the culprit file algebra/sttaylor.spad
into my current working dir and modified it. Issuing the command )compile
sttaylor compiled the file. However, the old definition of sqrt is still
being invoked. How do I force the code from sttaylor.spad in my working
directory to take priority?

That's very strange, usually, after compilation, the new definition replaces
the old. You can also say

You're right, that's what was happening. But my initial modification
was in the wrong place, so it wasn't being triggered. But I've found
the right place for it and it seems to work.

Post by Martin Rubey
I suspect you modified powern?
Maybe you could send me the modification, then I can look at it.

I'm attaching the patch. It's very small. The original author simply
forgot to prepend the leading zeros before returning the power series.

Post by Martin Rubey
BTW: Thanks a lot for looking at this!

No problem.

Igor

Ralf Hemmecke

2006-08-20 21:53:06 UTC

Post by Igor Khavkine
Can someone explain the following behavior of Taylor series in Axiom?
(113) -> y := taylor x
(113) x
Type: UnivariateTaylorSeries(Expression Integer,x,0)

There are only two functions "taylor" in Axiom with one argument. I
assume that your x is a Symbol so the return type should be Any.

"Any" basically says that you work without types, or rather Any boxes
the value together with its type. Its like an object knowing its type.

Post by Igor Khavkine
(114) -> x*y
(114) x x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(115) -> coefficient(%,1)
(115) x
Type: Expression Integer

We have gone through that before.

William Sit

2006-08-30 10:25:02 UTC