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?
On Tue, Aug 14, 2012 at 2:16 PM, Simon King <simon.k...@uni-jena.de> wrote:
> Hi Franco,
> On 2012-08-14, Franco Saliola <sali...@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.
On Tuesday, August 14, 2012 11:51:16 AM UTC-7, Franco Saliola wrote:
> Hello Simon,
> On Tue, Aug 14, 2012 at 2:16 PM, Simon King <simon...@uni-jena.de<javascript:>> > wrote: > > Hi Franco,
> > On 2012-08-14, Franco Saliola <sal...@gmail.com <javascript:>> 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
> 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 ...
I think "H.dual()" is good. Specifying a category like this also, as well as
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 <javascript:>> 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.)
> 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.)
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).
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.
> 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:
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, ...).
