dual (co)algebras

[Franco Saliola]

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

--

[Simon King]

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

[Franco Saliola]

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

--

[John H Palmieri]

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

[John H Palmieri]

 
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

[Franco Saliola]

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

--

[Nicolas M. Thiery]

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/

[John H Palmieri]

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

[Franco Saliola]

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.

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

Why doesn't if feel right to you? I would expect different behaviour
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

--