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

[William Sit]

Martin Rubey wrote:

> First things first. I had yet another idea, which avoids the problems of EXPR 
> a
> little. To put things into the right setting, I quote our discussion:
>
> > > I definitely don't want to restrict to EXPR INT.  It should work with any
> > > domain that has TRANFUN.
> >
> > No you don't have to, at least not for the user, but I think you must, to do
> > your computation.
>
> However, suppose that there is a domain Holonomic which enables us to compute
> with functions that satisfy an linear differential equation, i.e., there is a
> linear polynomial p such that p(x, y, y',...,y^(n))=0. Holonomic cannot 
> inherit
> from TRANFUN, since tan is not Holonomic, but it still captures a large class
> of trigonometric functions. Furthermore, it is a computable domain, i.e., we
> can automatically check whether an expression is zero. So, it is definitely an
> interesting domain.
>
> Currently I have the signature
>
> solve(UTS SUP F -> UTS SUP F, List F)
>
> where the first argument gives the series expansion of the equation defining 
> my
> series, the second is a list of initial values. For example, I could say
>
> solve(s +-> -s * D(s,2) + D(s)^2 + s*D s, [1,1])
>
> to obtain the exponential generating function for the Bell numbers. There is 
> no
> computation in an "Expression" domain involved here... (Note, furthermore, 
> that
> the necessity of SUP is not really clear for the user here, more on this 
> below)

Speaking for myself, I won't use the expanded series as input from a user. I may
use your function or something similar as a behind-the-scene local function.  As
will be seen in previous discussion and below, series expansions require more 
than
just TRANFUN.

Note your example argument in solve is not a linear polynomial in the 
derivatives
of s. Ignoring that and assuming you are really interested in non-linear ODEs, I
don't see the relevance of transcendental functions unless you allow them in the
coefficients of the ODE. But then you will have trouble evaluating the map in 
the
argument of solve (see below).

> Thus, the signature
>
> solve(UTS EXPR INT -> UTS EXPR INT, List EXPR INT)
>
> is, at least for me, not an option. I could imagine to have
>
> solve(UTS EXPR F -> UTS EXPR F, List F)
>
> but that poses some new problems, since EXPR EXPR INT is "forbidden" in the
> interpreter.

Before we get into the signature of solve, we have to make sure what is to be
computed can be effectively done within the domain. At first I thought
any domain having TRANFUN might be enough for your purpose because afterall, 
such a
domain is supposedly closed under all elementary function operators. Then I 
tried
with UTS(FRAC INT, x, 0):

(1) -> dom:=UTS(FRAC INT,x,0)

   (1)  UnivariateTaylorSeries(Fraction Integer,x,0)
                                                                 Type: Domain

(2) -> dom has TRANFUN

   (2)  true
                                                                Type: Boolean
(3) -> a:=series(1/(1-x),x=0)::dom

                 2    3    4    5    6    7    8    9    10      11
   (3)  1 + x + x  + x  + x  + x  + x  + x  + x  + x  + x   + O(x  )
                           Type: UnivariateTaylorSeries(Fraction Integer,x,0)
(4) -> sin a

   >> Error detected within library code:
   "sincos: series expansion involves transcendental constants"

protected-symbol-warn called with (NIL)
(4) -> sin series(1/(1-x),x=0)

   (4)

     sin(1) + cos(1)x  + (rest omitted)

                        Type: UnivariatePuiseuxSeries(Expression Integer,x,0)

The above shows that even though domains in TRANFUN may have sin SPECIFIED, it 
does
not mean the implementation is possible because the underlying coefficient ring 
(in
my example, FRAC INT) may not have enough constants such as sin(1) to support 
the
construction.  You cannot get around this even if you use UTS(SUP F, x, a) or
UTS(F,x,a) since F, not necessarily, but even if, a domain in TRANFUN, must 
still
have transcendental constants since UTS or SUP is not going to add these to F. 
(You
may however use Float instead of FRAC INT as F, but that gets us into
approximations.)

> -ALDOR 
> QUESTION----------------------------------------------------------------
>
> My "new" idea is to create a new domain SUPEXPR that is like SUP but has
> TRANFUN. That sounds childish, but I think it is not. I would do it as 
> follows:
>
> SUPEXPR(R: Ring):UPOLYC R with
>        if R has TRANFUN then TRANFUN
>
>     add
>
>         sin(p: %): % ==
>             ground? p => coerce sin ground p
>             output(hconcat("Cannot compute sin p for p=", p::OutputForm)
>                   $OutputPackage
>             error "SUPEXPR: sin defined for elements of the coefficient ring
>             only"
>
>         cos(p: %): % ==
>             ground? p => coerce cos ground p
>             output(hconcat("Cannot compute cos p for p=", p::OutputForm)
>                   $OutputPackage
>             error "SUPEXPR: cos defined for elements of the coefficient ring
>             only"
>
> etc. Of course, it would be nice if this could be done generically. But I
> suppose, Aldor cannot do something like this, i.e., define some operations
> generically only for a "subdomain"?
>
> -------------------------------------------------------------------------------
>
> In any case, this seems to do the trick, and should be quite easy to extend.

I am not familiar with Aldor, but what you suggested does not seem to be Aldor
specific (except for "extend").  Note that you avoided the most important 
operation
in the example implementation of sin above: for example, sin(1+?*x), where 
1+?*x is
in R = UTS(FRAC INT, x,0) and presumably SUPEXPR R would have a new symbol ? 
from
UPOLYC R,  would yield an error message, in addition to what I got in the above
test (that is, sin(1) need not be available during a series expansion of sin 
even
if you "extend" the definition of sin in series).

> Now the paragraph I still don't quite understand.
>
> > > > (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...
>
> > F is a subring of SUP F, so if you have a series with coefficients in F,
> > these are in SUP F (basically, "constants" with respect to the "?"
> > variable). Is it trivial to lift a series in GR to SGR? (you can just use
> > "map"). It is only a coercion from a subdomain to a domain. It is NOT 
> > lifting
> > a function from GR -> GR to another function from SGR -> SGR (such lifting
> > would be possible, but not unique unless the image for "?" is decided first,
> > in which case, "map" will do the job too).
>
> The one thing I dislike about the signature
>
>   solve(UTS SUP F -> UTS SUP F, List F)
>
> or
>
>   solve(UTS SUPEXPR F -> UTS SUPEXPR F, List F)
>
> is that the necessity of the constructor SUPEXPR is not really obvious. I'd
> rather have
>
>   solve(UTS F -> UTS F, List F)
>
> and "lift" the mapping to a mapping UTS SUPEXPR F -> UTS SUPEXPR F. Somehow I
> have the feeling that your suggestion above is relevant, however, I don't see
> at all how this can be done. In fact, I doubt that this can be done at all,
> but maybe I'm wrong.

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. I would think a much simpler way of giving the implicit
equation is just an expression in a single variable, something like:
   solve(z:EXPR F, x:Symbol, c:F, g:BasicOperator):UTS(EXPR F,x,c)
The EXPR F in the target is meant to allow for other parametric constants in z, 
and
F is a numerical domain like INT or Float; x is the series variable and c is the
center for the series expansion.

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.
   solve(sin(g(x))- sqrt(x), x,0, g)
would solve g(x) as a series solution in x around 0 for the equation
   sin(g(x) -sqrt(x)=0;
and you may want to allow the first argument to be a list LIST EXPR F:
   solve([g(x) * D(g(x),x,2) + D(g(x),x)^2 + g(x)*D(g(x),x), g(0)-1,
g'(0)-1],x,0,g)
would solve the ODE with initial conditions (but this is really not within the
setup until after one writes down g(x), g'(x), g''(x) in a series with 
undetermined
coefficients; but then for a fixed order, the equations boil down to an 
algebraic
system in the undetermined coefficients. Or, if you don't like the similarity 
with
Mathematica syntax, you can use:
   solve(sin(y) - sqrt(x),x,0,y)
but then you will be using an implicit convention that y depends on x.

> 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(...)?
>
> Many thanks,
>
> Martin

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).

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)

So the map in the picture is just UTS(-,x,a) applied to the ring morphism
F->SUP(F), which is the identity embedding (SUP(F) as an F-algebra).

The "lifting" is provided I think by the "map" in 
ExpressionSpaceFunctions2(E,F) in
ES2.spad. So for any s in GR, map(s, s)$ES2(GR,SGR) would be the lifting or
embedding. Of course "map" is far more general, just like UTS(-,x,a) is, and
accepts any morphism between rings.

[Disclaimer: I have no experience whatsoever with ExpressionSpace or related
domains and packages. I am only exploring this by looking up hyperdoc. Intuition
does not always work in Axiom and syntax may not be correct.]


William