[Axiom-developer] Re: EXPR POLY INT

[William Sit]

Just to keep the post by Martin in context. Here're the related exchanges:

Martin:
>  (1) -> a:EXPR POLY INT
>
>    Expression Polynomial Integer is not a valid type.

William:
> I wonder what generates the error message. 

Martin: 
> I found several possible sources, all in the boot code: The error code is
> S2IE004, so ...

William:

I am not good at boot code at all (this is one for Tim). The question is, what
call (not where the message came from) is invoked in the interpreter that is NOT
invoked in dom:=EXPR POLY INT but in (1) or a::EXPR POLY INT, or by the
compiler? One would think, in all cases, that EXPR POLY INT would be
instantiated BEFORE the : or :: or := operators. But it now seems that the
declaration : invokes some routines that
leads to the error.

 > )abb package TEST  Test
 > 
 > Test():Target==Implementation where
 >   EXPR ==> Expression
 >   POLY ==> Polynomial
 >   INT  ==> Integer
 >   Target ==> with
 >     myfunc: () -> EXPR POLY INT
 >   Implementation ==> add
 >     a:=new()$Symbol::EXPR POLY INT
 >     myfunc()==a
 > 
 > After compiling, I can do:
 > v:=myfunc()$TEST
 > v+v
 > convert(v)$(EXPR POLY INT)

Martin:

> Yes, I did that. I realised only later that axiom thinks it's not a valid
> type. The reason why I wanted it is: I have a Field F, do rational 
> interpolation
> to get a function f(x) with coefficients in F. Finally, I generate
> sum(f(x),x=0..n). However, I also want to allow FRAC POLY INT for my field 
> F...

William:

Whenever you use POLY constructor, you are including ALL symbols as
indeterminates (this is unlike some other domains like DMP where the variables
are specifically given). So it really does not make sense to consider your f(x)
as belonging to the domain EXPR FRAC POLY INT because the system gets confused
of where x belongs. Mathematically, it is like writing down k[a,b,c, ..., x,
...][x]. There is no way to replace the dummy x in f(x) by another symbol that
will work because ANY symbol is already included in POLY INT. So if you do want
F to be a rational function field, you will have to specify all its variables
and then the dummy variable needs a symbol different from those.

Actually, I think this also explains why a:EXPR POLY INT or a::EXPR POLY INT
causes problems with an error message. The symbol a can belong to POLY INT or be
part of EXPR (which includes in fact FRAC POLY). This ambiguity is why there is
an error. Simply constructing EXPR POLY INT without any computation is fine. 

So is this a bug? I am not sure, it may be good that the interpreter caught the
ambiguity and it may be bad that the compiler does not. The compiler actually
knows how to distinguish POLY INT from EXPR POLY INT even if the SAME symbol is
used, but we (human) will get all confused. Try:

)abb package TEST  Test

Test():Target==Implementation where
  EXPR ==> Expression
  POLY ==> Polynomial
  INT  ==> Integer
  Target ==> with
    f1: () -> EXPR POLY INT
    f2: () -> POLY INT
    f3: () -> EXPR POLY INT
    f4: () -> EXPR POLY INT
  Implementation ==> add
    a:=new()$Symbol
    b:=a ::EXPR POLY INT
    c:=a :: POLY INT
    f1()==b
    f2()==c
    f3()== (c*b)/b
    f4()== f3()/b

Note that if you check the signature of /, the compiler "knows" it is legally
used and the answer for f4() is c/b, not 1 (which should be the case
mathematically).
--------
added comment to last remark: Normally coercions must be explicit for the
compiler. But here, the compiler is "smart" in both c*b and in the subsequent /
for both f3 and f4.
So this may be a problem with the database for the interpreter.

Now some comment on the previous post of Martin:

> When saying f4()$TEST, the former gets called (twice, once for f3 too): The
> first time x is %A %A and y is %A and x /$Rep y gives %A / %A, the second 
> time, 

you meant x /$Rep y gives %A, not "%A / %A"?

> x and y are both %A, and x /$Rep y gives %A / %A.

> When I say a::EXPR INT/a, also the former gets called (once, of course),
> x and y being a and x /$Rep y gives 1.

It is strange that the interpreter finds / for EXPR INT, but not for EXPR POLY
INT
when I do:

  b:=f1()$TEST
  c:=f2()$TEST
  d:=c*b/b  (/ not found in EXPR POLY INT, even though it should be; e.g. )show
does.)
  d:=f3()$TEST
  e:=d/b   (/ not found)
  POLY INT has IntegralDomain

    true

b gets %A (EXPR POLY INT), c gets %A (POLY INT), d gets %A (EXPR POLY INT).

William