2 views

Skip to first unread message

Dec 7, 2010, 3:48:48 PM12/7/10

to sage-algebra

Hi!

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

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

Dec 7, 2010, 5:15:23 PM12/7/10

to sage-a...@googlegroups.com

We are already used to non-transitive equality (==)!

John

Dec 7, 2010, 6:04:33 PM12/7/10

to sage-algebra

On 7 dic, 21:48, Simon King <simon.k...@uni-jena.de> wrote:

> 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?

I think that either we discard bidirectional coercions for embedded
> 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

Dec 7, 2010, 6:30:16 PM12/7/10

to sage-algebra

Hi Luis,

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.

Indeed, commutativity is violated. I thought non-associative cross-

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

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

Dec 8, 2010, 5:34:39 AM12/8/10

to sage-a...@googlegroups.com, sag...@googlegroups.com

Hi Simon et al,

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

Dec 8, 2010, 6:11:38 AM12/8/10

to sage-algebra

Hi David!

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?

They are morphisms.

> Once I realised that coercion was being

> used to implement myriad possible functors, I became worried.

Do you refer to the "construction functors"? It's the other way

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.

They are supposed to be morphisms in an appropriate category. However,

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.

... and to map morphisms from one category into another -- see #8807!

> 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.

Indeed, strange things would happen if a coercion would be a map in a

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;

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).

Or do you mean a different situation?

Cheers,

Simon

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

Dec 8, 2010, 7:04:28 AM12/8/10

to sage-a...@googlegroups.com

> > 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;

>

> 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).

> > 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

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu