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

[William Sit]

Martin Rubey wrote:

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

This was only used to see if I understood your question. I was aware you are 
writing
a package. With the exception perhaps of Inteval, domains that descends from 
TRANFUN
are either constants or series, or EXPR. Only EXPR allows you to have a new 
symbol
without "adding" it to F as in SUP F. But the problem is not adding a new 
variable,
which is the easy part. So it is not even necessary to check if F allows a new
symbol. It is the series expansion that is causing the problems that forces you 
to
use EXPR.

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

No you don't have to, at least not for the user, but I think you must, to do 
your
computation. As you observed, if you add a new variable as the undetermined
coefficient using SUP F, the domain no longer has TRANFUN even if F has. 
Moreover,
the series expansion operation requires AlgebraicallyClosedField and 
FunctionSpace in
addition to TRANFUN. This means you cannot expand the transcendental functions 
in SUP
F into a series (example, expand series(sin(1+t*x))  ) without going to EXPR 
anyway.
But EXPR SUP F can then be replaced by EXPR F. Of course, if F is EXPR INT, you
should not add another layer, but this is "easy" to test by checking whether F 
has
FunctionSpace(some ring) (and really easy, whether F has 
AlgebraicallyClosedField)).
I am putting the first "easy" in quote because we went there before: Axiom does 
not
provide info of how F is constructed unless in you package, you ask for it in 
the
parameters. If you want to avoid such trouble, write your package for EXPR over 
some
numeric domain.

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

Ideally, assuming F is a domain from TRANFUN, the coefficient ring for the 
partial
series is F if F is already EXPR(S) and EXPR F if not (this second case include 
the
cases when F is itself is a numeric domain, or a series ring, wrt some other
independent variable). If what I said so far is correct, you have no choice.

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

No, it is much simpler (conceptually speaking). In your hypothetical scenario, 
you
must construct in InterestingFunctions the series expansion operation. At this 
time,
all roads lead to EXPR! (The only SPFCAT domain constructor is EXPR, which is 
also
the only FS domain constructor). So it is very likely that if there are new
interesting functions, you will certainly "extend" EXPR to belong to that 
category as
well.

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

Well, yes, for the reasons above. I don't think you can avoid this, at least 
not in
your computations. Users don't have to enter the z function that implicitly 
defines
the g function using EXPR domains---any TRANFUN domain is fine if no special
functions are involved.

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

> > In any case, you can now compute your undetermined coefficients 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.

I mean the definition of the macros newPoly and the functions npoly, oldpoly and
inRadical? in ideal.spad, where a polynomial ring domain used for the input
polynomials is extended by a new variable. You will notice a lot of similar 
code in
other routines (look for the variable tp or tp1). The construction works even 
when
the polynomial domain is POLY INT (supposedly includes all symbols). This is the
beauty of Axiom because we only need to extend the exponent vectors by one more
dimension (even if the original vectors are conceptually infinite dimensional). 
So I
am proposing you do the same thing because EXPR plays the same role as POLY, 
but in
function space.

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

Hope this makes more sense.

William