axiom-math
[Top][All Lists]
Advanced

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

Re: [Axiom-math] Curious behavior of Taylor series


From: Ralf Hemmecke
Subject: Re: [Axiom-math] Curious behavior of Taylor series
Date: Mon, 21 Aug 2006 23:11:31 +0200
User-agent: Thunderbird 1.5.0.5 (X11/20060719)

> (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)?

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.

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




reply via email to

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