[Axiom-developer] Re: conditionally defined functions

[William Sit]

Martin Rubey wrote:
> 
> Dear William,
>  > 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.

I know that! 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, then there is something very wrong since no one will know how to test
equality of two expressions. 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. ANY needed coercion should be done by the user. The
interpreter should NEVER automatically coerce the two sides to a common domain
-- I know this is difficult to fix, but an automatic coercion means mistakes on
types will not be caught. I realize that this automatic coercion is done for
common arithmetic operators like + in the interpreter but somehow I think
equality testing should be handled differently.

Although I have not yet tried the above in the compiler, I believe that (10)
should give false, and (11) should be flagged because of type error. 

In (11), sx has type SingletonAsOrderedSet and tx has type Symbol. If sx=tx is
to be considered as an Equation, then an intuitive common domain should be
Symbol (using [convert] as in (8). To use [create] and not [convert] to lift an
SAOS to UP(x,INT) AND do the same for tx is way too imaginative for my intuition
if indeed that is what the interpreter does.

> 
> 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 started a discussion of (6) in
> 
> http://page.axiom-developer.org/zope/mathaction/DesignIssues

Will take a look later. Pressed for time to prepare class (I do have to teach!)

> 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). But back to UP. EXPR INT can also contain polynomials in
x in addition to 1/x, 2^x, sin x. In fact:

(15) sin(x)*x + sin(x)*x^2
     (x^2 + x)sin(x)            Type Expression Integer

This regrouping is automatic. If you rather prefer the input form, which
separates the powers of x, I think you should use a package to provide the
conversion WITHIN EXPR INT and where you also change the outputform. In Axiom,
the domains correspond to mathematical objects, 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. 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 --- a difficult dilemma because
you now have to consider UP(x,EXPR INT) elements as ground elements (ground? may
fail, in general, though not here), perform the operation, and reformating back
to UP(x, EXPR INT). This really shows that the only thing you can achieve is
reformatting output and so it should be done that way.

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.

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.


William