37 views

Skip to first unread message

Aug 14, 2012, 11:58:58 AM8/14/12

to sage-combinat-devel, sage-a...@googlegroups.com

Hello,

What should the method that returns the dual of an algebraic object be called?

For example, the dual Hopf algebra of non-commutative symmetric

functions is the Hopf algebra of quasi-symmetric functions.

At #8899, I am using the following:

- dual_space -- returns the dual Hopf algebra

- dual_basis -- returns the dual basis of a basis

- dual_pairing -- the pairing between a basis and its dual basis

Is there already a convention for this that I should be using?

Thanks,

Franco

--

What should the method that returns the dual of an algebraic object be called?

For example, the dual Hopf algebra of non-commutative symmetric

functions is the Hopf algebra of quasi-symmetric functions.

At #8899, I am using the following:

- dual_space -- returns the dual Hopf algebra

- dual_basis -- returns the dual basis of a basis

- dual_pairing -- the pairing between a basis and its dual basis

Is there already a convention for this that I should be using?

Thanks,

Franco

--

Aug 14, 2012, 2:16:50 PM8/14/12

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

Hi Franco,

On 2012-08-14, Franco Saliola <sal...@gmail.com> wrote:

> What should the method that returns the dual of an algebraic object be called?

I don't know whether a convention exists. But I would suggest the

convention

dual_<name-of-structure>

Hence, if you have a vector space V then I'd suggest that

V.dual_vector_space() returns what it says, and ...

> For example, the dual Hopf algebra of non-commutative symmetric

> functions is the Hopf algebra of quasi-symmetric functions.

... H.dual_hopf_algebra() returns the dual Hopf algebra of a Hopf

algebra H.

> At #8899, I am using the following:

>

> - dual_space -- returns the dual Hopf algebra

I would tend to expect that dual_space returns the dual (vector)

*space*, not a Hopf algebra.

> - dual_basis -- returns the dual basis of a basis

> - dual_pairing -- the pairing between a basis and its dual basis

Would just "pairing" be clear enough? Or perhaps "duality_pairing",

because the pairing is not dual, but comes from duality.

> Is there already a convention for this that I should be using?

I don't know. So, my suggestions are not backed up by an existing

convention.

Cheers,

Simon

On 2012-08-14, Franco Saliola <sal...@gmail.com> wrote:

> What should the method that returns the dual of an algebraic object be called?

convention

dual_<name-of-structure>

Hence, if you have a vector space V then I'd suggest that

V.dual_vector_space() returns what it says, and ...

> For example, the dual Hopf algebra of non-commutative symmetric

> functions is the Hopf algebra of quasi-symmetric functions.

algebra H.

> At #8899, I am using the following:

>

> - dual_space -- returns the dual Hopf algebra

*space*, not a Hopf algebra.

> - dual_basis -- returns the dual basis of a basis

> - dual_pairing -- the pairing between a basis and its dual basis

because the pairing is not dual, but comes from duality.

> Is there already a convention for this that I should be using?

convention.

Cheers,

Simon

Aug 14, 2012, 2:51:16 PM8/14/12

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

Hello Simon,

On Tue, Aug 14, 2012 at 2:16 PM, Simon King <simon...@uni-jena.de> wrote:

> Hi Franco,

>

> On 2012-08-14, Franco Saliola <sal...@gmail.com> wrote:

>> What should the method that returns the dual of an algebraic object be called?

>

> I don't know whether a convention exists. But I would suggest the

> convention

> dual_<name-of-structure>

>

> Hence, if you have a vector space V then I'd suggest that

> V.dual_vector_space() returns what it says, and ...

>

>> For example, the dual Hopf algebra of non-commutative symmetric

>> functions is the Hopf algebra of quasi-symmetric functions.

>

> ... H.dual_hopf_algebra() returns the dual Hopf algebra of a Hopf

> algebra H.

I thought about that, but would the Hopf algebra then also have the methods

dual_vector_space

dual_coalgebra

dual_algebra

...

since it is a vector space, an algebra, a coalgebra, etc.?

What about just "dual"? By default, it would compute the dual with

respect to the category to which it belongs, and we can allow

customization like so:

sage: H.dual(category=VectorSpaces(QQ))

... a vector space ...

>> At #8899, I am using the following:

>>

>> - dual_space -- returns the dual Hopf algebra

>

> I would tend to expect that dual_space returns the dual (vector)

> *space*, not a Hopf algebra.

>

>> - dual_basis -- returns the dual basis of a basis

>> - dual_pairing -- the pairing between a basis and its dual basis

>

> Would just "pairing" be clear enough? Or perhaps "duality_pairing",

> because the pairing is not dual, but comes from duality.

I like duality_pairing.

Thanks, Simon.

Franco

--

On Tue, Aug 14, 2012 at 2:16 PM, Simon King <simon...@uni-jena.de> wrote:

> Hi Franco,

>

> On 2012-08-14, Franco Saliola <sal...@gmail.com> wrote:

>> What should the method that returns the dual of an algebraic object be called?

>

> I don't know whether a convention exists. But I would suggest the

> convention

> dual_<name-of-structure>

>

> Hence, if you have a vector space V then I'd suggest that

> V.dual_vector_space() returns what it says, and ...

>

>> For example, the dual Hopf algebra of non-commutative symmetric

>> functions is the Hopf algebra of quasi-symmetric functions.

>

> ... H.dual_hopf_algebra() returns the dual Hopf algebra of a Hopf

> algebra H.

dual_vector_space

dual_coalgebra

dual_algebra

...

since it is a vector space, an algebra, a coalgebra, etc.?

What about just "dual"? By default, it would compute the dual with

respect to the category to which it belongs, and we can allow

customization like so:

sage: H.dual(category=VectorSpaces(QQ))

... a vector space ...

>> At #8899, I am using the following:

>>

>> - dual_space -- returns the dual Hopf algebra

>

> I would tend to expect that dual_space returns the dual (vector)

> *space*, not a Hopf algebra.

>

>> - dual_basis -- returns the dual basis of a basis

>> - dual_pairing -- the pairing between a basis and its dual basis

>

> Would just "pairing" be clear enough? Or perhaps "duality_pairing",

> because the pairing is not dual, but comes from duality.

Thanks, Simon.

Franco

--

Aug 14, 2012, 3:50:17 PM8/14/12

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

I think "H.dual()" is good. Specifying a category like this also, as well as

sage: VectorSpaces(QQ)(H.dual())

to return the same thing as H.dual(category=...)

--

John

Aug 14, 2012, 5:23:17 PM8/14/12

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

On Tuesday, August 14, 2012 1:27:49 PM UTC-7, Simon King wrote:

["Followup-To:" header set to gmane.comp.mathematics.sage.algebra.]

On 2012-08-14, John H Palmieri <jhpalm...@gmail.com> wrote:

> ------=_Part_11_31037299.1344973817229

>> What about just "dual"? By default, it would compute the dual with

>> respect to the category to which it belongs, and we can allow

>> customization like so:

>

>

>> sage: H.dual(category=VectorSpaces(QQ))

>> ... a vector space ...

>>

>

> I think "H.dual()" is good. Specifying a category like this also, as well as

>

> sage: VectorSpaces(QQ)(H.dual())

Start with an object O in some category C1, take its dual D in C1, and apply

the forgetful functor to map it to a sub-category C2; one would not always get

the same result as if one first applies the forgetful functor to O and then

dualise the result in C2, right?

And hence VectorSpaces(QQ)(H.dual()) might (perhaps not here, but in other

situations) be different from (VectorSpaces(QQ)(H)).dual(). Would that

be a problem?

I agree that they might be different in some situations, but I also think it's clear what each means: either dualize first or apply the forgetful functor first. Anyway, I don't think it's a problem. (My original message might have said the wrong thing, though.)

--

John

Aug 15, 2012, 11:02:24 AM8/15/12

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

Hello,

I wrote docstrings for the methods dual and duality_pairing and

created a ticket:

http://trac.sagemath.org/sage_trac/ticket/13372

Now someone has to write the code. :-)

Franco

--

I wrote docstrings for the methods dual and duality_pairing and

created a ticket:

http://trac.sagemath.org/sage_trac/ticket/13372

Now someone has to write the code. :-)

Franco

--

Aug 19, 2012, 11:02:49 AM8/19/12

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

Hi Franco!

On Tue, Aug 14, 2012 at 02:51:16PM -0400, Franco Saliola wrote:

> What about just "dual"? By default, it would compute the dual with

> respect to the category to which it belongs, and we can allow

> customization like so:

>

> sage: H.dual(category=VectorSpaces(QQ))

> ... a vector space ...

Coming a bit late in the discussion, but I vote +1 on this. That's

what we had in MuPAD-Combinat (without the category argument).

There is one glitch though, which bothered us too in

MuPAD-Combinat. In the case of NCSF/QSym, it's not exactly the dual

that we are constructing, but the graded dual. We did not bother

finding a solution in MuPAD-Combinat because we were only considering

graded duals. But eventually, we will want to also manipulate the full

dual, i.e. infinite series.

So should this be called graded_dual? Should this react depending on

whether we pass a category which is graded or not (a priori, it does

not feel right to me, but ...)?

Of course, the same glitch occurs for the "dual" functorial

construction (which is basically empty yet).

Cheers,

Nicolas

--

Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>

http://Nicolas.Thiery.name/

On Tue, Aug 14, 2012 at 02:51:16PM -0400, Franco Saliola wrote:

> What about just "dual"? By default, it would compute the dual with

> respect to the category to which it belongs, and we can allow

> customization like so:

>

> sage: H.dual(category=VectorSpaces(QQ))

> ... a vector space ...

what we had in MuPAD-Combinat (without the category argument).

There is one glitch though, which bothered us too in

MuPAD-Combinat. In the case of NCSF/QSym, it's not exactly the dual

that we are constructing, but the graded dual. We did not bother

finding a solution in MuPAD-Combinat because we were only considering

graded duals. But eventually, we will want to also manipulate the full

dual, i.e. infinite series.

So should this be called graded_dual? Should this react depending on

whether we pass a category which is graded or not (a priori, it does

not feel right to me, but ...)?

Of course, the same glitch occurs for the "dual" functorial

construction (which is basically empty yet).

Cheers,

Nicolas

--

Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>

http://Nicolas.Thiery.name/

Aug 19, 2012, 12:43:05 PM8/19/12

to sage-a...@googlegroups.com, sage-comb...@googlegroups.com, Nicolas M. Thiery

On Sunday, August 19, 2012 8:02:49 AM UTC-7, Nicolas M. Thiéry wrote:

Hi Franco!

On Tue, Aug 14, 2012 at 02:51:16PM -0400, Franco Saliola wrote:

> What about just "dual"? By default, it would compute the dual with

> respect to the category to which it belongs, and we can allow

> customization like so:

>

> sage: H.dual(category=VectorSpaces(QQ))

> ... a vector space ...

Coming a bit late in the discussion, but I vote +1 on this. That's

what we had in MuPAD-Combinat (without the category argument).

There is one glitch though, which bothered us too in

MuPAD-Combinat. In the case of NCSF/QSym, it's not exactly the dual

that we are constructing, but the graded dual. We did not bother

finding a solution in MuPAD-Combinat because we were only considering

graded duals. But eventually, we will want to also manipulate the full

dual, i.e. infinite series.

So should this be called graded_dual? Should this react depending on

whether we pass a category which is graded or not (a priori, it does

not feel right to me, but ...)?

I think that

A.dual(category=GradedVectorSpaces(QQ))

makes sense (or category=GradedAlgebras() or ...). Maybe

A.dual(graded=True) or A.graded_dual()

should be synonyms for these. Maybe also (or instead?) for objects equipped with a grading, the default behavior should be to return the graded dual, but you can get the ungraded dual by specifying the appropriate argument, so maybe "graded_dual" should not exist, but "ungraded_dual" should, for objects with a grading? In my experience mathematically, when I want to dualize a graded object, I almost always want the graded dual, and I would expect that to be the default behavior of a "dual" method.

So we might have

A.dual() graded dual, by default

A.graded_dual(), A.ungraded_dual()

A.dual_graded(), A.dual_ungraded() good for tab completion

A.dual(graded=True), etc.

A.dual(category=Graded...), etc.

--

John

Aug 20, 2012, 10:01:55 AM8/20/12

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

On Sun, Aug 19, 2012 at 11:02 AM, Nicolas M. Thiery

<Nicolas...@u-psud.fr> wrote:

> Hi Franco!

>

> On Tue, Aug 14, 2012 at 02:51:16PM -0400, Franco Saliola wrote:

>> What about just "dual"? By default, it would compute the dual with

>> respect to the category to which it belongs, and we can allow

>> customization like so:

>>

>> sage: H.dual(category=VectorSpaces(QQ))

>> ... a vector space ...

>

> Coming a bit late in the discussion, but I vote +1 on this. That's

> what we had in MuPAD-Combinat (without the category argument).

>

> There is one glitch though, which bothered us too in

> MuPAD-Combinat. In the case of NCSF/QSym, it's not exactly the dual

> that we are constructing, but the graded dual. We did not bother

> finding a solution in MuPAD-Combinat because we were only considering

> graded duals. But eventually, we will want to also manipulate the full

> dual, i.e. infinite series.

Ah, yes, good point.
<Nicolas...@u-psud.fr> wrote:

> Hi Franco!

>

> On Tue, Aug 14, 2012 at 02:51:16PM -0400, Franco Saliola wrote:

>> What about just "dual"? By default, it would compute the dual with

>> respect to the category to which it belongs, and we can allow

>> customization like so:

>>

>> sage: H.dual(category=VectorSpaces(QQ))

>> ... a vector space ...

>

> Coming a bit late in the discussion, but I vote +1 on this. That's

> what we had in MuPAD-Combinat (without the category argument).

>

> There is one glitch though, which bothered us too in

> MuPAD-Combinat. In the case of NCSF/QSym, it's not exactly the dual

> that we are constructing, but the graded dual. We did not bother

> finding a solution in MuPAD-Combinat because we were only considering

> graded duals. But eventually, we will want to also manipulate the full

> dual, i.e. infinite series.

> So should this be called graded_dual? Should this react depending on

> whether we pass a category which is graded or not (a priori, it does

> not feel right to me, but ...)?

from the following two commands:

A.dual(category=GradedVectorSpaces(QQ))

A.dual(category=VectorSpaces(QQ))

I like the shorthand that John proposed:

A.dual(graded=True)

A.dual(graded=False)

With the default being graded=True if the category is graded.

My personal preference is to be able to access all the duality

functionality from the dual method (so no methods named graded_dual,

ungraded_dual, dual_ungraded, dual_graded, ...).

Franco

--

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu