Re: [Axiom-math] if-expression and variables

[Bill Page]

William,

As usual this thread is drifting away from the original question but I
still think it is interesting from a more general point of view. It
seems to me that InputForm is an often under-appreciated and
under-used domain in Axiom.

On Tue, May 3, 2011 at 3:04 AM, you wrote:
> Dear Bill:
>
> You are right. I should not have declare "It is not possible" (even with a
> qualifier) since one can program around the difficulties.

True.  The question is: how much programming is required versus how
much one can do "off-the-shelf". With any system that is designed to
be extended like Axiom, this is always a moving target. As user
requirements are identified and programming solutions found, these
solutions should become candidates for inclusion in the standard
library.

> However, what you did essentially defines two different piecewise function, 
> one
> for numeric and one for symbolic, by using "interpret" and "expr".

There is only one definition of 'test1'

(3) -> ex:InputForm := parse("if x<10 then 2*x else 5*x^2");
(4) -> test1(x0)==sub(ex, x,x0)

In that sense there is only one "function". (I think this definition
is more properly called a "mode".) This highlights a significant
difference between function definitions in the Axiom interpreter
versus the library compiler. Untyped modes will (usually but not
necessarily) be instantiated into fully typed functions.  Warning
messages like:

  Compiling function test1 with type PositiveInteger -> InputForm

are intend to inform the user that this "function" resulted in one of
possibly several different fully typed compiled functions.

> If you use "interpret test1(y)" you would still get the wrong answer, and

Yes. It is the "wrong" answer in as much as it probably differs wildly
from what a beginning user would expect. That is way other variants of
Axiom choose to eliminate "<" to denote the default ordering of
polynomials. In these other systems "interpret test1(y)" would not be
evaluated since these is preferable over an apparently wrong result.

> similarly, if you use "expr test1(3)", then you would not have the result
> evaluated.

That is true. 'expr' is only a matter of "pretty printing" and
unevaluated expression (InputForm). 'interpret' on the other hand
applies all of Axiom's built-in and library-dependent rules for
evaluation.

> Of course, you can combine the two cases and again distinguish them
> by testing if the input is a symbolic expression or numeric (keeping it
> unevaluated in the first case, and evaluating in the second).
>

I suppose you are suggesting a function that in Axiom parlance might
be called "interpretIfCan". It is not obvious to me how one could
"test if the input is a symbolic expression". In a deep sense
everything in Axiom (in fact in any computer system) is "symbolic".
>From the point of view of Axiom's run-time system (i.e. Lisp) some
things are considered "atomic" such as symbols, integers, etc. But

(5) -> sub(ex,x,3)
   Compiling function sub with type (InputForm,Symbol,InputForm) ->
      InputForm

   (5)  (IF (< 3 10) (* 2 3) (* 5 (^ 3 2)))
                                                              Type: InputForm

is not atomic in this sense, yet it can be evaluated by 'interpret' to
something which is:

(6) -> interpret(sub(ex,x,3))::InputForm

   (6)  6
                                                              Type: InputForm

It would certainly be possible in principle to implement a function such as:

   evaluate: InputForm -> InputForm

which attempts to 'interpret' its input and if possible returns the
InputForm derived from the corresponding value, otherwise it would
return the input unchanged.

> Your routine sub is, I believe, not full proof. If x were modified inside f,
> would a static substitution of all occurrences of x by y work? (isn't y
> bound and x is not?). Or if there were a local variable x that temporarily
> hides the scope of the outer x. By using f:InputForm, the dummy argument
> for f is no longer a dummy; as a function, f is independent of the literal
> used for its argument. Of course, we can identify the argument of f in the
> sub routine without passing it as an argument for sub.
>

I think 'sub' does exactly and only what I claimed.

(2) -> sub(f:InputForm, x:Symbol, y:InputForm):InputForm == ( _;f); _
          atom? f => (symbol? f => (symbol f = x => y;f);f); _
            [sub(g,x,y) for g in destruct f]::InputForm)

It finds all occurrences of the symbol (passed as formal parameter x)
in the InputForm (passed by parameter f). It inserts an InputForm
(passed as parameter y) into f where x occurs in f. The result is
still a value of type InputForm which may or may not be able to be
evaluated by 'interpret'. Nothing is "bound" in f. Also there is no
concept of "local variable" because the InputForm is not yet evaluated
in any way. The declaration "f:InputForm" is just like any other
similar declaration in an Axiom function. It says only that the value
passed by formal parameter f must be of type InputForm. f is not a
function, it just stands for some value of type InputForm.

> I am sure that in lisp, you can do anything. (Tim: would you rise up to the
> challenge?) I believe Stefan's question is whether it can be done
> "intuitively" (even though he did not say so explicitly).

As you can see InputForm is only slightly removed from Lisp. The
underlying representation of InputForm is exactly a Lisp s-expression
of a particular form.

> Mathematica is able to provide that, because neither the input nor the output
> is restricted by its type.

I think that is not very accurate. It might be better to say that in
Mathematica everything is of only one type: symbolic. In Axiom terms
this would be like making everything an InputForm. This is not as
"bad" or as "stupid" as it might sound. But it is not very "algebraic"
in the sense in which I used the word earlier.

> In Axiom, maybe we can do the same with a Union like
> Union(Integer, InputForm).

I am not sure how Union would help in this case.

> ...

Regards,
Bill Page.