On Sun, Aug 19, 2012 at 11:02 AM, 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.
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:
I like the shorthand that John proposed:
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, ...).