Martin Rubey wrote: > it seems that I am quite difficult to understand. ... The > package is attached below.
I would agree :-). Since you already have the package, I don't know why you are asking these questions! Actually, after a preliminary reading your package, I have more questions than answers. I have not yet tried your package and most likely, all these questions may go away once I do that. > Replace Aldor with SPAD if you like. But it seems to me that there is more > hope to make things > "generic" in Aldor... I'm not sure about that. I am not convinced that Aldor is a more powerful language. It may have a better compiler though (better error messages). But we have been through this, too. > No, I didn't omit anything I need. Even if R = UTS(FRAC INT, x, 0), i.e., R > has TRANFUN, I > don't want to teach SUPEXPR to do something with sin(1+?*x). I guess you > meant 1+?*x would be > in SUPEXPR R. Obviously, 1+?*x is not in R, thus SUPEXPR *should* throw an > error. >From a user viewpoint, I was surprised that the authors of UTS and UPXS would >allow a coefficient domain that does not have enough transcendental constants to be lifted to a series domain with transcendental functions. In your case, if you are not teaching SUPEXPR anything (including expanding sin(1+?*x) in series) then I don't know why you need SUPEXPR or what it is for. Do you mean just to "make" a domain similar to SUP F but just say it belong to the category TRANFUN, without actually being so (much like UTS)? Don't you need to expand things in series at all? Even if you are relegating the users to provide the series map, where do you expect them to obtain the series other than starting with EXPR? > > The signature you proposed probably won't be ideal for the user because if > > the map argument in solve involves transcendental functions, you will be in > > trouble when it is to be evaluated. > > No. As long as F is "large" enough, it just works. Well how "large"? Including transcendental constants? Which domain has them besides EXPR? > > The problem you are interested in has nothing to do with differential > > equations (it may have an application to differential equation) because it > > is > > just solving an implicit equation in series or power series. So all that is > > needed is an expression giving the implicit equation, where the dependent > > and > > independent variables are given. > > Yes. Do you restrict the implicit equation to be polynomial? Why do you consider an implicit equation as a map from UTS to UTS? Say I want to solve the implicit equation x y(x) = 1 in power series around x=1. Do you want me to create a map from UTS(INT,x,1) to UTS(INT,x,1) by sending a series s(x) to x s(x) - 1? And you would not allow implicit equation such as sin(y(x))=sqrt(x) be entered that way, but you require the user to create a map sending a series s(x) to the series expansion of sin(s(x))-sqrt(x) (so the user is responsible for the series expansion)? And what would be the implicit equation you are to solve if the user actually inputs some map that say takes a series s(x) = c0 + c1 (x-1) + t(x) (where t(x) is the tail end of s(x)) to the series c1 + c0(x-1) + t(x) (or some other ways of mangling the series such as swapping all even-indexed coefficients with previous odd-coefficients and the result combined with other operations)? > > > Could you please try to re-phrase what you mean with > > > > If you require your user to give input functions directly from > > > GR:=UPS(F,x,a), you will need to first "embed" GR to SGR:=UPS(SUP > > > F,x,a), > > > > in particular, to make things precise, could you give the signature you > > > propose for solve(...)? > > > Not sure what you are puzzled about. By "give input functions directly from > > GR", I mean allowing the implicit equation to be given by expressions > > involving a power series, which is probably a bad idea anyway since > > equations > > are generally not given that way. The series expansion of any special or > > transcendental function should be dealt with by the solve package (that is, > > you). > > I don't understand. Nowhere I suggested to deal with expressions involving > power series - assuming that, with "expressions" you refer to something like > EXPR. So far I only considered maps from UTS -> UTS and, somewhat > alternatively, elements of a FunctionSpace that I interpret as maps UTS -> > UTS. Even in UTS, which is of category TRANFUN, you are allowed to form "expressions" like sin, cos, etc with arguments in UTS and supposedly returning elements in UTS. But unless the coefficient ring has transcendental constants, sin and cos, etc. simply don't work in UTS. But, there is nothing to prevent a user to use transcendental functions in the implicit equation (especially if the implicit equation is not actually evaluated). Moreover, as indicated above, maps from UTS to UTS can be very general and need not be given by a "formula" involving the argument s(x) in UTS, but by an infinite stream of formulae for its (new) coefficients. And, if you allow using f: UTSSUPF -> UTSSUPF, what is the implicit equation if f(s(x)) involves the main variable in SUP F? Why do you treat f as if it has two arguments, as in f(x,y(x))? Is y(x) being substituted into the main variable of SUP F? In that case, why must f involve it? Are there any restrictions on f for your package? > > If you are asking about "embed", then perhaps you like the language of > > category theory? Treat UTS(-,x,a) (sorry, UPS is not the correct > > abbreviation) as a functor from Ring to Ring. Then we have the following > > diagram: > > > F -----> UTS(F,x,a) > > id | | map > > v v > > SUP(F) ---> UTS(SUP(F),x,a) > > In this picture, I guess that elements f of F are really implicit equations > defining y(x) which get mapped to the power series expansion of the function > y(x)? No, I said treat UTS(-,x,a) as a functor. So the arrow F ----> UTS(F,x,a) simply associates a ring F (an object of the ring category) with another ring UTS(F,x,a). In math notation, suppressing the center a, it takes F to F[[x]]. It is NOT a set map that takes f in F to some g in F[[x]] (even though of course, F can be embedded naturally in F[[x]]). The map id is a SET map that takes f in F to f in SUP(F), thus inducing a SET map from on the right of the diagram. Of course, both id and map are algebra homomorphisms over F. William _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer