#15305: Allow natural morphism between tensor products
-------------------------------------------+-----------------------------
Reporter: tscrim | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.13
Component: coercion | Resolution:
Keywords: tensor product coercion | Merged in:
Authors: Travis Scrimshaw | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: #15309 | Stopgaps:
-------------------------------------------+-----------------------------
Comment (by nborie):
After a second look,
My code did things exactly like you do (I mean I have no more interesting
proposition). For your current implementation, we win a 20% speedup
without using the constructor CartesianProduct and just iterate on ``im``
instead of CP for the return of the morphism subfunction.
About design, I had a discussion with Rémi Maurice (king of combinatorial
Hopf algebras implementation in Marne). Your patch and also the drafty one
I did have the same problem : we check the existence of "natural" morphism
by looking for coercion on atomic parent composing domain and codomain
position-wise. This doesn't catch everything from far... Even we forgive
about permutation of atoms in tensor product, this cut in atoms is the
best solution we currently have. This make the following problem:
{{{
sage: C1 = CombinatorialFreeModule(ZZ, ZZ)
sage: S1 = C1.tensor(C1)
sage: f = S1.module_morphism(on_basis = lambda x :
C1.monomial(x[0])+C1.monomial(x[1]), codomain=C1)
sage: f.register_as_coercion()
sage: C1(S1.an_element())
3*B[-1] + 9*B[0] + 2*B[1]
sage: S2 = S1.tensor(S1)
sage: S2.has_coerce_map_from(S1)
False
}}}
If A tensor A has coercion to B, we don't cath the "natural" coercion from
(A tensor A) tensor (A tensor A) to B tensor B.
That said, this ticket doesn't intend to solve the full research of
coercion between any couple of (tensor)combinatorial free module and this
could be very fun to have it rapidly in Sage since things like
{{{
sage: P = SymmetricFunctions(QQ).p(); P
Symmetric Functions over Rational Field in the powersum basis
sage: M = SymmetricFunctions(QQ).m(); M
Symmetric Functions over Rational Field in the monomial basis
sage: E = SymmetricFunctions(QQ).e(); E
Symmetric Functions over Rational Field in the elementary basis
sage: S = SymmetricFunctions(QQ).s(); S
Symmetric Functions over Rational Field in the Schur basis
sage: A = tensor((P, S))
sage: B = tensor((E, M))
sage: A(B.an_element())
2*p[] # s[] + 2*p[] # s[1] - 3*p[] # s[1, 1] + 3*p[] # s[2]
}}}
are very nice.
For the test of all permutations on atoms of a tensor product and each
parenthesis configuration on atoms and perhaps a coercion..... We think it
is not a good thing to check such loud thing every time. For these cases
(in which most of the time, the user know very well which is the
permutation and the packaging of the atoms for (co)domain), we should have
a nice tensor constructor which accept a tuple of morphisms (and after the
construction, we forgive the parenthesis cutting into atoms new domain and
new codomain). This should leave in a different ticket letting all current
tensor product in Sage benefit from this enhancement.
So, even I really love semantic, I would prefer a speedup version of your
patch without the CartesianProduct constructor.
Do you agree with that ?
Sorry for my English, I hope I am not too much confusing...
Cheers and thanks for your work.
Nicolas B.
--
Ticket URL: <http://trac.sagemath.org/ticket/15305#comment:8>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
