Re: [Axiom-developer] a problem, maybe with strict typing

[Martin Rubey]

Dear William,

"William Sit" <address@hidden> writes:

> Martin:
> 
> If I understand your question correctly, at least in the interpreter, there is
> no need to go to SUP F, especially for domains like F = EXPR INT. In the
> example you give,

So, you would check whether F allows a "transcendental" element (i.e., another
variable)? That doesn't look very "clean" to me. (I'm writing a package, by the
way...)

> > Now let F be EXPR INT, or, in fact, any domain that has TRANFUN. Already
> > series
> > as simple as g +-> sin g - sin 1, g(0) = 1 fail:
> 
> it would be possible to "find g" with enough initial data using, with t
> standing for the next undetermined coefficient
> 
> taylor(sin(1+t*x)-sin(1),x=0)
>      t cos(1)x - O(x^2)  Now you want this to be zero, say. so t = 0.  You 
> then
> iterate:
> 
> taylor(sin(1 + t*x^2) - sin(1), x=0)
> 
> and of course you get g = 1.  

Yes, that's what I do.

> Now if you want to write a package, you do not want to fix the variable x
> (which a user of your package may use t, for example). However, assuming you
> are only using input functions (like z and initial data) that are univariate 
> in
> EXPR INT, 

I definitely don't want to restrict to EXPR INT.  It should work with any
domain that has TRANFUN.

> you can extract the main variable, and assign it to x (in your package).  Let
> axiom generate a new symbol and assign it to t, which will be different from
> x (even if the user also uses t for his main variable, it will be a different
> t). Now you form your partial series for g involving t and x,

So, what will be the coefficient ring of this partial series? I currently use
SUP F. I thought about using EXPR F instead, but this looks rather like a
workaround than a solution. (That's why I asked for a more abstract problem
description, by the way) I think so, because, suppose there is another category
InterestingFunctions. It may well be that EXPR does not export
InterestingFunctions, and then wrapping the coefficient domain with EXPR won't
help. It seems that the present problem is quite close to the problem of
"indeterminates".

> and substitute g for x to form z g. Then compute the resulting series ending
> up in R:=UPXS(EXPR F,x,a) or UPS(EXPR F,x,a), where F can be simply INT.

This rather sounds like replacing my SUP with EXPR.

> (If you require your user to give input functions directly from
> GR:=UPXS(F,x,a) or UPS(F,x,a), you will need to first "embed" gr to
> SGR:=UPXS(SUP F,x,a) or UPS(SUP F,x,a), and you can assign t to the main
> variable of SUP F; then you have to repack everything (just the normal part
> of the series up to the order you need) back into EXPR F before forming the
> series in R).

That sounds interesting, but I don't think I understand. Do you mean I can
"lift" a function from GR -> GR to a function SGR -> SGR? I don't see how this
could be done...

> In any case, you can now compute your undetermine coefficient one at a time
> using arithmetic in EXPR F. The series for g may be retracted to GR. The user
> of your package would not need to know anything about your auxilliary
> variable t.

> Something similar to this can be found in IDEAL (PolynomialIdeals) package
> where we need an auxilliary variable (like your t) to turn inequations h \ne
> 0 into an equation of the form h*t-1 = 0 (here t must not be mixed up with
> user variables). A lot of type conversion is needed between different
> polynomial rings. 

Hm, you mean the code in relationsIdeal(listf : List DPoly): ST ? I must admit
that I find it quite difficult to read. THere couldn't be less documentation, I
suppose.

> So here, you need to write type conversion routines between EXPR INT and UPXS
> or UPS (one direction is given by series or taylor already).



Thanks,

Martin