Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> > UPOLYCoerce(A: UPOLYC, B: UPOLYC): with
> > coerce: A -> B
> > add
> > coerce a ==
> > resta := a
> > res: B := 0
> > while not zero? resta repeat
> > res := res + leadingCoefficient resta * leadingMonomial
> > resta
> > resta := reductum resta
> > res
>
> > and this will provide a coercion function from any A to any B in UPOLYC
>
> In other words, for any A and B you have a package that implements coerce:
> A->B. OK.
>
> > but I cannot state that for any A and any B in UPOLYC
>
> > A has CoercibleTo B
>
> Now why do you think this is still important? Onces *you* have programmed
> UPOLYCoerce and you know that A: UPOLYC and B: UPOLYC then everything is clear
> and you can simply say (for a: A)
>
> b: B := coerce(a)$UPOLYCoerce(A,B)
>
> I see no need to require "A has CoercibleTo B". Perhaps, I still didn't get
> your point.
Well, I may want to code
if A has CoercibleTo SparseUnivariatePolynomial R
then ...
This will "work" only for those A for which I have explicitly stated
CoercibleTo SparseUnivariatePolynomial R.
In a different package, I may want to ask
if A has CoercibleTo UnivariatePolynomial(x, R)
then ...
Of course, this is not really a problem if there are only two or three
implementations of univariate polynomials, say A, B and C. In A I say
with { CoercibleTo B; CoercibleTo C; }
in B I say
with { CoercibleTo A; CoercibleTo C; }
in C I say
with { CoercibleTo A; CoercibleTo B; }
But somehow, this looks suboptimal.
Martin
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
