Re: Defining piece-wise functions and drawing, integrating, ...

> For example in Axiom you can write the expression:
> 
>   (1) -> if x>0 then 1 else 0
> 
>     (1)  1
>                               Type: PositiveInteger
> 
> 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

(2) -> g(1)
    Compiling function g with type PositiveInteger -> Integer

    (2)  1
                                                         Type: 
PositiveInteger
(3) -> g(1.0)
    Compiling function g with type Float -> Float
    (3)  1.0
                                 Type: Float
(4) -> g(-1)
    Compiling function g with type Integer -> Integer

    (4)  1
                                 Type: PositiveInteger
(5) -> g(-1.0)
(5) ->
    (5)  1.0
                                 Type: Float
(6) -> g(y)
    Compiling function g with type Variable y -> Polynomial Integer

    (6)  y
                                 Type: Polynomial Integer
(7) -> g(y^2)
    Compiling function g with type Polynomial Integer -> Polynomial
       Integer

          2
    (7)  y
                                 Type: Polynomial Integer

What do we learn from that. Giving the interpreter a definition like

g(x)==if x>0 then x else -x

actually leaves a lot of guessing. Internally Axiom is strongly typed. 
So in order to make any sense of that expression one would have to give 
types. As one can see above there are actually several *different* 
functions compiled from the definition. The interpreter makes a good 
guess of the types. So let us in particular look at wat happens with
g(y).

The interpreter looks at the argument y and figures out that a good type 
for it is "Polynomial(Integer)". Now it takes the right hand side of the 
definition and figures out what the resulting type could be. So it 
arrives at

   Polynomial Integer -> Polynomial Integer

good guess. But now let's look at

   if x>0 then x else -x

or in particular at "x>0". The type of x is now clear, 
Polynomial(Integer). But what about the type of > and the type of 0.
Yes, 0 is a problem as well. Usually, what happens in that and similar 
cases is, that there are several options.

   >: (X, Y) -> Z
   0: U

X = Polynomial Integer is what is already known.
Z = Boolean can be figured out from where "x>0" is in the if expression.
I now have no complete overview about all the possible > functions, but 
I guess it can easily be restricted to something of the form

   >: (Polynomial Integer, Polynomial Integer) -> Boolean

Well, then the only reasonable choice for U to make the whole expression 
matching types is U=Polynomial(Integer).

OK, now everything is clear and the compilation can start.

Oh, but what is the implementation of > in Polynomial(Integer)?  Think 
about how you would implement it. Note that x, y, z are elements of 
Polynomial(Integer), but 5.0 or -5.0 are not.

Sumant, what you actually want to have is a polynomial function and not 
a polynomial. So for you the guess of the Axiom interpreter is wrong. 
But what can Axiom do? You just don't give enough information.

What you want is actually a function Float -> Float. For drawing that 
might be ok, but when it comes to integrating, that signature is bad. 
How can you as a human extract from a function that goes from the reals 
to the reals a generic way to integrate that function symbolically? It 
won't work, since what you need is an *expression* for the function.

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.

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".

Sorry, I don't see a good solution at the moment.

Ralf