(cross posting to fricas-devel, maybe others want to make things more
precise. Eg., I won't touch the difference between coercion and
conversion here, although I probably should...)
"Nicolas M. Thiery" <nicolas.thi...@u-psud.fr> writes:
> > > Do you foresee any occasion to meet physically all three of us?
> >
> > Well, at least two of us are at FPSAC 09 at RISC.
> >
> > (I love all these abbreviations, it feels so french :-)
>
> :-)
>
> > (3) The interpreter makes a heuristic choice which signatures to
> > prefer over others. This algorithm works usually very very well,
> > although it could be still improved.
>
> Just a short question: does the interpreter handle transitivity:
> i.e. if there is a coercion A -> B and one B -> C, then deduce one for
> A -> C?
I don't think so, but I should say that my point (3) was actually a
bit cryptic. Thus, I elaborate a little (I've got two minutes):
(a) In library code, coercions (mostly) have to be explicit. I think
there are a few implicit coercions, but this is a separate issue,
I'd say, i.e., the implementation of the language is not perfect.
Library code is compiled by the SPAD compiler.
(b) To make life enjoyable, the interpreter uses heuristics, i.e., it
"guesses" types. Eg., when you enter 3, the interpreter will
answer with "PositiveInteger" and not with "Polynomial Integer"
or "PrimeField 17". The algorithm chooses a reasonably specific
type. The types it chooses are (currently) hard-coded, and I
think they need to be, at least partially.
(c) When you want to use an operation, the interpreter looks at all
available operations with this name and the right number of
arguments.
If there is an operation that fits perfectly, i.e., the type of
the argument in the signature matches the type of the argument
provided by the user, that's the winner.
Otherwise it will use (roughly) the operation with the least
number of coercions necessary to make the types match.
Alltogether, I'd say that transitivity of coerce is not used, and is
not necessary, or, alternatively, you could say that it's coded in
the library, as in the example I provided in my previous post, or in
Ring(): Category == Join(Rng,SemiRing,LeftModule(%), unitsKnown) with
[...]
coerce: Integer -> %
++ coerce(i) converts the integer i to a member of the given domain.
I.e., *every* Ring allows coercion from an Integer. Of course, the
interpreter finds this operation.
Martin
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
