RE: [Axiom-mail] Using eval() in compile spad code.

[Bill Page]

On March 12, 2006 12:10 AM Donald J Bindner wrote:
> ... 
> On Sat, Mar 11, 2006 at 11:27:56PM -0500, Bill Page wrote:
> > The problem was only that in SPAD you must provide explicit
> > conversions. Sometimes these are not obvious from the behaviour
> > of the interpreter which provides many of these automatically.
> > The domain Expression has many possible forms of 'eval':
> > 
> >   )sh Expression Float
> > 
> > In your case you were probably expecting to call the function
> > 
> >   eval : (%,Kernel %,%) -> %
> > 
> > This means that the 2nd argument needs to be converted to a
> > 'Kernel Expression Integer' and the 3rd argument needs to be
> > of type 'Expression Integer'.
> 
> How do you get a feel for this?  If I understand correctly, the
> second argument is Kernel Expression Integer and the third
> argument is Expression Float.
> 

I am sorry. In error I wrote 'Expression Integer' I meant
'Kernel Expression Float' and 'Expression Float'.

> So does Kernel Expression Integer get promoted to Kernel
> Expression Float somehow?  Is this an explicit conversion
> that you don't have to provide?

No. There are not conversions in SPAD that you do not have
to provide. Everything must be explicit.

> 
> I have my Simpson's rule package working, although I found a
> different method.  I did
> 
> simple(func:EF, sbf:SBF) ==
>       a := lo(segment(sbf)) :: EF
>       b := hi(segment(sbf)) :: EF
>       x := variable(sbf) :: EF
>       eval(func, x, b) - eval(func, x, a)
> 
> Apparently I am hitting the function
>  eval : (%,%,%) -> %
> 
> This works.  But I'm left wondering, which is better?

Yes. I think your version is ok. To the best of my ability to
tell, the version of 'eval' that you are using eventually makes
use of pattern matching since you can also write something
like:

   eval(sin(x)+z*sin(y)+1,sin(y),sin(x))

to obtain:

  (z + 1)sin(x) + 1

'eval(func, kernel(x), b::EF)' on the other hand seems more
specific to your intended application. So I think it is "better"
even though the effect is the same.

> 
> Actually my questions seem to be almost endless.

Good! :)

> For example, it is legal to multiply an Expression Float by a
> Float.  Why can you not divide by a Float?
> 
>   a := 2.0 :: Expression Float
>   a := a*0.5  -- legal
>   a := a/2.0  -- illegal

This works in the interpreter, so I presume you mean when
you are writing in SPAD, right? If you look at the result of

  )sh Expression Float

you will find an operation 

  ?*? : (%,Float) -> %

but oddly enough there is no

  ?/? : (%,Float) -> %

instead you must call the function

  ?/? : (%,%) -> %

This requires that the divisor must be of type Expression Integer.
The Axiom interpreter automatically performs the coercion but in
SPAD you must write:

  a := a/(2.0::Expression Float)

> 
> That seems like the kind of thing to make you pull your hair out.
> There must be a good reason for it?
> 

I think many new users Axiom find that it takes some time to
get used to the idea of always having to think about types.
The interpreter releaves the user from more of the responsibility
for choosing correct types (domains) but in SPAD you must be
explicit. This difference is by design. In my opinion it is both
the major strength of and also that which makes Axiom harder to
learn than most other computer algebra systems.

Regards,
Bill Page.