RE: [Axiom-developer] Eval in Axiom/Aldor

[Page, Bill]

On Tuesday, November 14, 2006 6:20 PM Antoine Hersen wrote:
> 
> I get nasty FOAM run time error with Ralf solution (I used it
> in a more involved context)

Ralf wrote:

> Replace "eval(a, x, 1)" by
>
>     z: SingletonAsOrderedSet := create();
>     eval(numer a, z, 1)/eval(denom a, z, 1);

I don't understand why Ralf introduces a new variable z. But
I think that is the right idea.

According to Axiom:

  )display op eval

There is only one possible 3-argument form of eval that could
apply

   [26] (D,D1,D2) -> D from D
            if D has IEVALAB(D1,D2) and D1 has SETCAT and D2 has TYPE

Thus

    if Fraction UnivariatePolynomial(x, F) has InnerEvalable(Symbol,
Fraction UnivariatePolynomial(x,F)) then {
      test3(a:Fraction UnivariatePolynomial(x,F)):Fraction
UnivariatePolynomial(x,F) == {
        eval(a, x, 1)
      }
    }

compiles but will not work as one might expect because the
condition is false for Fraction UnivariatePolynomial(x, F)

However

  UnivariatePolynomial(x, F) has
InnerEvalable(UnivariatePolynomial(x,F),
  UnivariatePolynomial(x,F))

is true so one way that does work is:

    import from UnivariatePolynomial(x, F);
    import from NonNegativeInteger;

    test1(a:Fraction UnivariatePolynomial(x,F)):Fraction
UnivariatePolynomial(x,F) == {
        eval(numer a, monomial(1$F,1),1)/eval(denom a,
monomial(1$F,1),1)
    };

    -- equivalently
    test(n:UnivariatePolynomial(x,F)):UnivariatePolynomial(x,F) ==
eval(n,monomial(1$F,1),1);
    test2(a:Fraction UnivariatePolynomial(x,F)):Fraction
UnivariatePolynomial(x,F) == {
        map(test, a)
    };

monomial(1$F,1) is just one way to get x in the right form.
(Perhaps Ralf missed this possibility.)

See for example:

http://wiki.axiom-developer.org/address@hidden
om-developer.org

> 
> And I cant compile Martin one, maybe I should not assume that
> a Field is an INTDOM ...
>

No it not necessary to assume that a Field is an INTDOM.

I also don't understand Martin's workaround since Fraction does
not export elt with this signature.

However I agree with him that QuotientFieldCategory should probably
provide a default implementation of eval such as I show above and
as it does now for map.

> 
> On 14 Nov 2006 09:18:48 +0100, Martin Rubey 
> <address@hidden> wrote:
> > Dear Antoine,
> >
> > great to see you here!
> >
> > "Antoine Hersen" <address@hidden> writes:
> >
> > >     test(a:Fraction UnivariatePolynomial(x,F)):Fraction
> > > UnivariatePolynomial(x,F) == {
> > >         eval(a, x, 1)
> > >     }
> >
> >
> > I also had problems with that. In general, I think it is 
> > better to avoid UP whenever possible and use SUP instead.
> >
> > For your problem, one workaround is to use elt instead:
> >
> >      test(a:Fraction UnivariatePolynomial(x,F)):Fraction
> >  UnivariatePolynomial(x,F) == elt(a, 1)
> >
> > (Note that 1 refers to a Fraction UP here...)
> >

This gives the error:

  There are no suitable meanings for the operator `elt'

> >
> >
> > I can only guess why
> >
> >  eval : (%,Symbol,UnivariatePolynomial(x,Integer)) -> %
> >
> > does not work: it seems that it is not implemented. 
> > "Fraction" takes it from "QuotientFieldCategory", which
> > exports it unconditionally:
> >
> > QuotientFieldCategory(S: IntegralDomain): Category ==
> >   Join(Field, Algebra S, RetractableTo S, FullyEvalableOver S,
> >      DifferentialExtension S, FullyLinearlyExplicitRingOver S,
> >         Patternable S, FullyPatternMatchable S)
> >
> > However, "QuotientFieldCategory" doesn't provide a default 
> > definition... I guess this should be reported on issueTracker.
> > Currently I don't have the time to check this more thoroughly,
> > it would be interesting to see whether the compiler issues a
> > warning when compiling "Fraction".
> >
> > In any case, the fix is probably very easy, since 
> > QuotientFieldCategory has numer and denom. However, we
> > should check which definitions of "eval" should be provided.
> > There are so many defaults...
> >

Regards,
Bill Page.