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

[Martin Rubey]

Dear William, dear Aldor experts,

The bit for the Aldor exports is enclosed in

-ALDOR QUESTION----------------------------------------------------------------
-------------------------------------------------------------------------------

The rest can be safely skipped, I guess.



William, thanks for your input. Most of it makes sense, however, the paragraph
which I find most interesting I still don't understand. Thus a follow up.

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)

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. 


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

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.

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