[Axiom-developer] Re: Defining piece-wise functions and drawing, integrating, ...

[Ralf Hemmecke]

On 06/03/2007 07:44 PM, Bill Page wrote:
> Note: Continued from discussion on axiom-mail.
>
> On June 3, 2007 6:16 AM Ralf Hemmecke wrote:
> > ...
> > Bill Page wrote: 
> > > The result of evaluating this expression depends on the value
> > > assigned to x. This is a "piece-wise" expression in the sense
> > > we have been discussing *BUT* this is a part of the Axiom
> > > programming language - it is not part of any mathematical
> > > object currently implemented in the Axiom library. The Axiom
> > > library includes things like polynomials and even the domain
> > > 'Expression' containing expressions like 'x+1' or 'sin(1)'
> > > but there is currently no domain in which we can find an
> > > expression like 'if x>0 then 1 else 0'.
> > Agreed, but what about telling Axiom the following:
> >
> > (1) -> g(x)==if x>0 then x else -x
> >                                  Type: Void
>
> I think this is equivalent to writing:
>
>   g(x|x>0) == x
>   g(x|x<=0) == -x
>
> As far as I know the difference is only a matter of style.

Since that function definition is only possible in the interpreter (SPAD 
would have to figure out some reasonable types at compile time, and 
Aldor would forbid such typeless things altogether), you may be right.

But, actually, who tells you that > and <= are "opposite" things?

Assume x: MyInteger and I define

(a: MyInteger) >  (b: MyInteger): Boolean == true;
(a: MyInteger) <= (b: MyInteger): Boolean == true;

Of course, that is a stupid definition, but it proves that my and your 
definition are in general not equivalent. (Just a side remark, let's 
discuss such details at the time when we are about to redesign the Axiom 
Library.

> > So let us in particular look at wat happens with g(y).
> > ... 
> > But what about the type of > and the type of 0.
> > ...
> > I guess it can easily be restricted to something of the form
> >
> >    >: (Polynomial Integer, Polynomial Integer) -> Boolean
> >
> > ... 
> > OK, now everything is clear and the compilation can start.
>
> Actually I would much prefer that there be no fuction named
> '<' with the signature you give above. That leads to a lot
> of unnecessary confusion and will also ultimately make a
> proper treatment of predicates like 'x<0' more difficult.

I somehow agree. I must say, when I wrote this, I had problems to figure 
our without testing what x>0 actually means if one thinks of > as being 
a "lexicographical" term order. In fact, extending a term order on the 
monoid [X] of power products to the full polynomial ring P=R[X] does not 
lead to an order on P that is compatible with multiplication.

> > As I see it, we are a bit in a dilemma here. We need the
> > function expression here and at the same time > should be
> > considered as something like (Float, Float) -> Boolean.
>
> I think we really need a class of fuctions > with signatures
> like:
>
>   > : (Expression Integer, Expression Integer) ->
>         Union(Expression Integer, Boolean)

I think that would make things more complicated.

> Then 'x<0' can be treated as an expression of type Expression
> Integer just like 'sin(x)'. Or more generally we need a domain
> of predicate expressions which can interact with other domains
> like Expression.

Yep. I like to see a true expression domain. Axiom's Expression(..) is 
rather special. It covers a lot, but its inhabitants are not expression 
trees. They are rational functions.

> I would kind of like to write:
>
>   Expression Boolean
>
> but the current implementation of Expression does not produce
> the desired result. But see for example my related experiments
> at:
>
> http://wiki.axiom-developer.org/SandboxBooleanRing
>
> I think this is a step in the right direction.

(1) -> a: BooleanRing := true()
(1) ->
   (1)  true
                        Type: BooleanRing
(2) -> b: BooleanRing := false()
(2) ->
   (2)  false
                        Type: BooleanRing
(3) -> a < b
   There are 4 exposed and 1 unexposed library operations named <
      having 2 argument(s) but none was determined to be applicable.
      Use HyperDoc Browse, or issue
                                )display op <
      to learn more about the available operations. Perhaps
      package-calling the operation or using coercions on the arguments
      will allow you to apply the operation.

   Cannot find a definition or applicable library operation named <
      with argument type(s)
                                 BooleanRing
                                 BooleanRing

      Perhaps you should use "@" to indicate the required return type,
      or "$" to specify which version of the function you need.

(3) -> x:Polynomial(BooleanRing):=a
(3) ->
   (3)  true
                          Type: Polynomial BooleanRing
(4) -> y:Polynomial(BooleanRing):=b
(4) ->
   (4)  false
                          Type: Polynomial BooleanRing
(5) -> x<y
   There are 4 exposed and 1 unexposed library operations named <
      having 2 argument(s) but none was determined to be applicable.
      Use HyperDoc Browse, or issue
                                )display op <
      to learn more about the available operations. Perhaps
      package-calling the operation or using coercions on the arguments
      will allow you to apply the operation.

   Cannot find a definition or applicable library operation named <
      with argument type(s)
                           Polynomial BooleanRing
                           Polynomial BooleanRing

      Perhaps you should use "@" to indicate the required return type,
      or "$" to specify which version of the function you need.

I surely must do something wrong, but I somehow have the impression that

  )show Polynomial BooleanRing

doesn't tell you the truth. It shows that there is a <: (%,%)->Boolean 
function.

But BooleanRing does not have a < function and Polynomial exports < only 
through PolynomialCategory where it says:

    if R has OrderedSet  then OrderedSet

OK, that was just a side remark.

Then writing "Expression BooleanRing" is probably also not what you 
want. At least I don't want it.

> > Yes, Bill is right, currently, Axiom's Expression(...) domain 
> > does not allow to contain an expression of the form
> > "if a then b else c".

> If we had a domain for predicate expressions then it would not
> be difficult to introduce an expression in Expression of the
> form:
>
>   piecewise(Cond:Expression Boolean,
>             Then:Expression Integer,
>             Else:Expression Integer):Expression Integer

Well, what I would dream of is an expression domain (or several of them) 
that lets you define a general expression tree where you would have 
control over what is allowed as nodes. Maybe it would be interesting to 
be able to give a grammar G and MyExpression(G) would then describe the 
language generated by G. It would be nice to be able to encode the Aldor 
language in that way.

You all probably know that everything in Maple is an expression also "if 
a then b else c fi" and that one can compute with these things. (Yes, 
yes, looks again like the Maple language is nothing but Lisp with 
another syntax. ;-) ).

Aldor's LibAlgebra defines a domain ExpressionTree. But that is 
certainly not yet perfect.

Ralf