[Axiom-developer] Re: conditionally defined functions

[Martin Rubey]

Dear William,

William Sit writes:
 > >  > (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
 > 
 > ??

What do you mean with ?? ? 

 > > sx = tx has Type: Equation UnivariatePolynomial(x,Integer)
 > > 
 > > and (create()$SAOS)::UP(x,INT) returns x.
 > 
 > I know that! 

Sorry, I didn't know it. I didn't mean to be "belehrend". (don't know the
English equivalent. "instructive" doesn't catch the true meaning. It is
something between "instructive" and "squareheadish")

 > You should note in (10) I had declared g to be Boolean! In your
 > (6), yes, that is an Equation. Unfortunately, a Boolean MUST be declared 
 > before
 > assigning it a value. So your (6) should begin with test:Boolean = (variables
 > ...). If what you think is that Axiom coerced (sx = tx) from Equation to
 > Boolean,

I think that Axiom coerced (sx = tx) from EQ UP(x, INT) to Boolean, yes. 

Here is the relevant part where axiom looks for the right types for the 
equation:

 Function Selection for equation
      Arguments: (SAOS,SYMBOL) 
   -> no function equation found for arguments (SAOS,SYMBOL) 

 Function Selection for equation
      Arguments: (SAOS,OVAR [x]) 
   -> no function equation found for arguments (SAOS,OVAR [x]) 

 Function Selection for equation
      Arguments: (SAOS,POLY INT) 
   -> no function equation found for arguments (SAOS,POLY INT) 

 Function Selection for map by coercion facility (map) 
      Arguments: ((POLY INT -> INT),UP(x,POLY INT)) 
      Target type: UP(x,INT) 
 
 [1]  signature:   ((POLY INT -> INT),UP(x,POLY INT)) -> UP(x,INT)
      implemented: slot (UnivariatePolynomial x (Integer))(Mapping (Integer) 
(Polynomial (Integer)))(UnivariatePolynomial x (Polynomial (Integer))) from 
UPOLYC2(POLY INT,UP(x,POLY INT),INT,UP(x,INT))
 [2]  signature:   ((POLY INT -> INT),UP(x,POLY INT)) -> UP(x,INT)
      implemented: slot (UnivariatePolynomial x (Integer))(Mapping (Integer) 
(Polynomial (Integer)))(UnivariatePolynomial x (Polynomial (Integer))) from 
UP2(x,POLY INT,x,INT)
 

 Function Selection for equation
      Arguments: (SAOS,UP(x,INT)) 
 
 [1]  signature:   (UP(x,INT),UP(x,INT)) -> EQ UP(x,INT)
      implemented: slot $(UnivariatePolynomial x 
(Integer))(UnivariatePolynomial x (Integer)) from EQ UP(x,INT)

 > then there is something very wrong since no one will know how to test
 > equality of two expressions. 

Well, in some cases it can be done, in particular for UP(x, INT). That is,
whenever there is a normalized form. I'm pretty sure I misunderstood you. Do
you mean the following:

(25) -> (2^(2*x)=4^x)::Boolean

   (25)  false
                                                                Type: Boolean

I'm not too sure what to think of it. Probably there should be an attribute
telling whether a particular domain has such a normalized form. On the other
hand, we do want to have (x=x)::(EQ EXPR INT)::Boolean giving true, don't we?
Well, maybe not. I'm mainly thinking from the perspective of packages, and
there we don't.

 > Perhaps the "=" operator should not be overloaded this way.
 > 
 > Moreover, Equation (and equality) should only be formed (called) if both 
 > sides
 > come from the same domain. 

But in this case they do, don't they?

 > [...]

 > > Thus the only thing which I'd object to is the output of (6) and (8).
 > 
 > I have no objection to either (6) or (8). They are what I expected (from the
 > compiler viewpoint). I don't think UP was designed for the kind of 
 > rearrangement
 > you have in mind.

I think that create()$SAOS should not be coercible to Symbol. Again, this is
calling for trouble. Look:

(1) -> r:=create()$SAOS

   (1)  "?"
                                                  Type: SingletonAsOrderedSet
(2) -> s:=r::Symbol

   (2)  ?
                                                                 Type: Symbol
(3) -> s::SAOS
   Loading /home/rubey/axiom/mnt/linux/algebra/UPMP.o for package 
      UnivariatePolynomialMultiplicationPackage 
   Loading /home/rubey/axiom/mnt/linux/algebra/UP.o for domain 
      UnivariatePolynomial 

   (3)  "?"
                                                  Type: SingletonAsOrderedSet
(4) -> t:=?::Symbol

   (4)  ?
                                                                 Type: Symbol
(5) -> t::SAOS
 
   >> System error:
   Bind stack overflow.

protected-symbol-warn called with (NIL)

This should probably also go on

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

don't you think?
 
 > Will take a look later. Pressed for time to prepare class (I do have to 
 > teach!)

Me too. Just starting in fact...

 > > Well, I think that EXPR POLY INT (and similarly POLY EXPR INT) should be
 > > forbidden, since it is not clear where the variables belong.
 > 
 > AGREED!
 > 
 > > 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.
 > 
 > But so should UP(x, EXPR INT). You are inconsistent in the application of 
 > your
 > logic: according to the above, POLY EXPR INT is equally fine (just that there
 > may be more variables). 

In this sense, POLY EXPR INT would be the domain of Polynomials with
coefficients in EXPR INT that do not contain any variables. You are quite
right. In fact, thinking about it, this could be quite useful. At the moment,
there is no other way to accomodate coefficients like sin(2), is there? Also,
some time in the future, it may be possible to say
product(1/n^2,n=1..%infinity), which would also be an EXPR INT, I suspect.

 > [...] and to have x in BOTH EXPR INT and UP(x, EXPR INT) is not right since
 > mathematically, the two are the same, as underlying set and all operations
 > on it.

Whether they are mathematically the same obviously depends on the meaning we
give them. Currently, I think, UP(x, EXPR INT) has no good meaning.

 > Indeed, any operation in UP(x, EXPR
 > INT), say multiplication by sin(x) or 1/x, or even by x, will immediately 
 > need
 > to reconvert UP(x, EXPR INT) back to EXPR INT 

I don't follow. If you are talking about the current semantics - I'd say they
are broken. If you are talking about the semantics I propose(d), [past tense
means, that I'm not sure anymore whether the idea is a good one]
then multiplication by sin(x) would be forbidden, division would create a FRAC
UP(x, EXPR INT) and multiplication by x is OK.

 > If you are not mixing x in both places, then something like UP(y,
 > EXPR([a,b],INT)) may make sense where a new EXPR with specified variables is
 > constructed.

Yes. I'm inclined to think that this is the best way to go: create a domain
EXPR(VarSet, CoeffSet) and forbid all of the above constructions: UP(x, POLY
?), UP(x, FRAC POLY ?), UP(x, EXPR ?) and so on...

 > There is a general philosophy, I think, in developing Axiom algebra code: if
 > some previously established domain lacks certain functionality, you create a 
 > new
 > domain or package to add them, not modify the original (except for bugs). I
 > think this is a well-thought out strategy to let Axiom grow without breaking 
 > old
 > code.

I agree, if there remains a clear design. For example, I find the wealth of
polynomial domains and packages a little confusing:

polycat.spad
poly.spad
newpoly.spad
rf.spad

...

Thanks,

Martin