[sage-combinat-devel] progress on simplicial complexes (or "What I did on my summer vacation")
I have been working on improving Sage's capabilities with simplicial complexes. With the changes at #19179, #6101, and #6102 (all ready for review), we now have - chain homotopies - cup products (with field coefficients) - cohomology as a FiniteDimensionalAlgebra (with field coefficients) - Steenrod squares acting on cohomology (mod 2 coefficients) - maps on homology and cohomology induced by maps of simplicial complexes (with field coefficients) There is one speed bottleneck, the computation of an "algebraic topological model" for the simplicial complex. This should probably be cythonized, but I am not the person to do that. This could also be done with integer coefficients, but that requires a different algorithm. I can provide a reference if anyone wants to work on it. That will be even slower than with field coefficients, of course. If you are interested in this sort of mathematics, please take a look at the relevant tickets. http://trac.sagemath.org/ticket/19179 (which is also incorporated into 6101) http://trac.sagemath.org/ticket/6101 http://trac.sagemath.org/ticket/6102 Share and Enjoy. -- John -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Categories and the top level
I've been wondering lately about the design choice of having all of the various categories accessible at the top-level in Sage. Would it be preferable to have a catalog of categories accessible via categories.AdditiveMagmas(), etc.? Having more than 50 categories could be viewed as polluting the top-level. I certainly notice that when I hit the TAB key, I often see a bunch of categories in the list of possible completions, and I never actually use them, despite the fact that categories and functors underlie much of my research. Of course, I'm probably missing something. How often do people use these in Sage, and how much of an inconvenience would it be if you had to prefix them with categories. each time? Oh, and just to be clear, I am not volunteering to make any necessary changes. Nor am I against the status quo: I'm genuinely curious about the best approach here. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: dot2tex
On Saturday, April 26, 2014 11:31:43 AM UTC-7, slabbe wrote: One issue that is bugging me isA https://github.com/kjellmf/dot2tex/issues/13 (https://code.google.com/p/dot2tex/issues/detail?id=32) I'm not able to reproduce the issue with \verb in the current development version. I may have fixed it or things may have changed in Graphviz or pyparsing. Can you confirm if this issue is still an issue in Sage? I reported that issue. The ticket on the sage side is http://trac.sagemath.org/sage_trac/ticket/13624 If I well remember, the issue was fixed indirectly by http://trac.sagemath.org/ticket/14382 which stop adding the \verb part for labels. I am trying to confirm it on my version of Sage (sage-6.2.beta6), but it seems dot2tex is broken because it can't find pyparsing again. See comment http://trac.sagemath.org/ticket/14594#comment:62. So I am not able to confirm it is okay, but I think it was. Note that *with* doc2tex installed, I get the following error message: sage: G = DiGraph() sage: G.add_edge(, 88, 'my_label') sage: G.set_latex_options(format='dot2tex') sage: G.set_latex_options(edge_labels=True) sage: view(G) Traceback (most recent call last): ... RuntimeError: dot2tex not available. Please see :meth:`sage.graphs.generic_graph.GenericGraph.layout_graphviz` for installation instructions. which is quite bad. The real error (while importing pyparsing) is not reraised and is replaced by the one above. I just created ticket #16242 to fix this. It needs review. http://trac.sagemath.org/ticket/16242 Sébastien I think there should be a new dot2tex package which fixes the pyparsing import problem. See http://trac.sagemath.org/ticket/16026. (That said, your patch still looks like a good idea.) -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: CombinatorialFreeModules
You ask at the end what you're doing wrong. There are at least two things:
first, you should probably also post this message to sage-combinat-devel,
which gets a lot more traffic. I'm cc'ing that group. Second, the very last
error message is partly a clue:
TypeError: unhashable type: 'list'
Try using tuples everywhere instead of lists. For example, you could use the
line
threecolouredpart+=tuple([tuple([x,y,z]) for x in Partitions(i) for y in
Partitions(j) for z in Partitions(weight-i-j)])
in your function. Also, I'm not sure what FiniteCombinatorialClass is supposed
to do for you here; if I do
FiniteCombinatorialClass(genThreeColouredPartitions(2))
it seems to work just fine (after replacing the lists with tuples): it can tell
that the basis is a FiniteFamily. If I do use FiniteCombinatorialClass, then I
just see LazyFamily, the way you do.
--
John
On Sunday, April 13, 2014 6:51:02 AM UTC-7, Simon Wood wrote:
Good day everyone,
I am trying to get to grips with CombinatorialFreeModules. The
combinatorial basis I am trying to use is 3-coloured partitions. But I'm
not sure how to correctly define combinatorial classes.
What I've done so far is the following:
def genThreeColouredPartitions(weight): #generates all triples of
partitions with total weight equal to 'weight'
threecolouredpart= []
for i in range(weight+1):
for j in range(weight-i+1):
threecolouredpart+=[[x,y,z] for x in Partitions(i) for y in
Partitions(j) for z in Partitions(weight-i-j)]
return threecolouredpart
If I try to use these 3-coloured partitions to define a Combinatorial free
module things don't work the way I expect.
M =
CombinatorialFreeModule(QQbar,FiniteCombinatorialClass(genThreeColouredPartitions(2)));
M
Output=
Free module generated by Combinatorial class with elements in [[[], [],
[2]], [[], [], [1, 1]], [[], [1], [1]], [[], [2], []], [[], [1, 1], []],
[[1], [], [1]], [[1], [1], []], [[2], [], []], [[1, 1], [], []]] over
Algebraic Field
e=M.basis();e
Output=
Lazy family (Term map from Combinatorial class with elements in [[[],
[], [2]], [[], [], [1, 1]], [[], [1], [1]], [[], [2], []], [[], [1, 1],
[]], [[1], [], [1]], [[1], [1], []], [[2], [], []], [[1, 1], [], []]] to
Free module generated by Combinatorial class with elements in [[[], [],
[2]], [[], [], [1, 1]], [[], [1], [1]], [[], [2], []], [[], [1, 1], []],
[[1], [], [1]], [[1], [1], []], [[2], [], []], [[1, 1], [], []]] over
Algebraic Field(i))_{i in Combinatorial class with elements in [[[], [],
[2]], [[], [], [1, 1]], [[], [1], [1]], [[], [2], []], [[], [1, 1], []],
[[1], [], [1]], [[1], [1], []], [[2], [], []], [[1, 1], [], []]]}
Why is this a lazy family and not a finite family? I do not seem to be able
to iterate over the basis.
for i in e:
i
Output=
Traceback (most recent call last):
File stdin, line 1, in module
File _sage_input_11.py, line 10, in module
exec compile(u'open(___code___.py,w).write(# -*- coding: utf-8
-*-\\n +
_support_.preparse_worksheet_cell(base64.b64decode(Zm9yIGkgaW4gZToKICAgIGk=),globals())+\\n);
execfile(os.path.abspath(___code___.py))
File , line 1, in module
File /tmp/tmpm0bNnU/___code___.py, line 2, in module
exec compile(u'for i in e:\ni
File , line 1, in module
File
/home/sageuser/sage/local/lib/python2.7/site-packages/sage/sets/family.py,
line 952, in __iter__
yield self[i]
File
/home/sageuser/sage/local/lib/python2.7/site-packages/sage/sets/family.py,
line 968, in __getitem__
return self.function(i)
File
/home/sageuser/sage/local/lib/python2.7/site-packages/sage/categories/poor_man_map.py,
line 125, in __call__
return self._function(*args)
File
/home/sageuser/sage/local/lib/python2.7/site-packages/sage/combinat/free_module.py,
line 2176, in _monomial
return self._from_dict( {index: self.base_ring().one()}, remove_zeros =
False )
TypeError: unhashable type: 'list'
Can anyone tell me what I am doing wrong?
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: [sage-algebra] Re: CombinatorialFreeModules
Hi Travis,
I appreciate your trying to accept some of the blame. I'm not really
convinced that much of it is really your fault, and I wasn't asking for
anyone to step forward. (Not that it really matters, but ere you even
involved in Sage development 4 years ago?)
Instead, I have two points: Sage could have been better 4 years ago with
this code in it, and the reasons (as far as I understand them) for not
merging it when it was first submitted don't really hold water. For the
first point: with this particular ticket, there have been a number of
times, in these newsgroups, at ask.sagemath.org, and probably in other
contexts, where someone asked how do you do X with
CombinatorialFreeModule or what's a basic example of how to define an
algebra with a distinguished basis or ..., and rather than be able to
point to this code as part of Sage, I could only refer to the patch (along
with some of the existing code in categories/examples, etc.). There were
probably other people with similar questions and concerns who didn't ask,
and so didn't find out about this. Documentation and good examples are very
important to any computer code, and certainly to Sage. So I think real
damage may have been done by the slowness in merging this particular code.
For the second point, I think that after I submitted the code, the response
was basically, that's good, but we really need to get some of the
underlying framework in place first. In retrospect, since it has taken 4
years and may take another 4 for all I know, it would have been *much*
better to merge the code first, then revise it accordingly when (or if) the
underlying framework is part of Sage. Maybe future situations can be dealt
with better, keeping this sort of experience in mind.
John
On Sunday, April 13, 2014 9:51:27 PM UTC-7, Travis Scrimshaw wrote:
Hey John,
A good part of that is my fault. I need to get that dependency done, or we
need to switch the indexing set for the example.
Hey Simon,
You might also be interested in #14901 (
http://trac.sagemath.org/ticket/14901) (which I'll rebase shortly once I
fix a few things I've broken trying to refactor things). I'm hoping to get
a big chunk of work on finishing that over the next few months. I'd
appreciate it if you could keep me in the loop on your progress.
Best,
Travis
On Sunday, April 13, 2014 8:59:23 PM UTC-7, Simon Wood wrote:
Thank you John. I'll give that code a spin. Graded algebras are exactly
what I am interested in. The code snippet I presented in my first post was
a stepping stone on the way to defining Verma modules over affine Kac-Moody
algebras (which are graded as you probably know).
Anyway, I'll keep fiddling with the code. Thanks for your help.
Best,
Simon
On Monday, April 14, 2014 1:37:11 PM UTC+10, John H Palmieri wrote:
You might look at the code in the file
http://trac.sagemath.org/attachment/ticket/9280/trac_9280_nomodule.patch
This is a patch (which *should* have been merged into Sage 4 years ago,
but forces beyond my control have so far prevented this; don't get me
started) which uses CombinatorialFreeModules to define a simple-minded
version of a graded polynomial algebra, partly to illustrate the sorts of
things you're talking about. In particular, it has an infinite basis which
is made up of finite pieces, and it also uses the category structure in
Sage to define the produce just on basis elements.
You can also browse the existing Sage code (execute for example
search_src('CombinatorialFreeModule')) to see other uses of
CombinatorialFreeModule. Maybe some of them will be helpful.
John
On Sunday, April 13, 2014 6:52:38 PM UTC-7, Simon Wood wrote:Hi John,
That was very helpful thank you! Now I can generate the basis elements
and add them up and the likes.
There are two more things things I want to do:
1) Allow the 3-coloured partitions to be any non-neg integer weight,
i.e., take the direct sum over all non-neg integer weights.
2) Define operations on the basis elements and extend them linearly to
the entire module.
I'll just keep playing around with the code and see how far I get.
Thanks again for your help.
Best,
Simon
On 14 April 2014 00:54, John H Palmieri jhpalm...@gmail.com wrote:
You ask at the end what you're doing wrong. There are at least two
things:
first, you should probably also post this message to
sage-combinat-devel,
which gets a lot more traffic. I'm cc'ing that group. Second, the very
last
error message is partly a clue:
TypeError: unhashable type: 'list'
Try using tuples everywhere instead of lists. For example, you could
use the
line
threecolouredpart+=tuple([tuple([x,y,z]) for x in Partitions(i)
for y in
Partitions(j) for z
[sage-combinat-devel] Re: [sage-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions
On Tuesday, March 11, 2014 12:40:41 PM UTC-7, Nathann Cohen wrote: On that note, I think reviewers shouldn't hold up tickets because they don't like the current implementation without providing a working alternative and can demonstrate why it's better. Do you think that a patch should automatically be merged when it has been waiting for a reviewer for a long time ? With regards to #10963, the ticket had been reviewed and indeed had gotten a positive review, and then some other people looked at it and started asking questions. So Nicolas is not trying to bypass the review process, but rather trying to sort out a disagreement among the various participants on the ticket. That's probably too brief to adequately summarize what's going on, but anyway, I think your question is not really relevant to this particular ticket. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: Tensors on free modules of finite rank
Quick question: why not use the class sage.modules.free_module.FreeModule_generic? Longer question/comment (not directed at you, but at the general situation in Sage): is it a problem to have multiple parallel developments of free modules, one in sage.modules.free_module, one in sage.combinat.free_module, and then possibly a new one in this ticket? (It doesn't seem like a good idea to me.) Should they all be unified somehow? Are there any plans to do that? For my own uses, the version in combinat.free_module has been the most relevant, but it's not in an obvious place; there is nothing intrinsically combinatorial about it, is there? We could move it to sage.module.free_module_with_basis, for example... John On Monday, March 10, 2014 9:09:01 AM UTC-7, Eric Gourgoulhon wrote: Hi, A new enhancement, devoted to tensors on generic free modules of finite rank, has been submitted to trac (ticket #15916http://trac.sagemath.org/ticket/15916). By *generic*, it is meant *without any distinguished basis*. *Description* This ticket implements: - tensor products of the type M\otimes ...\otimes M \otimes M^* \otimes...\otimes M^* (k factors of M and l factors of M*, say) where M is a free module of finite rank over a commutative ring R and M^* is its dual - the elements of the above tensor products, considered as tensors of type (k,l) on M, i.e. multilinear forms (M^*)^k \times M^l -- R, thanks to the canonical isomorphism M^** = M (which holds since M is a free module of finite rank) - the following tensor operations: * operations inherent to the module structure (addition, multiplication by a ring element) * tensor product of two tensors * tensor contraction * symmetry / antisymmetry handling (on subset of the tensor arguments or on all arguments) * exterior product of alternating forms No distinguished basis is assumed on the free module M; on the contrary many bases can be introduced. Each tensor has then various representations, via its components in the various bases. *Motivation and context* The ticket has been motivated by tensors on smooth manifolds over \RR, within the SageManifolds http://sagemanifolds.obspm.fr/ project. In this context, tensors on free modules appear at two places: - tensors on tangent spaces: * commutative ring R = real field \RR * free module M = tangent vector space at a given manifold's point - tensor fields on a manifold: * commutative ring R = the set C^\infty(N) of smooth functions N-- \RR, where N is a parallelizable open set of the manifold * free module M = the set X(N) of smooth vector fields on N (since N is parallelizable, this is a free module; its rank is the manifold's dimension) *Documentation* Apart from the numerous doctests in the code, some pieces of documentation are - the tutorial worksheet posted herehttp://sagemanifolds.obspm.fr/examples/html/SM_tensors_modules.html (the pdf version is herehttp://sagemanifolds.obspm.fr/examples/pdf/SM_tensors_modules.pdf ) - the reference manualhttp://sagemanifolds.obspm.fr/doc/tensors_free_module/index.html(the pdf version is here http://sagemanifolds.obspm.fr/doc/tensors_free_modules_ref.pdf); it can also be generated via the command sage -docbuild tensors_free_module html See also this page http://sagemanifolds.obspm.fr/tensor_modules.html. *Remarks* 1/ Although developed in the context of SageManifolds, the ticket is self-contained and does not depend on other parts of SageManifolds. It this respect, it can be viewed as some attempt to include a first subset of SageManifolds in Sage, with a moderate size: the ticket comprises 9391 lines of Python code (most of them being doctests), while at present SageManifolds contains 29240 lines of code. 2/ The ticket follows Sage's Parent/Element scheme and the (new) category framework. In particular, the ticket's free module class (FiniteFreeModule) passes the module TestSuite. 3/ It turned out to be necessary to develop a new class to implement free modules of finite rank. Indeed, the category of free modules does not exist yet in Sage: only those of generic modules (Modules) or free modules with a distinguished basis (ModulesWithBasis) are available. Now, the tangent space at a given point of a manifold is a vector space without any distinguished basis (in other words, while the tangent space is isomorphic to \RR^n, there is no *canonical* isomorphism, each isomorphism relying on the choice of some coordinate chart). The new class, FiniteFreeModulehttp://sagemanifolds.obspm.fr/doc/tensors_free_module/finite_free_module.html, does not rely on any distinguished basis. It inherits directly from sage.modules.module.Module. In particular, it does not inherit from sage.modules.module.Module_old.FreeModule_generic since the latter does not conform to the new coercion model and seems to assume a distinguished
Re: [sage-combinat-devel] tensor products of free modules; combinatorial algebras
On Friday, February 14, 2014 6:18:42 PM UTC-8, Mark Shimozono wrote: Nicolas, In your case, to implement the smash product, you probably want to implement a subclass of CombinatorialFreeModuleTensor, set its category to the join of ModulesWithBasis(QQ).TensorProducts() and AlgebrasWithBasis(QQ), and implement the product similarly to what's done for tensor products of algebras with basis. I would dearly love to be able to construct elements in my class in an automatically multilinear way, using the _tensor_of_elements method for tensor products of modules. However sage won't let me. Basically it has an overly restrictive type check which fails. Here is a toy version of my class: class MyTensorProductOfAlgebras(CombinatorialFreeModule_Tensor): def __init__(self, A, B): R = A.base_ring() CombinatorialFreeModule_Tensor.__init__(self, [A,B], \ category=Category.join((AlgebrasWithBasis(R),ModulesWithBasis(R).TensorProducts( The code calling the _element_tensor method for the vanilla instance T: sage: L = CartanType(['A',2]).root_system().weight_lattice() sage: A = L.algebra(ZZ) sage: a = A.an_element() sage: T = tensor([A,A]) sage: T._tensor_of_elements([a,a]) B[2*Lambda[1] + 2*Lambda[2]] # B[2*Lambda[1] + 2*Lambda[2]] and the custom class TT: sage: TT = MyTensorProductOfAlgebras(A,A) TT._tensor_of_elements([a,a]) AssertionError and the offending line is: assert(sage.categories.tensor.tensor(modules) == self) where modules is the list of modules to be tensored and self is the instance that is invoking _tensor_of_elements. Note that sage: T and sage: TT give the same exact description string. Any solutions/workarounds? Surely there is no need to reimplement the multilinearity! --Mark You could reimplement the 'tensor_constructor' method for your class: just copy over the one from CombinatorialFreeModule_Tensor in combinat/free_module.py, but delete the line assert(sage.categories.tensor.tensor(modules) == self) Or you could patch free_module.py, adding an optional argument, say type_check=True, to both tensor_constructor and _tensor_of_elements, and only do this assertion if type_check is True. Other suggestions? -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] tensor products of free modules; combinatorial algebras
On Friday, February 14, 2014 9:06:35 PM UTC-8, John H Palmieri wrote: On Friday, February 14, 2014 6:18:42 PM UTC-8, Mark Shimozono wrote: Nicolas, In your case, to implement the smash product, you probably want to implement a subclass of CombinatorialFreeModuleTensor, set its category to the join of ModulesWithBasis(QQ).TensorProducts() and AlgebrasWithBasis(QQ), and implement the product similarly to what's done for tensor products of algebras with basis. I would dearly love to be able to construct elements in my class in an automatically multilinear way, using the _tensor_of_elements method for tensor products of modules. However sage won't let me. Basically it has an overly restrictive type check which fails. Here is a toy version of my class: class MyTensorProductOfAlgebras(CombinatorialFreeModule_Tensor): def __init__(self, A, B): R = A.base_ring() CombinatorialFreeModule_Tensor.__init__(self, [A,B], \ category=Category.join((AlgebrasWithBasis(R),ModulesWithBasis(R).TensorProducts( The code calling the _element_tensor method for the vanilla instance T: sage: L = CartanType(['A',2]).root_system().weight_lattice() sage: A = L.algebra(ZZ) sage: a = A.an_element() sage: T = tensor([A,A]) sage: T._tensor_of_elements([a,a]) B[2*Lambda[1] + 2*Lambda[2]] # B[2*Lambda[1] + 2*Lambda[2]] and the custom class TT: sage: TT = MyTensorProductOfAlgebras(A,A) TT._tensor_of_elements([a,a]) AssertionError and the offending line is: assert(sage.categories.tensor.tensor(modules) == self) where modules is the list of modules to be tensored and self is the instance that is invoking _tensor_of_elements. Note that sage: T and sage: TT give the same exact description string. Any solutions/workarounds? Surely there is no need to reimplement the multilinearity! --Mark You could reimplement the 'tensor_constructor' method for your class: just copy over the one from CombinatorialFreeModule_Tensor in combinat/free_module.py, but delete the line assert(sage.categories.tensor.tensor(modules) == self) Or you could patch free_module.py, adding an optional argument, say type_check=True, to both tensor_constructor and _tensor_of_elements, and only do this assertion if type_check is True. Oh, heh, if you go this route, then you actually have to use the optional argument somehow. Maybe instead you should define an attribute self._type_check and set it when you initialize an instance of the class. The default value would be True, but when you initialize your version, you would set it to False. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: [sage-devel] poll for making dot2tex a standard spkg
On Wednesday, May 22, 2013 9:58:56 AM UTC-7, Nicolas M. Thiéry wrote: On Wed, May 22, 2013 at 09:13:09AM -0700, kcrisman wrote: A standard package which is only useful in the presence of an optional package doesn't make sense to me. It simplifies our users's life, and that is useful! Also it simplifies *my* life: I am tired, e.g. during Sage Days, of having to explain about Sage packages to our complete beginners for something that is often one of the very first feature that they want to play with. Is graphviz a run-time dependency of dot2tex? That is, can someone install graphviz after building Sage (including dot2tex, if it were a standard spkg) and have it work, or would they need to rebuild dot2tex? -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: WARNING: Docbuilder patch (#6495) going into combinat
On Tuesday, February 19, 2013 6:23:08 PM UTC-8, Andrew Mathas wrote: Hi Travis, The queue isn't applying for in using version 5.6 even with this spkg installed. Specifically, trac_6495-part1-moving-files-link.patch does not apply. It's not a big deal as I can just move to 5.7.rc0 but it might affect others. Andrew You might have to add the patches from the dependency tickets listed at #6495. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: problems with documentation build
On Thursday, December 13, 2012 9:03:51 AM UTC-8, Volker Braun wrote: Works for me on Firefox 17.0.1 on Linux x86_64. Can somebody try and see if its fixed in more recent recent release? In more detail: go to http://www.mathjax.org/download/ and follow the link for Current Version: MathJax-2.1. Unzip the file to get a directory called something like ~/Downloads/mathjax-MathJax-24a378e. Now, go to SAGE_ROOT/devel/sagenb/sagenb/data and do $ mv mathjax mathjax-old $ mv ~/Downloads/mathjax-MathJax-24a378e mathjax and try looking at the documentation. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/fWfuYoY47ugJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: problems with documentation build
On Thursday, December 13, 2012 9:09:15 AM UTC-8, John H Palmieri wrote: On Thursday, December 13, 2012 9:03:51 AM UTC-8, Volker Braun wrote: Works for me on Firefox 17.0.1 on Linux x86_64. Can somebody try and see if its fixed in more recent recent release? In more detail: go to http://www.mathjax.org/download/ and follow the link for Current Version: MathJax-2.1. Or perhaps Volker meant a more recent release of Firefox. What is the most recent release available for OS X 10.6.8? -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/lCFZQHfbZAYJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: problems with documentation build
On Thursday, December 13, 2012 9:17:24 AM UTC-8, Volker Braun wrote: On Thursday, December 13, 2012 5:13:38 PM UTC, John H Palmieri wrote: Or perhaps Volker meant a more recent release of Firefox. What is the most recent release available for OS X 10.6.8? Thats what I meant - most recent version is 17.0.1 on all platforms. I wonder if upgrading MathJax would help anyway. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/zsS8xVr14eYJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: number_of_partitions and friends
On Wednesday, August 29, 2012 4:53:33 PM UTC-7, Anne Schilling wrote: In principle, reading the documentation of Partitions the command sage: RestrictedPartitions(5,[3,2,1], 3).list() [[3, 1, 1], [2, 2, 1]] should be achieved by sage: Partitions(5, parts_in = [3,2,1], max_length=3) Partitions of the integer 5 with parts in [1, 2, 3] but unfortunately max_length is not taken into account: sage: Partitions(5, parts_in = [3,2,1], max_length=3).list() [[3, 2], [3, 1, 1], [2, 2, 1], [2, 1, 1, 1], [1, 1, 1, 1, 1]] Is this a bug? The documentation for Partitions says Right now, the parts_in, starting, and ending keyword arguments are mutually exclusive, both of each other and of other keyword arguments. If you specify, say, parts_in, all other keyword arguments will be ignored; starting and ending work the same way. So it's not a bug: it's documented. (Not ideal behavior, I think, but at least it's documented.) -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/HvSrQi6Wn4kJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: number_of_partitions and friends
On Wednesday, August 29, 2012 5:21:31 PM UTC-7, Anne Schilling wrote: On 8/29/12 5:11 PM, John H Palmieri wrote: On Wednesday, August 29, 2012 4:53:33 PM UTC-7, Anne Schilling wrote: In principle, reading the documentation of Partitions the command sage: RestrictedPartitions(5,[3,2,1], 3).list() [[3, 1, 1], [2, 2, 1]] should be achieved by sage: Partitions(5, parts_in = [3,2,1], max_length=3) Partitions of the integer 5 with parts in [1, 2, 3] but unfortunately max_length is not taken into account: sage: Partitions(5, parts_in = [3,2,1], max_length=3).list() [[3, 2], [3, 1, 1], [2, 2, 1], [2, 1, 1, 1], [1, 1, 1, 1, 1]] Is this a bug? The documentation for Partitions says Right now, the parts_in, starting, and ending keyword arguments are mutually exclusive, both of each other and of other keyword arguments. If you specify, say, parts_in, all other keyword arguments will be ignored; starting and ending work the same way. So it's not a bug: it's documented. (Not ideal behavior, I think, but at least it's documented.) Then I think the functionality of RestrictedPartitions should be fully implemented in Partitions by allowing several keyword entries. That sounds fine to me. I think that RestrictedPartitions should not be removed until this happens. This could be addressed at #12278 or at #13072. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/jB_VJnwfYPIJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: number_of_partitions and friends
On Friday, August 24, 2012 12:29:06 AM UTC-7, Nicolas M. Thiery wrote: On Thu, Aug 23, 2012 at 04:48:31PM -0700, Andrew Mathas wrote: Here, I think, is the complete list together with their recommended replacements: Thanks! If no one has complained in, say, two days, please go ahead. I don't think it's a good idea to remove functions from the global name space with no warning. If they were already deprecated, sure, but if not: deprecate them now, and remove them from the global name space in 6 months or a year. I remember seeing number_of_partitions used in some Sage demo talks, for example at least one talk by William Stein, so removing it seems dangerous to me. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/wolUPUUbR4QJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Sage compared to LiE
On Wednesday, August 22, 2012 11:40:05 AM UTC-7, Anne Schilling wrote: Hi All! Savdeep Sethi made a summary of a comparison between Sage and LiE. Any volunteers to port or implement the functionality of LiE to Sage? There is already an optional LiE spkg for Sage [1]. I don't know anything about it, for example whether it even builds. But that would perhaps be a place to start. [1] http://www.sagemath.org/packages/optional/lie-2.2.2.p4.spkg -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/7trakn2M_ZAJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Sage compared to LiE
On Wednesday, August 22, 2012 11:47:08 AM UTC-7, John H Palmieri wrote: On Wednesday, August 22, 2012 11:40:05 AM UTC-7, Anne Schilling wrote: Hi All! Savdeep Sethi made a summary of a comparison between Sage and LiE. Any volunteers to port or implement the functionality of LiE to Sage? There is already an optional LiE spkg for Sage [1]. I don't know anything about it, for example whether it even builds. But that would perhaps be a place to start. [1] http://www.sagemath.org/packages/optional/lie-2.2.2.p4.spkg Note also SAGE_ROOT/devel/sage/sage/interfaces/lie.py. Anyway, I just tried it out. The spkg-install file relies on the GNU version of 'mv', so it doesn't install on my mac without this change: diff --git a/spkg-install b/spkg-install --- a/spkg-install +++ b/spkg-install @@ -25,5 +25,5 @@ cd .. sed -i -e s'$PWD/src'$SAGE_LOCAL/lib/LiE' src/lie rm -rf $SAGE_LOCAL/lib/lie # clean up old versions rm -rf $SAGE_LOCAL/bin/lie $SAGE_LOCAL/lib/LiE -mv src/lie -t $SAGE_LOCAL/bin/ -mv src/ -T $SAGE_LOCAL/lib/LiE +mv src/lie $SAGE_LOCAL/bin/ +mv src/ $SAGE_LOCAL/lib/LiE But then it seems to work okay. It probably installs without problems on a linux system. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/ypN6gGHlRFYJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: dual (co)algebras
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.dejavascript: 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 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 ... 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 -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/m8yyBeVLBLsJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: dual (co)algebras
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.) -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/6qBXMyQrZeMJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] The deprecation change
On Wednesday, August 1, 2012 1:35:02 PM UTC-7, Nicolas M. Thiery wrote: All in all, in the future, I *will* put a negative review to similar non essential global changes that impact much of our code (stuff in combinat, ...). Unless the author volunteers to handle all the rebasing work in the Sage-Combinat queue, together with the associated communication. See http://trac.sagemath.org/sage_trac/ticket/13255. There may be other similar tickets by the same author. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/iDH9j3Xenl4J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] The deprecation change
On Wednesday, August 1, 2012 6:05:44 PM UTC-7, Volker Braun wrote: On Wednesday, August 1, 2012 8:47:37 PM UTC-4, John H Palmieri wrote: See http://trac.sagemath.org/sage_trac/ticket/13255. There may be other similar tickets by the same author. At least that ticket only touches stuff in sage/misc and only replaces them by equivalent python 3. So it shouldn't conflict with the combinat queue at all. Well, according to grep, 39 patches in the combinat queue touch files in sage/misc. I didn't test if any of them conflicted with the patch at #13255. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/fGXB14ydfOcJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] doctest failures
On Thursday, July 19, 2012 2:45:09 PM UTC-7, Martin wrote: Anne Schilling writes: Here are several *ideas*: * We should run daily tests on the needs review section and pop patches off that section if the tests do not pass (or people are not actively working on making them pass). * Everyone should try to get their patches into main-sage in a reasonable time frame or remove their patches from the queue if they are outdated. * Perhaps we should have a second queue for only the patches currently actively developed and in the review or final development process. This queue would only be maintained on the very last version of sage and patches are removed once the next version of sage comes out. This would take the extra constraints off developers to, at the same time, make their patch apply cleanly on a given version of sage and juggle the tail of sage-combinat patches that lie on top of it. This caused quite some frustration to both Franco and Mike and myself last week trying to work on some large patches. Although I am now relieved that I didn't break anything, let me add one other idea: in the unittesting package for fricas, two things turned out to be very useful: 1) being able to mark tests as expected to fail You can mark a doctest as sage: 2+2 # known bug 5 Then it won't get run ordinarily, but you can do sage -t -only-optional=bug FILE.py to run doctests marked this way. It doesn't quite do what you want, since the number of skipped tests is not reported. But maybe that could be added on to the new doctesting framework being developed at http://trac.sagemath.org/sage_trac/ticket/12415. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/43dodjTRo2wJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Warning: a few trac tickets touching many files, leading to possible conflicts with the queue
For people working with the combinat queue: - Trac ticket #13255 [1] touches many files, all in the directory devel/sage/sage/misc. - Trac ticket #6495 [2] touches many files, all in devel/sage/doc/, including practically all of the files in devel/sage/doc/en/reference. These patches are still marked as Needs review, so if your combinat patch also touches files in these directories, you might want to work with the authors of these tickets to try to avoid future conflicts. Also, ticket #13245 turns off docbuilding while doing the clone when installing the combinat queue, so if you want to review that, you will help to speed up the process of installing the queue. Cheers, John [1] http://trac.sagemath.org/sage_trac/ticket/13255 [2] http://trac.sagemath.org/sage_trac/ticket/6495 [3] http://trac.sagemath.org/sage_trac/ticket/13245 -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/s-wElRyadycJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] problems with some files in the queue
In the combinat queue, some files contain non-ascii characters. Several participants at Sage-Combinat Days 40 have run into problems with this: when there are non-ascii characters, if you clone the combinat queue, you get errors when building Sage and its documentation. - trac_11305-rigged_configurations-ts.patch: line 1064 (in 187–201) contains a character which looks like a hyphen, but is not, so it needs to be replaced. - trac_11929_8899-ncsf-qsym-fs.patch: line 77 has a similar problem (218–348). - separatrix_diagram-vd.patch: line 2179 looks something like this: +`vef = 1` and the action of the group generated by `v,e,f` acts transitvely but there are two characters of gibberish before `v,e,f`. They should be deleted. - trac_12518-enumerated_set_from_iterator-vd.patch: line 476 has a character (immediately after the #) which looks like a space but isn't. Maybe Franco has fixed this already, but please check. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/80c6qBpn3vIJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Deprecations
Dear Sage developers: Because of Volker's work on the patch at Trac #13109, the syntax for deprecations has changed. He fixed all of the discrepancies in the Sage library, and we just did similar fixes on (I think) all tickets with positive reviews. So if you have a ticket at some other stage which uses deprecations, please rebase your work to use the new syntax at #13109. Thanks, John http://trac.sagemath.org/sage_trac/ticket/13109 -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/eH3qCfnteSMJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: doctesting nonsage modules
On Sunday, April 8, 2012 8:44:47 PM UTC-7, Mark Shimozono wrote: Suppose I make a new file that looks like a sage module, replete with doctesting strings. If I run sage -t on it, the functions defined in the new file are not loaded and errors occur. What version of Sage is this? The patch in http://trac.sagemath.org/sage_trac/ticket/12069 was merged in Sage 5.0.beta11, and should fix this problem. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/amoC_9wQsO0J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: problems with HasseDiagram and rank
On Friday, January 13, 2012 2:07:00 PM UTC-8, Raymond N. Greenwell wrote: Hello! I posted this on sage-support, but I should have posted it here. I tried using the HasseDiagram and rank features of Sage as described on http://www.sagemath.org/doc/reference/sage/combinat/posets/hasse_diagram.html Things worked ok, but when I then tried: m= Matrix([[0,1,1],[0,0,1],[0,0,0]]) g = DiGraph(m) h2 = HasseDiagram(g) h2.rank(2) Look at the documentation for HasseDiagram. It says: This should not be called directly, use Poset instead; all type checking happens there. So: sage: m = Matrix([[0,1,1],[0,0,1],[0,0,0]]) sage: g = DiGraph(m) sage: p2 = Poset(g) Then sage: p2.rank(2) 2 Also, sage: p2.cover_relations() sage: show(p2) both look right. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/OUPHsmBJjm8J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: dot2tex, combinat
On Friday, December 23, 2011 4:54:53 PM UTC-8, Travis Scrimshaw wrote: I copied the latest version of TikZ / PGF (using a shared folder) to the VM and installed it. I was able to compile the .tex file using the VM's latex compiler and view the output .pdf from my host OS (Windows Vista) in the shared folder, but I could not get it to display in the notebook. Did you try my suggestion about using jsmath_avoid_list? -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/YVSFZP9ZF2UJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: dot2tex, combinat
On Tuesday, December 20, 2011 12:48:00 AM UTC-8, Nicolas M. Thiery wrote:
On Tue, Dec 20, 2011 at 12:55:11AM +, Sagan, Bruce wrote:
Formidable! This installed dot2tex. Thanks so much!! One last
question. When I went back to the notebook and ran a view command (I just
copied the first example of using this command from the section Crystals of
Tableaux in Sage of the Classic Crystals thematic tutorial) I got as output
the tex commands for the tikz picture of the crystal. Is there a way to
get the picture itself printed in the notebook without having to create a
latex file? Maybe I have to install another package?
Alas, the notebook (or more precisely the component jsmath/mathjax
which is the same used on e.g. mathscinet) isn't yet able to display
all latex construct, and in particular tikz pictures.
Instead, you can view it in an external pdf viewer:
sage: view(B, pdflatex=True, tightpage=True)
You could also use the jsmath avoid list: a list of strings which tells
the notebook to use straight latex, rather than JSMath, to process them:
sage: latex.add_to_jsmath_avoid_list('tikz')
tells Sage to not try to use JSMath on any string which includes 'tikz'.
This is documented in sage/misc/latex.py. You can do this to try an
example:
sage: from sage.misc.latex import latex_examples
sage: G = latex_examples.graph()
sage: G
(prints an informative message about what you can do with G)
I would hope that something similar would work with dot2tex, but I haven't
actually tried it.
--
John
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/vwiFON0ku2kJ.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] (free) algebras
On Tuesday, March 22, 2011 1:34:44 AM UTC-7, Nicolas M. Thiéry wrote:
Is it already possible or would it be easy to implement a quotient
of the free algebra by specifying relations between the generators?
Unless Singular can provide something (but I guess that would be more
for skew-commutative algebras; Simon: can you confirm?), the proper
way to do this would be to use gap's KBMAG package. It should be
fairly straightforward, but not instantaneous either.
I don't know anything about KBMAG; I should look into that. Meanwhile,
Singular does let you define certain quotients of free algebras. See
http://www.singular.uni-kl.de/Manual/3-1-0/sing_404.htm. In Sage, I can
define a GF(2)-algebra S to be the free algebra on x and y subject to the
relation [x,y] = y^2:
sage: singular.LIB('ncall.lib')
sage: R=singular.ring(2,'(x,y)')
sage: C = singular.matrix(2, 2, '(1,1,1,1)')
sage: D = singular.matrix(2, 2, '(0, y*y, 0, 0)')
sage: S = C.nc_algebra(D)
sage: S.set_ring()
sage: x = singular('x')
sage: y = singular('y')
sage: x*y
x*y
sage: y*x
x*y+y^2
There are limitations on the sorts of algebras which can be defined this way
-- I think they need to have a PBW basis, basically -- see
http://www.singular.uni-kl.de/Manual/3-1-0/sing_420.htm#SEC461 -- but
Singular does give you some quotients of free algebras.
--
John
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: bug in latex for CombinatorialFreeModule in elements in the root lattice
On Friday, February 25, 2011 1:28:06 PM UTC-8, Christian Stump wrote: Is it okay if I open a ticket on that and provide a fix? Yes, please fix CombinatorialFreeModule! Is there a way to provide a latex prefix in addition to the prefix for CombinatorialFreeModule in order to get the alpha shown as an \alpha? Should I add this functionality as well? here is the patch: http://trac.sagemath.org/sage_trac/ticket/10852 Could you please reconcile this with the patch at #9370? That implemented a latex prefix and various other things. (If you felt like refereeing #9370 at the same time, that would be helpful, too.) -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Implementing a ring using CombinatorialFreeModule
On Sep 27, 5:41 am, Christian Stump christian.st...@gmail.com wrote: Salut, as you are just talking about the CombinatorialFreeModule: my problem is that the CFM imports everything from rings, as you can create a CFM over any ring. Now, I use the CFM to implement the universal cyclotomic field, which I import in rings, as it is one. Thus, I get problems with an import loop. Any suggestions? I think that many of the import statements in free_module.py should be inside the methods that use them, rather than at the top level. Here's a patch which moves some of them: http://sage.math.washington.edu/home/palmieri/misc/cfm.patch I think this should make it work. I tested this by adding a line from sage.categories.examples.algebras_with_basis import Example to sage.rings.all, and Sage started without problems. (I may also have had to fix some imports in examples/algebras_with_basis.py.) -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Implementing a ring using CombinatorialFreeModule
On Sep 27, 12:02 pm, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi John, Christian, On Mon, Sep 27, 2010 at 08:20:26AM -0700, John H Palmieri wrote: I think that many of the import statements in free_module.py should be inside the methods that use them, rather than at the top level. Here's a patch which moves some of them: http://sage.math.washington.edu/home/palmieri/misc/cfm.patch Sounds good to me in general. Thanks for working on that! Just a comment: I would tend to leave the import of ``Integer`` at the top level, since it's used in at least one time critical spot. Only, I would import it from sage.rings.integer instead of sage.rings.all. I guess I don't know what the speed issues are here. Why should including it at the top-level be better than when it is actually used? In practice during a Sage session, Integer will already be imported, right? While you are at it: the first occurrence of Integer (in R(Integer(1))) would be best rewritten in R.one(). In principle, that should be supported by all Sage rings. I think this should make it work. I tested this by adding a line from sage.categories.examples.algebras_with_basis import Example to sage.rings.all, and Sage started without problems. (I may also have had to fix some imports in examples/algebras_with_basis.py.) Just a side note: (except for testing purposes like above), things in categories/examples are not supposed to be imported into Sage by default, or at least only very late in the process. So I would leave the imports there as simple as possible. Right, I wasn't suggesting doing that for real. I was just using it as something defined in terms of CombinatorialFreeModule which I could import (temporarily) in rings to trouble-shoot the circular imports. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: CombinatorialFreeModule (again)
On Sep 2, 3:33 am, Bruce brucewestb...@gmail.com wrote: I am trying to construct the free module on the set of instances of a class G. Did you also ask this on ask.sagemath.org? I've posted some possibly related ideas in the thread http://ask.sagemath.org/question/94/using- combinatorialfreemodule. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] CombinatorialFreeModule and UniqueRepresentation
I find the following a little strange. I know why it happens, but anyway: sage: F = CombinatorialFreeModule(QQ, [1,2,3,4], prefix='F') sage: F._prefix = 'x' sage: G = CombinatorialFreeModule(QQ, [1,2,3,4], prefix='F') sage: G.prefix() 'x' Would it be possible, and would it make sense, to do the following instead: - every module M over a given base ring with a given basis is unique (also including the element_class and category, but not including the prefix). This would be its own class, UniqueCombinatorialFreeModule or something. I think of this as the immutable part of the structure. - then specifying a prefix makes it no longer unique: a CombinatorialFreeModule would essentially be a pair (M as above, prefix). Modifying the prefix would not affect other instances: it wouldn't affect M. The prefix would be mutable. One way to do this would be for the __init__ method for CombinatorialFreeModule to be something like this: self._module = UniqueCombinatorialFreeModule(...) self._prefix = ... # other mutable parts of the structure here Then a lot of things in free_module.py would have to be rewritten to use self._module. How feasible is this? -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] customizing printing of CombinatorialFreeModuleElements
I personally don't like the use of an asterisk * for scalar multiplication in printed output -- I like a space, or sometimes nothing at all -- so I've put a patch at http://trac.sagemath.org/sage_trac/ticket/9370 which allows for customization of printing of CombinatorialFreeModuleElements. It's maybe a first draft; please provide feedback. As far as I can tell, it's backwards compatible, but it should allow for more flexibility in the future. (I don't know how well putting sage-combinat in the cc field works, so I'm posting here as well.) -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: an example of a graded algebra with basis
On Jun 24, 12:23 am, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: On Wed, Jun 23, 2010 at 11:06:40PM -0700, John H Palmieri wrote: If the grading is over NN/ZZ, or some naturally ordered monoid, I would definitely argue for keeping degree for all elements. That's not how I think of elements of a Z-graded algebra: in my experience, if they're not homogeneous, then they don't have a degree. It should probably be left as a case-by-case situation. Well, certainly not case by case, since for most of our graded algebras (and we will have lots of them) we definitely want to have a degree function for all elements. But maybe that should be just in a subcategory (most of our algebras are actually graded connected over NN). What makes you dislike having degree implemented for all elements? - That it could be accidently used on non homogeneous elements by the caller, when not meant to, without an error raised? Yes, or that mathematically, at least some people would view degree as being undefined except on homogeneous elements, and I would want Sage to reflect that. If someone tells me that an element of a graded algebra has degree d, then I expect it to be homogeneous: I expect it to give a well-defined action, raising degree by d, on any graded module over that graded algebra. If someone says that they have a degree d polynomial, then I understand that this just means that the leading term is homogeneous of degree d, but if they say they have a degree d element in the polynomial ring k[x,y,z] graded by ..., then I interpret this to be a homogeneous element. (By if they say, I really mean, if I read this in a paper dealing with graded algebras. For example, if X is a topological space and H^*(X) is its cohomology, then if someone talks about a degree d element of H^*(X), they are almost guaranteed, in my experience, to mean a *homogeneous* element of degree d of H^*(X).) I'm leaving my example as is: non-homogeneous elements don't have a well-defined degree. But I'm also including a comment about this choice in the docstring. - That the specs might be ill-defined for non homogeneous elements (e.g. if the order is not total)? - That there is a faster way to do it for homogeneous elements (assuming we don't check for homogeneity)? Because without forcing the list, the TestSuite fails. Ah ok. Then that's just a bug that should be investigated and fixed. Let me know when you have an updated patch on trac, and I'll have a look. It's posted now: http://trac.sagemath.org/sage_trac/ticket/9280 It's great that we are having all those discussions. Once the example will be finalized, we will have a sound basis to build upon. That's what I'm hoping. Thanks to everyone for all of your comments and suggestions. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: an example of a graded algebra with basis
On Jun 22, 2:53 pm, Franco Saliola sali...@gmail.com wrote: Hello John, On Sat, Jun 19, 2010 at 11:45 PM, John H Palmieri jhpalmier...@gmail.com wrote: I have a simple example of a graded algebra with basis. Please take a look at http://trac.sagemath.org/sage_trac/ticket/9280 I have some comments on the interface for GradedAlgebraWithBasis. 1. Your choice of using ``A[n]`` to return the degree `n` piece of `A` is not consistent with other graded algebras in Sage. And given the lack of formal development of graded objects in Sage, maybe now is the time to settle on a convention. For example: sage: sf = SymmetricFunctions(QQ) sage: s = sf.schur() sage: s[3] s[3] This returns an element of the algebra, and not the degree 3 homogoneous component. I wrote graded because the algebra is indeed graded, but Sage does not currently know about the grading. Personally, I strongly prefer the idea of using __getitem__ to access elements of the algebra, by passing data to construct an element of the indexing set. I really don't like to write sage: s.basis()(Partition([3])) to construct an element of the algebra. Instead, I suggest a method called homogeneous_component(n) that returns the degree n component. (This should be generic and pushed up to every GradedAlgebraWithBasis, and so you don't need to define it in your case. It would also have the benefit of showing up in tab completion.) I would instead use _element_constructor_ to construct elements of the algebra, so you would call A(data) instead of A[data]. This is consistent with the coercion framework: you should use A(...) to construct elements of A. In mathematical notation, if I have a graded object M, then I would write M_n or M^n to get the graded pieces, so in Sage, M[n] seems like a reasonable approximation. If list[n] gives me the nth term of the list, it feels natural that M[n] should give me the nth homogeneous piece of a graded object. I happen to think that M[n] returning the nth homogeneous piece feels more natural than M[n] returning an element of M. In the case of an integer grading, there is also the possibility of implementing M[m:n] to return the sum of several graded pieces, or M[1:] or M[1:Infinity] to return the positively graded part. This notation just feels right to me. Does anyone else have an opinion? As far as tab completion goes, if we use __getitem__, then M.homogeneous_component(n) should be a synonym for M.__getitem__(n), and both usages should be discussed in the docstring. (By the way, if you want A[n] to return a element of the algebra, note that this construction doesn't show up in tab completion either.) 2. I wonder if your method basis_in_degree should be merged with basis: if no argument is specified, then default to the current behaviour (return a basis of the algebra); otherwise, return a basis of the degree n component. That seems like a good idea, although the printing of bases when they're produced from infinite lazy families is perhaps less than ideal. We're overriding the basis method for a CombinatorialFreeModule, but I guess with no arguments it should return the old value, so it shouldn't break anything. 3. Right now, you are starting with a DisjointUnionEnumeratedSets constructed from a family: DisjointUnionEnumeratedSets(Family(NN, self._basis_fcn)) This choice was based on some discussions over the past few months in sage-algebra and sage-combinat-devel. I tried changing this to Family(NN, self._basis_fcn) and got some weird doctest errors about pickling, causing the TestSuite to fail. So while what you say makes sense, it causes problems for me. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: an example of a graded algebra with basis
On Jun 22, 3:36 am, Andrew Mathas a.mat...@usyd.edu.au wrote:
Hi John,
I am currently writing some code to compute in some graded module --
there is a graded algebra lurking in the background for which I have
generators and relations but it is highly non-trivial to describe how
the algebra acts on its homogeneous basis and to rewrite the
generators in terms of this basis so I am not really interested in
coding up the algebra just yet. Still, I'd be happy to work with you
on this.
Great!
I had a look through your code and it looks good. Some comments:
o you seem to have a positive grading built in, but a Z-grading is
more natural in many ways.
In general I agree with you, but for a polynomial algebra, if you have
one generator in a positive degree and another in a negative degree,
then some of the graded pieces will be infinite-dimensional, and that
seems awkward, if nothing else.
Some people will be interested in grading by arbitrary groups or
even monoids so some flexibility should be allowed here.
Right. In principle, where I have a line like
Family(NN, self._basis_fcn)
you could put
Family(M, self._basis_fcn)
where M is any (commutative?) monoid. In practice, it may not work so
well yet -- I tried using cartesian_product((NN, NN)) and it didn't
work -- but I think things are progressing.
To capture the greatest
generality the degree function
probably should be allowed to be a morphism, or even just a
method on the indexing set
for the basis/generating set? (The latter is what I am doing.)
Sounds good to me. (Remember, in my patch I'm trying to implement an
example, not the general case. But we could add comments about this
sort of thing to my example.)
o Is it necessary to code up _latex_ for the elements? I thought
that this should be inherited from
AlgebrasWithBasis?
My basis is given by tuples of integers, and their latex method
doesn't produce anything resembling monomials: the default method
would give something like B[(2,0,3)]. I could have made a separate
class of monomials first, then used them as basis elements, but I
chose to use tuples as the raw data.
o the only generic function that I have added apart from degree() is
a homogeneous_components()
function. What I have currently is the following method:
def homogeneous_components(self):
r Returns a dictionary of the homogeneous components.
EXAMPLES::
sage: G=GradedSpechtModule(3,[3,2])
Graded Specht module S(3,2) with e=3.
sage: a=G.an_element()
sage: a.homogeneous_components()
{0: 2*[125/34] + 3*[134/25], 1: [135/24]}
hom={}
for (tab,coeff) in self:
d=tab.degree(self.parent().e)
if d in hom: hom[d]+=self.parent().term(tab,coeff)
else: hom[d]=self.parent().term(tab,coeff)
return hom
I just threw this in playing around am not sure that it will
be useful in practice.
Seems like it might be useful.
In my current implementation -- which is still very much a template --
I am hacking CombinatorialFreeModule. My degree function is actually a
method on tableaux, so it is not defined explicitly. Having seen your
code it's clear that I really ought to implement a
GradedCombinatorialFreeModule/GradedModuleWithBasis class.
I think something like that is probably needed, but I didn't have the
time to think about all of the details behind implementing it. It was
easier for me to write a simple example using what's already present
in Sage. (Actually, first I've been working on rewriting the Steenrod
algebra code in Sage using the new category framework, and I wanted to
make it into a graded algebra. From what I've learned doing that, I
produced the example, in the hope that it's helpful to other people.)
One issue I've had: if I define the nth graded piece (using
__getitem__, for example) as a CombinatorialFreeModule on a subset of
the basis, then I couldn't figure out how to easily multiply elements
of that: it's just a free module, with no _mul_ or product method
defined. It's easy to set up coercion so that multiplying an element
of a graded piece with an element of the whole algebra is defined, but
not so easy when multiplying an element of one piece with an element
of another. Part of the structure of GradedCombinatorialFreeModule
should allow this, so that you can work with the pieces, then
reassemble them using sums, products, etc.
One idea is that we could try and develop the GradedAlgebraWithBasis
and GradedModuleWithBasis in parallel. That way we can fine tune what
we're both doing and hopefully arrive at a good design... I'm likely
to be overloaded for the next few weeks, but can probably do something
after this.
Sounds okay. I hope some other people chime in with ideas as well.
John
Andrew
On Jun 20, 5:45 am, John H Palmieri jhpalmier...@gmail.com wrote:
I have a simple example of a graded algebra
[sage-combinat-devel] Re: Graded algebras (a third time)
On Jun 4, 3:21 pm, John H Palmieri jhpalmier...@gmail.com wrote: On Jun 4, 2:51 pm, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi John, Hi Nicolas, On Wed, Jun 02, 2010 at 10:48:00AM -0700, John H Palmieri wrote: How about this for a starting point for an implementation of graded algebras: sage: A = Family(NonNegativeIntegers(), lambda d: CombinatorialFreeModule(GF(2), steenrod_algebra_basis(d), prefix=), lazy=True) Is there something preventing to do doing something like: CombinatorialFreeModule(GF(2), DisjointEnumeratedSet(NonNegativeIntegers, steenrod_algebra_basis)) If I do CombinatorialFreeModule(GF(2), DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(), steenrod_algebra_basis))) it's okay but not perfect. (Maybe it's better if I use keepkey=True as well.) (Also, I can't seem to make it work without using Family -- I get an assertion error -- but I haven't tried that hard.) However, with this setup, I don't know how to get the basis in degree n, for instance, or the entire degree n piece of the algebra. I really need to be able to extract this information. Any ideas how? I could separately write a method which just returns CombinatorialFreeModule(GF(2), steenrod_algebra_basis(n)) but I want to have a structure where I can extract this from the original construction. If I define the whole thing as a family (or if I store the family as an attribute and write a suitable __getitem__ method), then I can do A[n] to get the degree n part, so for example A[n].basis() is what I want. For the Steenrod algebra, it is pretty rare to deal with nonhomogeneous elements, so having the homogeneous parts as easily extractable pieces is a natural way to think about things. One more thing: I can't figure out how to modify CombinatorialFreeModule(GF(2), DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(), steenrod_algebra_basis))) to define a bigraded algebra. For example, sage: NN = NonNegativeIntegers() sage: N2 = CartesianProduct(NN, NN) sage: def f(s,t): return tuple(range(s+t)) # tuple so hashable ... sage: CombinatorialFreeModule(GF(2), DisjointUnionEnumeratedSets(Family(N2, lambda a: f(a[0], a[1] gives me an error NotImplementedError: infinite list. Indeed, while sage: Family(N2, lambda a: f(a[0], a[1])) works, this doesn't: sage: DisjointUnionEnumeratedSets(Family(N2, lambda a: f(a[0], a[1]))) Nesting families (as below) partially works, but I'm having various problems with it... sage: DisjointUnionEnumeratedSets(Family(NN, lambda s: Family(NN, lambda t: f(s,t -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] bug with DisjointUnionEnumeratedSet?
(also posted to sage-devel) One of the examples in the docstring for DisjointUnionEnumeratedSet goes something like this: sage: U = DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(), Permutations)) sage: it = iter(U) sage: it.next() [] If I try the same thing, replacing Permutations with Partitions, it doesn't work: sage: U = DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(), Partitions)) sage: it = iter(U) sage: it.next() --- ValueError Traceback (most recent call last) /Users/palmieri/ipython console in module() /Applications/sage/local/lib/python2.6/site-packages/sage/sets/ disjoint_union_enumerated_sets.pyc in __iter__(self) 398 399 for k in self._family.keys(): -- 400 for el in self._family[k]: 401 if self._keepkey: 402 el = (k, el) /Applications/sage/local/lib/python2.6/site-packages/sage/sets/ family.pyc in __getitem__(self, i) 939 10 940 -- 941 return self.function(i) 942 943 def __getstate__(self): /Applications/sage/local/lib/python2.6/site-packages/sage/combinat/ combinat.pyc in __call__(self, x) 1013 return self._element_constructor_(x) 1014 else: - 1015 raise ValueError, %s not in %s%(x, self) 1016 1017 Element = CombinatorialObject # mostly for backward compatibility ValueError: 0 not in Partitions Is this expected? -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: [sage-algebra] AlgebraWithBasis, GradedAlgebraWithBasis (again)
On May 25, 12:46 am, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi John! Again, I'll stick to a very short answer for the moment. Prompted by your questions, I now have a clearer idea of what sort of wizard-like document is needed by the developers when choosing the implementation for a parent. I'll try to work on it this week, and keep you updated when I'll have some draft. Great! On Mon, May 24, 2010 at 09:46:54PM -0700, John H Palmieri wrote: Some questions about defining an AlgebraWithBasis or a GradedAlgebraWithBasis: - Do these need to be defined using CombinatorialFreeModule, as in the example? Not at all. CombinatorialFreeModule just provides you with a data structure (mostly for the elements, and a bit for the parent). But you can use your own data structure. If I use another data structure, are there methods that I should make sure to implement for it to be a well-implemented (Graded)AlgebraWithBasis? - If so, in all of the examples I've seen, CombinatorialFreeModule needs a basis with an explicit indexing set. Yes. That's actually a prerequisite of AlgebrasWithBasis. Ok, the definition of AlgebrasWithBasis should be rewritten as: The category of algebras with a distinguished basis on which the elements are represented by their expansion. When I say an explicit indexing set, I mean explicit from the point of view of Sage. I can give you a mathematically explicit indexing set -- ordered partitions satisfying certain explicit conditions -- but I can't give it as a list or tuple or anything else simple that already exists in Sage. This morning I thought of the possibility of implementing a subclass of Partitions and then using that for my indexing set; is that feasible? Maybe that's the right choice. I don't know an explicit indexing set in the case I'm interested in; When I said this, I meant that I don't know, for example, a closed- form expression for the dimension of the algebra in bidegree (s,t). But as I said above, I can write down a mathematically explicit expression for an indexing set for the basis. rather, I can define a function which produces the basis. (It's graded, so I can give a recursive function which defines the basis in degree d in terms of the bases in lower degrees.) So what can I do? Is it possible and is it a good idea to specify a spanning set instead (as the basis in CombinatorialFreeModule) -- I can just use words in the generators -- and then later on specify a linearly independent subset? Sounds like you probably just want to use the GradedAlgebras(QQ) category. And as of now, the categories won't give you that much, except for TestSuite, and not having to be refactored at some later point. On the other hand, it also sounds like your algebra is defined as a subalgebra of a larger ambient algebra. Well, it's actually a quotient of a free algebra, which by itself tells you absolutely nothing, since every algebra is such a quotient. But I have explicit generators and relations, and there is a distinguished collection of words (admissible words) in the generators which projects to a basis of the quotient algebra, and there is a clear procedure for rewriting any word in the generators as a sum of basis elements. -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] question about Partitions, Compositions, IntegerListsLex
I would like to construct the set of ordered partitions of a positive
integer n subject to a condition like this:
- if the partition is (l_1, l_2, ...), then I want to specify a
variant of slope: I want to specify integers a and b, or lists of
integers (a_1, a_2, ...) and (b_1, b_2, ...) and then I want to
replace the slope condition
max_slope = l_i - l_{i+1} = min_slope
with
max_slope = a_i * l_i - b_i * l_{i+1} = min_slope
For example, I want to be able to produce the ordered partitions (l_1,
l_2, ..., l_k) of n, with length k, such that
2l_i = l_{i+1}
for all i.
Can someone help me to alter IntegerListsLex (I think this is the
right class) so that it allows for this functionality? The code in
combinat/integer_list.py looks a little complicated, and I'm hoping
someone can provide a quick answer.
Thanks,
John
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] AlgebraWithBasis, GradedAlgebraWithBasis (again)
Some questions about defining an AlgebraWithBasis or a GradedAlgebraWithBasis: - Do these need to be defined using CombinatorialFreeModule, as in the example? - If so, in all of the examples I've seen, CombinatorialFreeModule needs a basis with an explicit indexing set. I don't know an explicit indexing set in the case I'm interested in; rather, I can define a function which produces the basis. (It's graded, so I can give a recursive function which defines the basis in degree d in terms of the bases in lower degrees.) So what can I do? Is it possible and is it a good idea to specify a spanning set instead (as the basis in CombinatorialFreeModule) -- I can just use words in the generators -- and then later on specify a linearly independent subset? - If I don't need to use CombinatorialFreeModule, what other choices do I have? Thanks, John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: categories, etc.: how to define a new algebra
On May 19, 3:55 pm, Nicolas M. Thiery nicolas.thi...@u-psud.fr
wrote:
Hi John!
On Wed, May 19, 2010 at 03:40:44PM -0700, John H Palmieri wrote:
On May 19, 3:02 pm, Nicolas M. Thiery nicolas.thi...@u-psud.fr
wrote:
On Wed, May 19, 2010 at 02:25:22PM -0700, John Palmieri wrote:
- Should I do anything with the new categories framework? I've
defined a category method for the algebra, but should I do anything
else?
- I'm working on a differential graded algebra, in fact. It is a
graded algebra with basis (and it's actually Z x Z graded, so a
bigraded algebra with basis); do I need to do anything special about
this? I've defined a basis method already which returns the basis
in each bidegree as a Python list.
As a short first answer, please try:
sage: A = AlgebrasWithBasis(QQ).example()
Yes, I saw that. It looks like I should try to define my algebra
(call it L) as a CombinatorialFreeModule and implement at least
one_basis, product_on_basis, and algebra_generators. Unfortunately,
there is no corresponding example for GradedAlgebrasWithBasis, and the
framework for graded objects doesn't seem very complete. So should I
specify the basis for the CombinatorialFreeModule using some family,
and then attach some sort of grading to the basis elements to induce a
grading on L? That seems awkward -- it is important, at least for
this example, to be able to easily extract the basis in any given
(bi)degree, so it seems better to define a function specifying the
basis in each degree. What do you think?
If that's right, then I don't see how to conveniently construct L as a
CombinatorialFreeModule; rather, it is an infinite direct sum of
(finite-dimensional) such objects, and I need to be able to consider
each piece as well as the whole.
Yes, real support for graded enumerated sets / algebras is still to
come. Now I really need to jump to bed; in the mean time, you may want
to have a look at DisjointUnionEnumeratedSets!
I'm sorry, but I can't see how to use this. I'm stuck with the whole
thing, in fact. (I'm not stuck with a Sage implementation, but I am
stuck with an implementation using the new categories framework.)
Let me provide some details: my algebra L is a bigraded algebra over
GF(p) (there is one algebra L for each prime p). I don't know a
simple way to list the basis elements; instead, if I want a basis in a
particular bidegree (s,t), I build it recursively using the algebra
generators and the bases in bidegrees (s', t') for various s' s and
t' t. Thus, for example, I don't know offhand the dimension in each
bidegree. As a result, I don't see how to implement this with
families or DisjointUnionEnumeratedSets.
(In case it helps: at the prime 2, the basis in bidegree (s,t) is in
bijection with length s partitions (i_1, i_2, ..., i_s) of t-s that
don't increase too fast: for each j, 2i_j = i_{j+1}. It's similar
but a bit more complicated at odd primes.)
Anyway, if you have more suggestions, I would appreciate it.
--
John
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: [sage-release] Sage 4.4.rc0 released
On Apr 26, 7:58 am, Florent Hivert florent.hiv...@univ-rouen.fr wrote: How is it decided to make a ticket a blocker ? Is it the responsibility of the release manager ? If on Wednesday I had realized that 4.4rc0 was so close to be out, could I have made #8746 a blocker ? (Apologies if my use of past tense in the previous sentence is wrong... Anyway I hope you get what I mean) You can mark anything you like a blocker, but I think the release manager can evaluate the ticket and decide whether to keep it as a blocker for this release, change its priority, or make it a blocker for the next release. The release manager should make some sort of comment on any blocker ticket indicating what's going on (or what isn't) with the ticket for that release and why. Regarding #8746: this appears to be a performance issue, not a bug fix -- without it, Sage still functions but does some things much more slowly. So I personally wouldn't hold up a release just for this. If the patch had been there while I was working on alpha0 or alpha1, no problem, but I would need a really good reason to delay the release once we hit feature freeze. (This particular release also had a time constraint: I have to stop being release manager tomorrow. It takes about 19 hours to build Sage on our Solaris box, t2.math, so thoroughly testing a potential new release adds about a day to the process.) I think in general, if during the release process you decide that a positively-reviewed ticket should have high priority, then it might be best to email the release manager and explain the situation. If this had happened last Wednesday, I would have tried to merge it. (If it had been Friday, probably not -- feature freeze by then.) -- John -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Partitions bug with max_slope?
On Jan 9, 3:58 am, Nicolas M. Thiery nicolas.thi...@u-psud.fr
wrote:
On Sat, Jan 09, 2010 at 10:53:30AM +0100, Vincent Delecroix wrote:
I get the following with sage-4.3, is it normal to have [2, 1] and [1,
2] as partitions ?
{{{
sage: for p in Partitions(3, max_slope=1):
: print p
:
[3]
[2, 1]
[1, 2]
[1, 1, 1]
}}}
Well, that's consistent with max_slope=1. Did you mean max_slope=-1?
Of course, it would have been nicer to get an error (since the highest
meaningful max_slope for a partition is 0). Hopefully we will be able
to do that when the IntegerListsLex kernel will be rewritten
(volunteers for that welcome!).
While we're on this topic, here's a bug which I don't know if anyone
has worked on recently: compare
sage: Partitions(4, max_slope=-1).list()
[[4], [3, 1]]
to
sage: Partitions(4, max_slope=-1, length=3).list() # doesn't work
[[2, 1, 1]]
See http://trac.sagemath.org/sage_trac/ticket/6538.
--
John
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
