Re: Curious behavior of Taylor series

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