[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] a problem, maybe with strict typing
From: |
William Sit |
Subject: |
Re: [Axiom-developer] a problem, maybe with strict typing |
Date: |
Thu, 21 Dec 2006 15:48:20 -0500 |
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] a problem, maybe with strict typing, Martin Rubey, 2006/12/18
- Re: [Axiom-developer] a problem, maybe with strict typing, William Sit, 2006/12/18
- Re: [Axiom-developer] a problem, maybe with strict typing, Martin Rubey, 2006/12/18
- Re: [Axiom-developer] a problem, maybe with strict typing, William Sit, 2006/12/18
- Re: [Axiom-developer] a problem, maybe with strict typing, Martin Rubey, 2006/12/19
- Re: [Axiom-developer] a problem, maybe with strict typing, William Sit, 2006/12/19
- Re: [Axiom-developer] a problem, maybe with strict typing, Martin Rubey, 2006/12/20
- Re: [Axiom-developer] a problem, maybe with strict typing,
William Sit <=