Re: [Axiom-mail] Declare variable type within function

[Bill Page]

On 3/18/08, Angelos Mantzaflaris wrote:
>
> Well it just seemed strange to me since it will compile it if I do the
> trick I told you. After all, compiling is better than interpreting, right?

Yes, it results in code that executes more quickly although in some
cases and in some versions of Axiom compiling involves a significant
overhead so if the function is only used infrequently there many be no
net gain in performance. To prevent compilation of functions in the
interpreter there is the system command:

  )set functions compile off

It is 'on' by default.

>  Another reason is that If I explicitly define a local variable type this
>  saves me from having to convert the right side of some assignments
> inside the code, cause otherwise I won't get the desired output type
> (it won't auto-convert to left hand type). So my thought is:
> " Cannot compile conversion for types involving local
>  variables": Why not? Since you can do it if I do the trick!
>

Yes, it is a good question. In Axiom types are essentially static.
This is particularly true in the Spad library compiler but it is also
true to a lesser extent in the Axiom command interpreter. This means
that variables cannot be used where types are required (e.g. in the
declaration of a new variable). In the case of your example, the type
of the variable is called "static in context", i.e. the type is known
and fixed by the value of a parameter. So in principle a smarter
interpreter/compiler could in principle analyze the situation and
compile the code. The trick you used makes this fact obvious to the
interpreter so the compilation goes ahead.

>  To be more specific, I would like to have a function that works with
>  polynomials, for example the normalForm function. This function works
> with  POLY FRAC INT, Univariate, DMP's, HDMP's and so on. If I want
> to write a script that implements this function and just make it work
> with polynomials, I should leave it I/O undeclared.
>

I think that is very interesting.

Regards,
Bill Page.