Dear Carl.
> > I definitely see your point. Well, without introducing a hierarchy,
> > there is this natural notion of invertible coercions (strongly
> > connected components in the conversion graph). But that would not have
> > helped anyway for 4/2 in ZZ. Here it's more about a notion of partial
> > inverse for the canonical coercion from ZZ into QQ. It probably would
> > be over engineering to introduce it.
>
> The strongly connected components in the conversion graph are huge.
> Did you mean strongly connected components in the coercion graph?
> There shouldn't be any of those; a coercion should only exist A->B or
> B->A, but not both. (Otherwise how do you decide what the result of
> an A plus a B is?)
You don't !!! I completely disagree with that. One of the *main* usage of
computer in algebraic combinatorics is to do computations in many (usually
between 5 and 10) different bases of the same algebra. The way we use to deal
with this in MuPAD-Combinat is that each basis is a particular parent, and we
set up a graph of automatic coercion for one bases to an other. That is you
consider that for each basis B, the algebra with element stored in B ( an
instance of the category AlgebraWithBasis) is a particular algebra. You use
the coercion mechanism to say that theses algebra are isomorphic.
Let me point out some typical use-case (B1, B2 and B3) are different bases:
1) I know an explicit formula for conversions B1 -> B2 and B2 -> B3. The
problem is to experiment to find an explicit formula/fast algo for B1 -> B3
2) I know the multiplication rule in B1 and the conversions B1 <-> B2, I'm
looking for an explicit rule for multiplying two B2s
3) I don't known how to multiply two B1 or two B2, I know B1 <-> B2 and I
know how to multiply a B1 by a B2.
list goes on...
> Then "x in P" means that there is a safe conversion from the parent of
> x to P. If this is actually a coercion, then you don't even have to
> run it; if it's a conversion, then you do have to run it, to test that
> the conversion is defined on x. "x == y", "x<y" will find a safe
> coercion to a common parent if one exists; otherwise it will find a
> safe conversion. If a conversion is used that fails, then the
> comparison is false.
This preceding rule is not always true: I know many counter example.
To begin with
sage: x = int(2)
sage: type(x)
<type 'int'>
Of course x has no parent:
sage: x.parent()
...
AttributeError: 'int' object has no attribute 'parent'
sage: x in ZZ
True
So your rule "there is a safe conversion from the parent of x to P" does not
specify why we should answer yes. I fill being some lawyer in pointing out
that but I think we must use extra care when using conversion/coercion from
basic type to construct elements.
Another example to show that the example is not as trivial as it seem:
sage: l = [3,2,1]
sage: l in Permutations()
True
sage: l in Partitions()
True
Cheers,
Florent
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
