[Axiom-developer] Re: conditionally defined functions

[Martin Rubey]

Dear William, 

(I stopped copying to Bronstein and Hemmecke, since I suspect that the
following is too Axiom specific)

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

(6) -> variables((3*x+1)::UP(x, POLY INT)).1=variables((3*x+1)).1

   (6)  x= x
                               Type: Equation UnivariatePolynomial(x,Integer)

The reason is that the interpreter thinks (quite rightly) that 

sx = tx has Type: Equation UnivariatePolynomial(x,Integer)

and (create()$SAOS)::UP(x,INT) returns x.

Thus the only thing which I'd object to is the output of (6) and (8).

I started a discussion of (6) in 

http://page.axiom-developer.org/zope/mathaction/DesignIssues

 > 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

Well, I think that EXPR POLY INT (and similarly POLY EXPR INT) should be
forbidden, since it is not clear where the variables belong.

On the other hand, it is easy to clarify the semantics of types like 
UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this
domain. I don't think that there is another way to make sense of such a
domain. That's the reason for the question I started with, in fact.

So, let's return there:

> > > So, in more general terms, here's my question:
> > > 
> > > Suppose you have a category A, taking as parameter a domain P and 
> > > providing an
> > > operation f: % -> P. Furthermore, you have a category (or a domain, a 
> > > package)
> > > B, taking as parameter a domain Q. Now you want to achieve the following:
> > > 
> > > If Q is a domain in A, provide a function g: % -> P, using f.
> > > 
> > > Of course, it is not possible to provide P as a parameter of B, since B 
> > > should
> > > also be defined for Q's that are not domains in A...
> > 
> > The way to handle this is to create a special version of B, which takes a 
> > domain
> > in A as parameter, together with parameters needed for A and construct the
> > special version using the general one. This is ok because the compiler can
> > handle dynamic signature on the category/domain constructor level.
> > 
> > BforA(P:Cat1, Q: A(P)): Cat2 == B(Q) with { g:%->P }
> > 
> > You can then add the function g without a problem. The moral is: Don't Ask, 
> > Just
> > Tell.
>
> Great! gonna try this!

Well, I thought a little about this, but it seems that I cannot apply it to the
problem at hand. 

I'll note my thoughts on mathaction.

Martin