[Axiom-developer] Re: conditionally defined functions

[William Sit]

Martin Rubey wrote:
> 
> William Sit writes:
>  > > In principle, this is not too difficult. However, there is a slight 
> subtlety:
>  > > Currently not all domains that contain variables provide such a 
> function, in
>  > > particular, FRAC does not. Instead, there is a package RF that provides 
> this
>  > > functionality. Well, no problem:
>  > >
>  > > * move the operation variables from RF and POLYCATQ to QFCAT :
>  > >
>  > >     if S has variables: S -> List Symbol then
>  > >       variables: % -> List Symbol
>  > >       variables f ==
>  > >          mymerge(variables(numer(f)), variables(denom(f)))
>  > >
>  > > and add the following to UP and MPOLY :
>  > >
>  > >     if R has variables: R -> List Symbol then
>  > >       coerce(r:R):% ==
>  > >         if member?(x, variables(r)) then
>  > >           error "coefficient contains variable"
>  > >         else coerce(r)$Rep
>  > >
>  >
>  > If this works, it works wrongly, because this confuses the x in the inner
>  > domain of a tower with the x in the outer domain of the tower.
> 
> I don't understand what you mean with "wrongly". I'm aiming at the following: 
> I
> want that UP(x, FRAC POLY INT) or UP(x, EXPR INT) would be a rational function
> (or expression) that is a polynomial in x. I tested the code above and it does
> indeed "work" (in this sense).
> 
>  > Remember that the compiler distinguishes these already. So the condition
> 
>  >          member?(x, variables(r))
> 
>  > would always return false.
> 
> No, it does not. (at least not in the tests I ran)
> 
>  > I don't know what you meant by "fishy". The code would not work at present
>  > because I don't think you can consider a function as an attribute.
> 
> Hmm, I think you can. The code above does so.

One can never argue with code that works! I am surprised that a function can be
treated as an attribute -- I tried that in the interpreter:

INT has min: (INT, INT)->Boolean
   false

Of course, it has. I think the reason why the answer is false is because this
property is not in the AttributeRegistry. Another difference between interpreter
and compiler?

Martin, I did not test your code (lack of time, but probably also I do not have
the setup as well. I might even have misunderstood your question: Perhaps you
are just trying to "lift" a polynomial (or rational function) with integer
coefficient that may or may not involve x (and if it does, only polynomially)
and just want to separate the variable x and rewrite it as a polynomial in x
with all the rest as coefficients? In other words, there is never two different
x's and you just want to rewrite something like Q[a,b,...w,x] as
Q[a,b,...,w][x]? Have you tried using POLYLIFT?

As to why I think if it works, it works wrongly:
Try this:

(1) -> )clear all
(1) -> y:=3*x + 1
    (1) 3x+1                Type: Polynomial Integer
(2) -> z: UP(x, POLY INT)
                            Type: Void
(3) -> z:=3*x + 1
    (3) 3x+1                Type: UnivariatePolynomial(x,Polynomial Integer)
(4) -> t:=variables(y)
    (4) [x]                 Type: List Symbol
(5) -> s:=variables(z)
    (5) ["?"]               Type: List SingletonAsOrderedSet
(6) sx:=s.1
    (6) "?"                 Type: SingletonAsOrderedSet
(7) member?(sx,t)
    (7) true                Type: Boolean

Is this correct? How?

(8) sxx:=convert(sx)
    (8) ?                   Type: Symbol
(9) tx := t.1
    (9) x                   Type: Symbol
(10) g:Boolean:= sxx=tx
    (10) false               Type: Boolean
(11) g:= sx = tx
    (11) true               Type: Boolean

How do you explain (11) that two items of different type can be equal, and (10),
after conversion to the same type, are not?
   
William
---

PS:
>  > Remember that the compiler distinguishes these already. So the condition
> 
>  >          member?(x, variables(r))
> 
>  > would always return false.
> 
> No, it does not. (at least not in the tests I ran)

I was writing based on a similar situation we discussed on June 12:

---quote from June 12
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).
---end of quote

I have not tried to replace EXPR by UP(x, ...) in Test(). Perhaps they behave
differently