Can we really accept this consequence of bidirectional plus forgetful coercion?
Simon King
In different threads, it seemed that most of you think that a
forgetful coercion should be fairly harmless.
However, if a forgetful coercion is added to an existing bidirectional
coercion then addition fails to be associative:
sage: K1.<r1>=NumberField(x^2-2)
sage: K2.<r2>=NumberField(x^2-2, embedding=1)
sage: K3.<r3>=NumberField(x^2-2, embedding=-1)
In that situation, we already have a bidirectional coercion between K3
and K2, sending r3 to -r2. I suppose that we won't remove the
existing feature.
Now, if we introduce forgetful coercion, we would have coercion from
K2 to K1 sending r2 to r1, and a coercion from K3 to K1 sending r3 to
r1.
Hence, (r1+r2) == 2*r1 and thus (r1+r2)+r3==3*r1.
But (r2+r3)==K2.zero(), and thus r1+(r2+r3)=r1.
The question is: Can we accept such consequence?
My opinion is: We can. After all, no axiom states that addition
between elements of different mathematical structures is associative
(or even defined).
On the other hand, I acknowledge that the lack of associativity might
be confusing/shocking to people. So, I thought I'd better ask here:
What shall we do? I think forgetful coercions are quite natural; but
perhaps it would mean to over-do coercion?
Cheers,
Simon
John Cremona
John
luisfe
> My opinion is: We can. After all, no axiom states that addition
> between elements of different mathematical structures is associative
> (or even defined).
>
> On the other hand, I acknowledge that the lack of associativity might
> be confusing/shocking to people. So, I thought I'd better ask here:
> What shall we do? I think forgetful coercions are quite natural; but
> perhaps it would mean to over-do coercion?
fields or forgetful operator but that we cannot have both. And I
prefer to eliminate forgetful operator because it is not unique.
Acording to the reference manual, coercions should be commutative and
I do not see any good reason in this case to ignore this rule.
Coercing from K3 to K1 in the example above is different than coercing
from K3 to K2 and then K2 to K1.
If we allow forgetful operator, why do not we allow also operate in
non embedded rings?
sage: K1.<r1>=NumberField(x^2+2)
sage: K2.<r2>=NumberField(x^2+2)
sage: r1+r2
???
Note that in current sage 4.6 you can use these operators if you wish
but they do not produce indesirable behaviour
sage: K1.<r1>=NumberField(x^2-2)
sage: K2.<r2>=NumberField(x^2-2, embedding=1)
sage: K3.<r3>=NumberField(x^2-2, embedding=-1)
sage: K1.has_coerce_map_from(K3)
True
Composite map:
From: Number Field in r3 with defining polynomial x^2 - 2
To: Number Field in r1 with defining polynomial x^2 - 2
Defn: Generic morphism:
From: Number Field in r3 with defining polynomial x^2 - 2
To: Number Field in r2 with defining polynomial x^2 - 2
Defn: r3 -> -r2
then
Ring morphism:
From: Number Field in r2 with defining polynomial x^2 - 2
To: Number Field in r1 with defining polynomial x^2 - 2
Defn: r2 |--> r1
sage: K1(r3)
-r1
I really think that it is better to let the user deal with morphisms
between number fields as long as there is not a unique homomorphism
(which is the case of the two embedded fields above).
Bests
Luis
Simon King
On 8 Dez., 00:04, luisfe <lftab...@yahoo.es> wrote:
> On 7 dic, 21:48, Simon King <simon.k...@uni-jena.de> wrote:
> Acording to the reference manual, coercions should be commutative and
> I do not see any good reason in this case to ignore this rule.
> Coercing from K3 to K1 in the example above is different than coercing
> from K3 to K2 and then K2 to K1.
parent addition was acceptable, but you convinced me that non-
commutative coercions are not acceptable.
Since the bidirectional coercions already exist, while the forgetful
coercion would be a new feature, I think I'll forget about the
forgetful coercions and change my patch from #8800 accordingly.
Cheers,
Simon
David R. Kohel
One of the previous postings made me realise that I do not know
what a coercion in Sage is designed to do: are they morphisms
or are they functors? Once I realised that coercion was being
used to implement myriad possible functors, I became worried.
In my view, the ideal situation would be for objects to be
"strongly categorized", and coercion should only be canonical
morphisms within this category. Functors should exist and
be easily definable by users in order to map objects from one
category into another. The objects in that category might
admit a completely different set of morphisms. If one class
of objects simultaneously exists (or can be transformed by a
coercion functor) in more than one category, then one loses
control over what are valid morphisms, which is precisely the
advantage of the categorical structure.
Specifically I find the application of a forgetful functor by
coercion dangerous.
Similarly construction of the pushout (I would prefer [fibered]
coproduct or sum) in the category of embedded number fields is
questionable for the same reason. First, one has to create a
new object, which might be computationally expensive; this is
an objection on the basis of computational efficiency. Second,
it may be universal (well-defined up to unique isomorphism) but
noncanonical. The particular example of a category of embedded
fields is misleading. The homsets Hom(X,Y) have at most one
element, any two coproducts are canonically isomorphic (even
forgetting the X -> X \oplus Y and Y -> X \oplus Y). In general
this will not be true.
For number fields, in my view the "correct" category should not
be number fields but etale algebras over QQ (or another base
number field for a category of relative extensions), and the
coproduct should just be the tensor product (and this distinction
shows the relevance of a strong category). This keeps the
category closed under finite products and sums. However,
I wouldn't expect addition or multiplication of two elements in
different number fields to create this universal object for me.
I would expect an error so I could debug my code (the most
likely case in which such an addition or multiplication would
arise).
Certainly, for a number field X there is a canonical morphism
from QQ to X, so I'm not saying that no coercions should exist.
Cheers,
David
P.S. I am aware that Sage does not implement my "ideal situation"
above, as demonstrated by the following example:
sage: PZ.<x> = PolynomialRing(ZZ)
sage: a = QQ(1/2)
sage: a + x
x + 1/2
sage: parent(a + x)
Univariate Polynomial Ring in x over Rational Field
Simon King
I hope that below I am not writing too much nonsense about coercion,
but let's try. I am open for corrections.
On 8 Dez., 11:34, "David R. Kohel" <ko...@iml.univ-mrs.fr> wrote:
> One of the previous postings made me realise that I do not know
> what a coercion in Sage is designed to do: are they morphisms
> or are they functors?
> Once I realised that coercion was being
> used to implement myriad possible functors, I became worried.
around. These functors are not coercions and they are not implemented
using coercions. But the construction functors are used to implement
coercions.
> In my view, the ideal situation would be for objects to be
> "strongly categorized", and coercion should only be canonical
> morphisms within this category.
one and the same object can be regarded in different categories.
Example:
QQ is in the category of fields, QQ['t'] is in the category of
commutative rings (it should be in the category of QQ-algebras, but
that's a different story).
So, the categories are different, but there is a common super-
category, namely the category of commutative rings. Hence, the
coercion from QQ to QQ['t'] is supposed to be a morphism in the
category of commutative rings. However, one only has
sage: (QQ['t']).coerce_map_from(QQ).category()
Category of hom sets in Category of rings
> Functors should exist and
> be easily definable by users in order to map objects from one
> category into another.
> The objects in that category might
> admit a completely different set of morphisms. If one class
> of objects simultaneously exists (or can be transformed by a
> coercion functor) in more than one category, then one loses
> control over what are valid morphisms, which is precisely the
> advantage of the categorical structure.
category that is too broad.
*Theoretical* example (this is not in Sage!): Any QQ-algebra A is a QQ-
vectorspace. Let V be a QQ-vectorspace that is of the same dimension
as A. Then, it is imaginable to have a forgetful coercion morphism
from A to V in the category of QQ-vectorspaces. Hence, A.one()
+V.zero() would be an element of V, no error is raised.
I doubt this is what we want!
> Similarly construction of the pushout (I would prefer [fibered]
> coproduct or sum) in the category of embedded number fields is
> questionable for the same reason. First, one has to create a
> new object, which might be computationally expensive;
being defined as pushout(K1,K2)? Well, of course a new object must be
created, because the pushout of L1 and L2 *is* a new object (compare
the pushout of QQ and ZZ['t'], which is a new object as well).
Or do you mean a different situation?
Cheers,
Simon
David R. Kohel
> > coproduct or sum) in the category of embedded number fields is
> > questionable for the same reason. �First, one has to create a
> > new object, which might be computationally expensive;
>
> Do you mean in the situation (L1 -> K1), (L2 -> K2) and pushout(L1,L2)
> being defined as pushout(K1,K2)? Well, of course a new object must be
> created, because the pushout of L1 and L2 *is* a new object (compare
> the pushout of QQ and ZZ['t'], which is a new object as well).
Yes, this worries me somewhat -- both pushout(L1,L2) and pushout(QQ,ZZ[t])
-- since they create new objects, which are basically defined by a functor
from the product category ComAlg x ComAlg to ComAlg (together with the
canonical morphisms of L1 and L2 into L1 \otimes L2). The coercion is
a morphism, to a functorially created object, and opens the question of
which pairs (A,B) do we create A \otimes B? The answer would seem to
be determined by a mix of computational efficiency, existence of an
implementation, and maybe some judgment of how canonical the result is
(based for example on the size of the automorphism group of the result).
--David