Re: [sage-combinat-devel] Sage Days 65 mini report
On Saturday, June 13, 2015 at 2:05:54 PM UTC-4, Volker Braun wrote: On Saturday, June 13, 2015 at 1:27:30 AM UTC+2, William wrote: I'm also curious if anybody has any -- possibly *radical* -- suggestions about how to address this problem using new ideas. Use Docker (or boot2docker on OSX and Windows) to build and run Sage. Pro: Instant windows port. Boot2docker bundles VirtualBox. Kitematic installs boot2docker as part of its install, we could just copy that. Gives us a reproducable build environment with a guaranteed working toolchain. Con: Requires 64-bit and VT-x. Some Windows boxes still ship with VT-x disabled in the bios. A bit less efficient than native. I just tried this out on a 2011 imac and it worked very well. It was all very smooth. This is for the 6.7 release. How difficult would it be to automatically create a docker image for each development version? To do actual development, one would also want git, the git-trac command, a way to launch a terminal in the virtual machine (in general, a way to edit files). Can you update the README.md with hints on how to go about doing this? https://github.com/sagemath/docker Franco -- 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.
Re: [sage-combinat-devel] Sage Days 65 mini report
On Fri, Jun 12, 2015 at 10:03 PM, Franco Saliola sali...@gmail.com wrote: On Friday, June 12, 2015 at 6:27:28 PM UTC-5, William Stein wrote: On Fri, Jun 12, 2015 at 1:28 PM, Franco Saliola sali...@gmail.com wrote: Here is a mini report on Sage Day 65. I'm not an organizer so this is not official. Thanks to Anne Schilling for helping to prepare this. - 24 tickets on trac are tagged with `sagedays65` or `sd65`. Some of these have been positively reviewed and marked as fixed. Some are waiting for review (hint, hint). Several of these tickets include contributions from new users. - Installation troubles: - several people had a hard difficult time installing Sage on their machines (8-10 people) - there were people who did not have a working development version on their machines by the end of the week (4-5 people); two of these people were the organizers of the Sage Days This is a bummer. It gives me even more motivation to make SageMathCloud Sage-developer friendly.I'm also curious if anybody has any -- possibly *radical* -- suggestions about how to address this problem using new ideas. Most of these problems were related to installing on Macs: various different OS versions (10.10, 10.9, 10.8, ...); XCode versions; command line tools out of date; Perhaps an enhanced build test system might help. Some ideas (mostly questions): (1) Would it be possible to maintain a list of known compilation errors? The build process could check online if the error message matches one of the known issues and then return links to a page with information (possible workarounds, appropriate trac tickets)? Another idea along these lines. When a build fails, there is a message that suggests a user send an email to sage-devel. From my experience, *many* people don't do this. At Sage Days, they ask a neighbour. At home, they'll ask a Sage person the next time they run into them, or they send an email to a Sage friend, But information about these build failures could be useful. So maybe when a build fails, there can be a message that says something like: Would you like to send an error report to the Sage development team? This will include information about your operating system and the log files of the build process. [Y/n]. Franco -- 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.
Re: [sage-combinat-devel] Sage Days 65 mini report
On Sat, Jun 13, 2015 at 3:23 AM, Volker Braun vbraun.n...@gmail.com wrote: On Saturday, June 13, 2015 at 5:03:02 AM UTC+2, Franco Saliola wrote: Most of these problems were related to installing on Macs: various different OS versions (10.10, 10.9, 10.8, ...); XCode versions Apple does not support OSX 10.10, so I don't see how we could (or should). Sometimes there are obstacles that prevent for people from upgrading to 10.10 for a few months. Here is an example from a Sage Days participant: their university VPN doesn't (yet) work on 10.10, so he has been holding off an upgrading. As a result, he can't do any Sage development cause Sage doesn't compile on 10.9. I think this problem on holding off on upgrading until a certain software is compatible with the new OS is very common. I'm not advocating that we support older versions (nor am I against this). But I don't think we should base our decision on what Apple does. (3) A computer scientist who participated in part of the Sage Days said that perhaps using Travis CI The travis-ci build environment is the same docker image everywhere (on each OS). You can not test a large variety of OS'es that way. Thanks! As I said, I don't know anything about travis-ci, so this answer helped me understand things a bit better. Franco -- 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] Sage Days 65 mini report
Here is a mini report on Sage Day 65. I'm not an organizer so this is not official. Thanks to Anne Schilling for helping to prepare this. - 24 tickets on trac are tagged with `sagedays65` or `sd65`. Some of these have been positively reviewed and marked as fixed. Some are waiting for review (hint, hint). Several of these tickets include contributions from new users. - Installation troubles: - several people had a hard difficult time installing Sage on their machines (8-10 people) - there were people who did not have a working development version on their machines by the end of the week (4-5 people); two of these people were the organizers of the Sage Days - number of participants: 40 - some thing that really helped was the Sage Development Images project - A possible warning to future organizers of Sage Days: We had good internet access, but the university network blocked all ssh connections! This was mainly resolved on the first day, but there were still some issues with pulling/pushing through the `git trac` command. Franco -- 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.
Re: [sage-combinat-devel] Sage Days 65 mini report
On Friday, June 12, 2015 at 6:27:28 PM UTC-5, William Stein wrote: On Fri, Jun 12, 2015 at 1:28 PM, Franco Saliola sali...@gmail.com wrote: Here is a mini report on Sage Day 65. I'm not an organizer so this is not official. Thanks to Anne Schilling for helping to prepare this. - 24 tickets on trac are tagged with `sagedays65` or `sd65`. Some of these have been positively reviewed and marked as fixed. Some are waiting for review (hint, hint). Several of these tickets include contributions from new users. - Installation troubles: - several people had a hard difficult time installing Sage on their machines (8-10 people) - there were people who did not have a working development version on their machines by the end of the week (4-5 people); two of these people were the organizers of the Sage Days This is a bummer. It gives me even more motivation to make SageMathCloud Sage-developer friendly.I'm also curious if anybody has any -- possibly *radical* -- suggestions about how to address this problem using new ideas. Most of these problems were related to installing on Macs: various different OS versions (10.10, 10.9, 10.8, ...); XCode versions; command line tools out of date; Perhaps an enhanced build test system might help. Some ideas (mostly questions): (1) Would it be possible to maintain a list of known compilation errors? The build process could check online if the error message matches one of the known issues and then return links to a page with information (possible workarounds, appropriate trac tickets)? (2) Could we release bundles or dmgs or whatever they are called for the *developer* version for OS X? (3) A computer scientist who participated in part of the Sage Days said that perhaps using Travis CI could help with some of this. I don't know anything about this, but maybe someone with Travis experience could say whether this might help? Franco -- 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] gfun in sage?
Hello everyone, Does Sage currently include any functionality similar to the gfun package in Maple? Here is a description of gfun: Gfun is a Maple package that provides tools for guessing a sequence or a series from its first terms; manipulating rigorously solutions of linear differential or recurrence equations, using the equation as a data-structure. Website with more information: http://perso.ens-lyon.fr/bruno.salvy/software/the-gfun-package/ Thank you! Franco -- -- 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.
Re: [sage-combinat-devel] Functorial constructions progress (hopefuly :-))
Fantastic news, Nicolas! Thanks again for all your hard work on this! Franco -- On Wed, Jun 5, 2013 at 10:59 AM, Anne Schilling a...@math.ucdavis.eduwrote: Hi Nicolas, It is great that you are making progress on these! Cheers, Anne On 6/4/13 8:04 PM, Nicolas M. Thiery wrote: Dear Sage-Combinat devs, Executive summary: - NCSF, QSym and their friends should finally work again with the Sage-Combinat queue applied; sorry it took so long. - The changes are relatively subtle; most test pass with 5.10.rc0 and those patches applied. But please report if you stumble on any abnormal behavior. Longer version: I am making progress on the functorial construction patch (#10963). Most of its dependencies are now positive review, and I have rebased it today on top of #13589: C3 under control and pushed on the Sage-Combinat queue: we should never be bitten again by the dreaded Cannot create a consistent method resolution order (MRO). Finally! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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. -- 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] _repr_ method for Posets
On Thu, Feb 28, 2013 at 9:44 PM, Chris chrisjamesb...@gmail.com wrote:
Hello all!
Right now, the _repr_ method for posets returns a very generic statement:
sage: Posets(4)[0]
Finite poset containing 4 elements
This is consistent with the behaviour with graphs:
sage: Graph()
Graph on 0 vertices
sage: Graph({0:[1,2]})
Graph on 3 vertices
This makes two posets with the same number of elements indistinguishable
from their _repr_.
Sage does not require _repr_ to distinguish between objects.
I would like to change this. Possible suggestion:
Poset on n elements with covering relations ...
Any objections?
I don't have any serious objections to changing this, but perhaps the
question to ask is why you want to change it. There are methods available
that distinguish between posets. One can even change _repr_ on the fly:
sage: g = Graph({0:[1,2]})
sage: g._repr_ = lambda : str(g.edges())
sage: g
[(0, 1, None), (0, 2, None)]
See also g.rename.
Franco
--
--
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] queue broken on 5.7
$ sage -v Sage Version 5.7, Release Date: 2013-02-19 $ sage -combinat update ... applying trac_13605-partition_options-ts.patch patching file sage/combinat/rigged_configurations/rigged_configurations.py Hunk #1 FAILED at 930 1 out of 1 hunks FAILED -- saving rejects to file sage/combinat/rigged_configurations/rigged_configurations.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_13605-partition_options-ts.patch Abort $ hg qpush -a applying trac_14000-doctests.patch applying trac_7886_conjugacy_classes_combined.patch transaction abort! rollback completed cleaning up working directory...done abort: decoding near 'Javier López Peñ': 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)! -- -- 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: queue broken on 5.7
On Mon, Feb 25, 2013 at 9:01 PM, Franco Saliola sali...@gmail.com wrote: $ hg qpush -a applying trac_14000-doctests.patch applying trac_7886_conjugacy_classes_combined.patch transaction abort! rollback completed cleaning up working directory...done abort: decoding near 'Javier López Peñ': 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)! You can get around this error by using `sage -hg` instead (local version of hg is too old, apparently), but there is another patch that fails to apply: $ sage -hg qpush -a ... applying polyhedron-plot-nt.patch patching file sage/geometry/polyhedron/plot.py Hunk #2 FAILED at 51 1 out of 3 hunks FAILED -- saving rejects to file sage/geometry/polyhedron/plot.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh polyhedron-plot-nt.patch -- 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] queue broken on 5.7
Hello Nicolas, Thank you for the quick fix! Take care, Franco -- On Mon, Feb 25, 2013 at 9:58 PM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: On Mon, Feb 25, 2013 at 09:01:52PM -0500, Franco Saliola wrote: $ sage -v Sage Version 5.7, Release Date: 2013-02-19 $ sage -combinat update ... applying trac_13605-partition_options-ts.patch patching file sage/combinat/rigged_configurations/rigged_configurations.py Hunk #1 FAILED at 930 1 out of 1 hunks FAILED -- saving rejects to file ... I fixed my failing patch as well as Travis. The queue is functional again on 5.7. Cheers, Nicolas PS: Travis, I allowed myself to trim out the following trivial hunk out of trac_13605-partition_options-ts.patch -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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. -- 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: queue broken on 5.6 (fixed)
On Thu, Feb 21, 2013 at 4:10 PM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Thanks to Travis, the queue now works again on 5.6! Thanks for all your hard work, Travis. But I'm afraid I have some bad news (followed by good news): sage -v Sage Version 5.6, Release Date: 2013-01-21 sage -combinat update ... applying trac_12453-refactor_integer_vectors-ts.patch patching file sage/combinat/integer_vector.py Hunk #22 FAILED at 1254 1 out of 23 hunks FAILED -- saving rejects to file sage/combinat/integer_vector.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_12453-refactor_integer_vectors-ts.patch Abort The good news is that things work with 5.7, so I'll stop complaining about 5.6. :-) Franco -- -- 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: WARNING: Docbuilder patch (#6495) going into combinat
After a fresh install of sage-5.6, I try to install the sage-combinat patches and sage -combinat install ... applying trac_6495-part1-moving-files-link.patch patching file doc/en/reference/combinat/index.rst Hunk #1 FAILED at 3 1 out of 3 hunks FAILED -- saving rejects to file doc/en/reference/combinat/index.rst.rej patching file doc/en/reference/cryptography/index.rst Hunk #1 FAILED at 26 1 out of 1 hunks FAILED -- saving rejects to file doc/en/reference/cryptography/index.rst.rej patching file doc/en/reference/groups/index.rst Hunk #2 succeeded at 30 with fuzz 1 (offset -9 lines). patching file doc/en/reference/rings/index.rst Hunk #2 FAILED at 15 1 out of 2 hunks FAILED -- saving rejects to file doc/en/reference/rings/index.rst.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_6495-part1-moving-files-link.patch Abort -- On Wed, Feb 20, 2013 at 12:47 PM, Travis Scrimshaw tsc...@ucdavis.eduwrote: Just as a gotcha!, make its recommended on the ticket that you delete the old output directory before you rebuild the new documentation because the old files still hang around. Best, Travis On Tuesday, February 19, 2013 9:13:37 AM UTC-5, Travis Scrimshaw wrote: Here's the list of patches I disabled: - trac_10193-graded_enumerated_**sets-vd_no_more_nt.patch - trac_10193-review-nb.patch - trac_10193-more-vd.patch - trac_12940_affine_**permutations-td.patch - trac_8703-trees-fh.patch - trac_13987_mary_trees-vp.**patch - trees_symmetry_factor-fh.patch - trac_11529-rooted_trees-fh.**patch - shape_tree-fc.patch - operads-fh.patch - operads_more-fc.patch - bintrees_leaf_paths-fh.patch - q_tree_factorial-fc.patch - algebras_over_operads-fc.**patch - shuffle-operads-fc.patch - trac_14086-parking_**functions-dm.patch - sage-demos-and-tutorials-nt.**patch - trac_Kleshchev-partitions-**am.patch Here is the list of patches I rebased: - trac_13580-map_reduce-old-**fh.patch - trac_10194-factories_policy-**fh.patch - trac_11407-list_clone_improve-**fh.patch - mutator-fh.patch - trac_9280-graded-algebras-**example-fs.patch - trac_10963-more_functorial_**constructions-nt.patch - missing-doc-includes-nt.**patch - finite_semigroup-nt.patch From the rejects, I suspect most of the patches in the trees block will apply once #8703 is rebased. (Miraculously) Sage starts with the full queue applied. Best, Travis -- 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. -- 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] queue broken on 5.6
sage -combinat install ... des erreurs se sont produites durant l'application, veuillez corriger puis rafraîchir *trac_6495-part1-moving-files-link.patch* hg qpush -a ... des erreurs se sont produites durant l'application, veuillez corriger puis rafraîchir *trac_6495_separate_inventory.patch* hg qpush -a ... des erreurs se sont produites durant l'application, veuillez corriger puis rafraîchir *trac_13605-partition_options-ts.patch* hg qpush -a ... des erreurs se sont produites durant l'application, veuillez corriger puis rafraîchir *trac_8392-check_permutation-ts.patch* plus others -- -- 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] patches fail to apply
I just tried applying the queue to 5.6 and came across the following problems (both patches apparently have positive reviews). I didn't try to apply the entire queue, so I don't know whether there are any other issues. This workflow doesn't work for me. - applying trac_14065-combinatorial_object_cmp-ts.patch patching file sage/categories/crystals.py Hunk #1 FAILED at 518 1 out of 3 hunks FAILED -- saving rejects to file sage/categories/crystals.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_14065-combinatorial_object_cmp-ts.patch - applying trac_14130-gyw-bs.patch patching file sage/categories/crystals.py Hunk #1 FAILED at 498 1 out of 1 hunks FAILED -- saving rejects to file sage/categories/crystals.py.rej patching file sage/combinat/crystals/highest_weight_crystals.py Hunk #1 FAILED at 82 1 out of 1 hunks FAILED -- saving rejects to file sage/combinat/crystals/highest_weight_crystals.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_14130-gyw-bs.patch - -- 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: Sage-Combinat queue working on 5.4.beta1
On Wed, Sep 26, 2012 at 7:45 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: On Tue, Sep 25, 2012 at 07:51:10PM -0700, Hugh Thomas wrote: I just tried to install the combinat queue on 5.4.beta1, and got rejects on tableaux-combinatorics-am.patch. I think the issue is that 5.4.beta1 (and 5.4.beta0) have trac_9265_tableaux_categories_am merged, but not the most recent version of it. Since this patch is pretty near the end of the queue, for my purposes I can ignore the problem, but I thought I should report the issue. Ouch. Thanks for the report, I'll look into this. Lesson to be learned: please everybody refrain from modifying a patch in a ticket that is in the closed state; instead, create a new ticket! Does anyone know whether hg can prevent this (can we declare those patches read-only)? Franco -- -- 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.
Re: [sage-combinat-devel] queue broken for sage 5.3
On Tue, Sep 18, 2012 at 10:08 AM, Martin Rubey martin.ru...@math.uni-hannover.de wrote: Hi there, I just installed sage 5.3 from source and did sage -combinat install and got patching file sage/categories/category.py Hunk #6 FAILED at 1803 1 out of 7 hunks FAILED -- saving rejects to file sage/categories/category.py.rej unable to find 'sage/categories/category_with_axiom.py' for patching 1 out of 1 hunks FAILED -- saving rejects to file sage/categories/category_with_axiom.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh impose_mro_for_category_classes-nt.patch Abort I'm rather desperate (I didn't update because I needed a stable environment, but now it seems that the operating system was updated :-()) It's not clear what you are desperate for. The command sage -b main will return you to the main sage branch. This will give you a working copy of sage without any combinat patches applied. Franco -- -- 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.
Re: [sage-combinat-devel] Reject on Sage 5.2
On Thu, Sep 13, 2012 at 11:11 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi Franco, Chris, On Wed, Sep 12, 2012 at 09:11:16AM +0200, Florent Hivert wrote: On Sage 5.2: popcorn-*el/sage-combinat $ sage -combinat qselect ... application de trac_11929_8899-ncsf-qsym-fs-5.2.patch skipping trac_11929_8899-ncsf-qsym-final.patch - guarded by '-5_3_beta2' skipping trac_11929_8899-ncsf-qsym-repr-fix-fs.patch - guarded by '-5_3_beta2' application de trac_13404-sf-nt.3.patch patching file sage/combinat/ncsf_qsym/ncsf.py Hunk #1 FAILED at 492 ... The final ncsf patches seem to apply smoothly on 5.2. Is there any reason not to use them instead of trac_11929_8899-ncsf-qsym-fs-5.2.patch? Then trac_13404-sf-nt.3.patch would apply smoothly without doing something specific for 5.2. At some point there was a conflict with the functorial constructions patch. I guess that has been fixed now, so it is definitely be better to use the final patches. Thanks for noticing this! Should I leave it to you to make the switch? Franco -- -- 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.
Re: [sage-combinat-devel] Re: slice
On Sun, Sep 9, 2012 at 3:01 PM, Travis Scrimshaw tsc...@ucdavis.edu wrote: I feel like it should return at least a mathematically correct parent for consistency. For example sage: p = Partition([4,4,3,1]) sage: slice = p[0:2]; slice [4, 4] sage: p.parent() Partitions of the integer 10 sage: slice.parent() Partitions of the integer 8 Should we have the parent of a partition be Partitions()? With Partitions(3) being a facade parent? (Same remark applies to compositions). Franco -- -- 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.
Re: [sage-combinat-devel] importing patches from #8899 (NCSF/QSym)
Hello, On Fri, Aug 31, 2012 at 5:28 PM, Anne Schilling a...@math.ucdavis.edu wrote: Hi Franco, Thanks so much for doing this! Is it too late to incorporate the change ... on basis ... to ... in basis... to conform with #13404? I guess this could wait for another patch. Okay, I did this and posted a patch at #8899 (it's also on the queue). Please review! Franco -- -- 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] Who is the owner of trac_9280-graded-algebras-example.patch?
Who is the owner of trac_9280-graded-algebras-example.patch? I suspect it is Nicolas Thiéry, and if so, can I take over the patch? Franco -- -- 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] importing patches from #8899 (NCSF/QSym)
Hello everyone, Due to various reasons, the final phase (review, review-review, review-review-review, etc.) of the development of the patches at #8899 happened on trac and not on the sage-combinat queue. I just included the final patch in the queue, but ... - If you are working with sage-5.2, then you only get an earlier version of the QSym/NCSF patch. The final one only applies if you are using sage-5.3.rc0. - I had to rebase (trivial) the following patches because of a change in doc/en/reference/combinat/index.rst: REBASED: invariant_ring_permutation_group-nb.patch REBASED: trac_10538-quiver-cs.patch - I had to disable the following patch, but this is not really a problem since I know it is not being actively developed on the queue: DISABLED: fqsym-fh.patch - And, finally, I found a problem. With the whole queue applied, NCSF/QSym doesn't work: sage: N = NonCommutativeSymmetricFunctions(QQ) Traceback (most recent call last): ... TypeError: Cannot create a consistent method resolution order (MRO) for bases Sets.Realizations.subcategory_class, HopfAlgebras.subcategory_class, GradedAlgebras.subcategory_class Take care, Franco -- -- 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.
Re: [sage-combinat-devel] bug in symmetric function scalar product?
On Wed, Aug 29, 2012 at 8:30 PM, Anne Schilling a...@math.ucdavis.edu wrote:
On 8/29/12 12:16 PM, Nicolas M. Thiery wrote:
On Wed, Aug 29, 2012 at 12:01:13PM -0700, Mike Zabrocki wrote:
Hi,
This one looks really serious. In some ways seems to be computer
dependent because my answers seem to have twice as
many digits as yours.
This really looks like an integer overflow (in the communication with
Symmetrica?), which might differ depending on the hardware.
I think it is not symmetrica per se, but some wrapper functions around
symmetrica
as the following example shows:
sage: f = eval('symmetrica.t_POWSYM_SCHUR')
sage: f({Partition([2,2]):Integer(1)})
s[1, 1, 1, 1] - s[2, 1, 1] + 2*s[2, 2] - s[3, 1] + s[4]
sage: time g = f({Partition([1]*47):Integer(1)})
Time: CPU 13.03 s, Wall: 13.04 s
sage: f({Partition([2,2]):Integer(1)})
s[1, 1, 1, 1] - s[2, 1, 1] + 2*s[2, 2] - s[3, 1] + s[4]
sage: Sym = SymmetricFunctions(QQ)
sage: p = Sym.power()
sage: s = Sym.schur()
sage: s(p[2,2])
s[1, 1, 1, 1] - s[2, 1, 1] + 4631790164*s[2, 2] - s[3, 1] + s[4]
Best,
I've created a ticket for this:
http://trac.sagemath.org/sage_trac/ticket/13413
Franco
--
--
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.
Re: [sage-combinat-devel] bug in symmetric function scalar product?
On Wed, Aug 29, 2012 at 10:36 AM, Anne Schilling a...@math.ucdavis.edu wrote: Hi Franco, Will this also happen on this person's computer with sage-5.3.rc0? I think I am running this on the same computer, but I do not have sage-5.0.1 installed any longer. Don't know. He hasn't upgraded yet. I've tried this on several versions going back to sage-4.6.2 and I don't have this error. If we can't reproduce this problem for the latest version of sage, then it's not a bug. ;-) Franco -- sage: Sym = SymmetricFunctions(QQ) sage: p = Sym.powersum() sage: s = Sym.schur() sage: f = p([1,1,1,1,1,1,1,1,1,1,1])/990 + p([2,2,2,2,2,1])/10 +p([5,5,1])/10 - p([10,1])/10 + p([9,1,1])/3 + p([3,3,3,1,1])/9 +5*p([11])/11 sage: [f.scalar(s(q)) for q in Partitions(11)] [1, 0, 0, 0, 0, 0, 0, 1, 0, 2, 0, 2, 0, 1, 1, 1, 1, 0, 0, -1, 2, 1, -1, 2, 4, 3, 0, 1, 0, 2, 1, 0, 1, 1, 2, 1, 2, 1, 1, 0, 0, 3, 0, 1, -1, 1, 0, 2, 0, 1, 0, 0, 0, -1, 0, 1] Anne On 8/29/12 6:51 AM, Franco Saliola wrote: Someone sent me the following sage session, which I cannot reproduce, but I'm asking whether this is a known issue and whether someone can reproduce it: sage: p=SFAPower(QQ) sage: s=SFASchur(QQ) sage: f = p([1,1,1,1,1,1,1,1,1,1,1])/990 + p([2,2,2,2,2,1])/10 + p([5,5,1])/10 - p([10,1])/10 + p([9,1,1])/3 + p([3,3,3,1,1])/9 + 5*p([11])/11 sage: [f.scalar(s(q)) for q in Partitions(11)] [1, 0, 0, 0, 0, 0, 0, 1, 0, 2, 0, 2, 0, 1, 1, 1, 1, 0, 0, -1, 2, 1, -1, 2, 4, 3, 0, 1, 0, 2, 1, 0, 1, 1, 2, 1, 127020063634, 1, 1, 0, 0, 158403414193, 0, 1, -1, 1, 0, 19558976098, 0, 1, 3804836920632, 29874454, 6021978496, -1, 0, 1] Expected: [1, 0, 0, 0, 0, 0, 0, 1, 0, 2, 0, 2, 0, 1, 1, 1, 1, 0, 0, -1, 2, 1, -1, 2, 4, 3, 0, 1, 0, 2, 1, 0, 1, 1, 2, 1, 2, 1, 1, 0, 0, 3, 0, 1, -1, 1, 0, 2, 0, 1, 0, 0, 0, -1, 0, 1] computer: MacBook Pro with an Intel Core i7 processor (64-bit processor according to the Intel web page) version: Sage-5.0.1-OSX-64bit-10.6 -- 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. -- 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.
Re: [sage-combinat-devel] bug in symmetric function scalar product?
Hello Florent! On Wed, Aug 29, 2012 at 11:00 AM, Florent Hivert florent.hiv...@lri.fr wrote: Hi Franco, Someone sent me the following sage session, which I cannot reproduce, but I'm asking whether this is a known issue and whether someone can reproduce it: sage: p=SFAPower(QQ) sage: s=SFASchur(QQ) sage: f = p([1,1,1,1,1,1,1,1,1,1,1])/990 + p([2,2,2,2,2,1])/10 + p([5,5,1])/10 - p([10,1])/10 + p([9,1,1])/3 + p([3,3,3,1,1])/9 + 5*p([11])/11 sage: [f.scalar(s(q)) for q in Partitions(11)] [1, 0, 0, 0, 0, 0, 0, 1, 0, 2, 0, 2, 0, 1, 1, 1, 1, 0, 0, -1, 2, 1, -1, 2, 4, 3, 0, 1, 0, 2, 1, 0, 1, 1, 2, 1, 127020063634, 1, 1, 0, 0, 158403414193, 0, 1, -1, 1, 0, 19558976098, 0, 1, 3804836920632, 29874454, 6021978496, -1, 0, 1] Expected: [1, 0, 0, 0, 0, 0, 0, 1, 0, 2, 0, 2, 0, 1, 1, 1, 1, 0, 0, -1, 2, 1, -1, 2, 4, 3, 0, 1, 0, 2, 1, 0, 1, 1, 2, 1, 2, 1, 1, 0, 0, 3, 0, 1, -1, 1, 0, 2, 0, 1, 0, 0, 0, -1, 0, 1] I'm wondering: did this happen during a session, or is the bug triggered deterministically after the preceding sequences of command ? It sure looks likely, based on the following session (with 5.3.beta2). To begin with, let's do a change of basis in a small degree: sage: p = SymmetricFunctions(QQ).powersum() sage: s = SymmetricFunctions(QQ).schur() sage: s(p[2,2]) s[1, 1, 1, 1] - s[2, 1, 1] + 2*s[2, 2] - s[3, 1] + s[4] Now let's do one in a larger degree: sage: time g = s(p([1]*47)) Time: CPU 19.16 s, Wall: 20.91 s Now let's do that first one again: sage: s(p[2,2]) s[1, 1, 1, 1] - s[2, 1, 1] + 4571483302*s[2, 2] - s[3, 1] + s[4] That's not the correct answer ! And the next time you ask Sage, it gives different, still incorrect, answers: sage: s(p[2,2]) s[1, 1, 1, 1] - s[2, 1, 1] + 4614252243*s[2, 2] - s[3, 1] + s[4] sage: s(p[2,2]) s[1, 1, 1, 1] - s[2, 1, 1] + 4634718110*s[2, 2] - s[3, 1] + s[4] sage: s(p[2,2]) s[1, 1, 1, 1] - s[2, 1, 1] + 4631047636*s[2, 2] - s[3, 1] + s[4] Franco -- -- 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.
Re: [sage-combinat-devel] Re: Names for the bases of symmetric functions
On Mon, Aug 27, 2012 at 10:15 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Ok, everybody, please vote! sage: Sym.e() Sym; basis: elementary There is an issue with the above in that it makes no mention of the base ring. Knowing the base ring is important since it causes issues with changing bases over different base rings. I don't mind long descriptive default names, especially since I will be able to rename them in my init.sage file. Franco -- -- 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.
Re: [sage-combinat-devel] Re: missing methods from documentation
Hello Simon! On Wed, Aug 22, 2012 at 4:57 PM, Simon King simon.k...@uni-jena.de wrote: Hi! On 2012-08-22, Franco Saliola sali...@gmail.com wrote: --20cf307f346ad0c8b804c7df7c9f Content-Type: text/plain; charset=ISO-8859-1 Over at #8899, I'm having a problem with methods not showing up in the reference manual. Here is a schematic of the class structure: class QuasiSymmetricFunctions(UniqueRepresentation, Parent): class Bases(Category_realization_of_parent): class ElementMethods: def expand(self,n,alphabet='x'): ... It sounds like #9107 (because of double nesting of classes) and #11768 (because of source inspection of parent and element classes) could help. Can you test it (and perhaps review)? Mike Z tested it and found that #9107 fixes the problem (I'll note this on #9107). -- 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.
Re: [sage-algebra] Re: [sage-combinat-devel] Re: dual (co)algebras
On Sun, Aug 19, 2012 at 11:02 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi Franco! On Tue, Aug 14, 2012 at 02:51:16PM -0400, Franco Saliola wrote: What about just dual? By default, it would compute the dual with respect to the category to which it belongs, and we can allow customization like so: sage: H.dual(category=VectorSpaces(QQ)) ... a vector space ... Coming a bit late in the discussion, but I vote +1 on this. That's what we had in MuPAD-Combinat (without the category argument). There is one glitch though, which bothered us too in MuPAD-Combinat. In the case of NCSF/QSym, it's not exactly the dual that we are constructing, but the graded dual. We did not bother finding a solution in MuPAD-Combinat because we were only considering graded duals. But eventually, we will want to also manipulate the full dual, i.e. infinite series. Ah, yes, good point. So should this be called graded_dual? Should this react depending on whether we pass a category which is graded or not (a priori, it does not feel right to me, but ...)? Why doesn't if feel right to you? I would expect different behaviour from the following two commands: A.dual(category=GradedVectorSpaces(QQ)) A.dual(category=VectorSpaces(QQ)) I like the shorthand that John proposed: A.dual(graded=True) A.dual(graded=False) With the default being graded=True if the category is graded. My personal preference is to be able to access all the duality functionality from the dual method (so no methods named graded_dual, ungraded_dual, dual_ungraded, dual_graded, ...). Franco -- -- 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.
Re: [sage-combinat-devel] (With)Realizations
Hello Nicolas! On Thu, Aug 16, 2012 at 5:50 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi Franco! On Tue, Aug 14, 2012 at 01:41:28PM -0400, Franco Saliola wrote: I'm having trouble with (With)Realizations. If I understand correctly, then we have the following. - The methods in Category.WithRealizations.ParentMethods are methods that are inherited by any object in the Category that has realizations. - The methods in Category.Realizations.ParentMethods are methods that are inherited by realizations of an object in the Category. Correct! I want to add a new method for a realization of an algebra. But my method only makes sense if the realization has a basis, so it doesn't apply to all realizations of algebras. So I shouldn't put it in Algebras.Realizations.ParentMethods. Where should I put this method? It should go in: Algebras.Realizations.WithBasis.ParentMethods Ah, yes. But being able to do so requires the ``more functorial construction patch''. I am glad to see another application of this patch :-) Speaking of which, I have been working on it recently, and hope to get it finished or so next week. Great! I added myself to the CC on the ticket. Take care, Franco -- -- 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: [sage-algebra] Re: dual (co)algebras
Hello, I wrote docstrings for the methods dual and duality_pairing and created a ticket: http://trac.sagemath.org/sage_trac/ticket/13372 Now someone has to write the code. :-) Franco -- On Tue, Aug 14, 2012 at 5:23 PM, John H Palmieri jhpalmier...@gmail.com wrote: On Tuesday, August 14, 2012 1:27:49 PM UTC-7, Simon King wrote: [Followup-To: header set to gmane.comp.mathematics.sage.algebra.] On 2012-08-14, John H Palmieri jhpalm...@gmail.com wrote: --=_Part_11_31037299.1344973817229 What about just dual? By default, it would compute the dual with respect to the category to which it belongs, and we can allow customization like so: sage: H.dual(category=VectorSpaces(QQ)) ... a vector space ... I think H.dual() is good. Specifying a category like this also, as well as sage: VectorSpaces(QQ)(H.dual()) Start with an object O in some category C1, take its dual D in C1, and apply the forgetful functor to map it to a sub-category C2; one would not always get the same result as if one first applies the forgetful functor to O and then dualise the result in C2, right? And hence VectorSpaces(QQ)(H.dual()) might (perhaps not here, but in other situations) be different from (VectorSpaces(QQ)(H)).dual(). Would that be a problem? I agree that they might be different in some situations, but I also think it's clear what each means: either dualize first or apply the forgetful functor first. Anyway, I don't think it's a problem. (My original message might have said the wrong thing, though.) -- John -- 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] dual (co)algebras
Hello, What should the method that returns the dual of an algebraic object be called? For example, the dual Hopf algebra of non-commutative symmetric functions is the Hopf algebra of quasi-symmetric functions. At #8899, I am using the following: - dual_space -- returns the dual Hopf algebra - dual_basis -- returns the dual basis of a basis - dual_pairing -- the pairing between a basis and its dual basis Is there already a convention for this that I should be using? Thanks, Franco -- -- 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] (With)Realizations
I'm having trouble with (With)Realizations. If I understand correctly, then we have the following. - The methods in Category.WithRealizations.ParentMethods are methods that are inherited by any object in the Category that has realizations. - The methods in Category.Realizations.ParentMethods are methods that are inherited by realizations of an object in the Category. I want to add a new method for a realization of an algebra. But my method only makes sense if the realization has a basis, so it doesn't apply to all realizations of algebras. So I shouldn't put it in Algebras.Realizations.ParentMethods. Where should I put this method? Franco -- -- 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.
Re: [sage-combinat-devel] Re: dual (co)algebras
Hello Simon, On Tue, Aug 14, 2012 at 2:16 PM, Simon King simon.k...@uni-jena.de wrote: Hi Franco, On 2012-08-14, Franco Saliola sali...@gmail.com wrote: What should the method that returns the dual of an algebraic object be called? I don't know whether a convention exists. But I would suggest the convention dual_name-of-structure Hence, if you have a vector space V then I'd suggest that V.dual_vector_space() returns what it says, and ... For example, the dual Hopf algebra of non-commutative symmetric functions is the Hopf algebra of quasi-symmetric functions. ... H.dual_hopf_algebra() returns the dual Hopf algebra of a Hopf algebra H. I thought about that, but would the Hopf algebra then also have the methods dual_vector_space dual_coalgebra dual_algebra ... since it is a vector space, an algebra, a coalgebra, etc.? What about just dual? By default, it would compute the dual with respect to the category to which it belongs, and we can allow customization like so: sage: H.dual(category=VectorSpaces(QQ)) ... a vector space ... At #8899, I am using the following: - dual_space -- returns the dual Hopf algebra I would tend to expect that dual_space returns the dual (vector) *space*, not a Hopf algebra. - dual_basis -- returns the dual basis of a basis - dual_pairing -- the pairing between a basis and its dual basis Would just pairing be clear enough? Or perhaps duality_pairing, because the pairing is not dual, but comes from duality. I like duality_pairing. Thanks, Simon. Franco -- -- 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: the degree of an element in QSym/NSym/Sym
Hello Andrew, On Mon, Aug 13, 2012 at 8:28 PM, Andrew Mathas andrew.mat...@sydney.edu.au wrote: I think that the default behaviour for categories like GradedAlgebra, GradedAlgebraWithBasis, GradedModule, ... should be to return an error if the element is not homogeneous. I have some code which works with graded modules for a graded algebra and this is what my degree method does -- and is_homogeneous method simply checks to see whether degree() returns False. This is more-or-less the proposed implementation for GradedAlgebraWithBasis, except that degree checks whether is_homogeneous returns True or False. Would it make sense to implement methods maximal_degree or homogenous_degree? Then by default, we would set degree = homogeneous_degree. In cases like symmetric functions, where you are essentially working with polynomials, it makes more sense to return the maximum degree. Right, from the point-of-view of polynomials, one would expect consistency between what happens with symmetric functions and polynomials. I find this very convincing. Such classes should override the default methods. Will do. In this case, the NCSF/QSym patch at #8899 doesn't have to deal with the default behaviour of degree for GradedAlgebraWithBasis. We can leave this for another ticket, but it would be good to decide what should be done. Franco -- -- 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.
Re: [sage-combinat-devel] Re: Trac 9265: Remove `CombinatorialClass` from sage.combinat.tableau
On Tue, Jul 31, 2012 at 9:01 PM, Andrew Mathas andrew.mat...@sydney.edu.au wrote: Sorry, I have pushed the patch onto the queue and reinstated 9265 in the series file. Please let me know if there are any problems. Btw, on trac the patchbot is applying both the old patch and the new one. Could some please tell me how I get it to ignore the old patch. There is a directive that you can use to tell the patchbot which patches to apply. The syntax is: Apply: patch1, patch2, patch3, Two things to note. 1. You have to put the directive in a *comment*; the patchbot only looks for this directive in the comments (and not in the description). 2. (It seems that) The patches are applied in chronological order, no matter what order you specify in the list above. Nonetheless, it is also a good idea to include the list of patches to apply in the *description* since this makes life easier for the release manager and anyone looking to review the ticket. I'll go make this change to #9265. Franco -- -- 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.
Re: [sage-combinat-devel] Re: Trac 9265: Remove `CombinatorialClass` from sage.combinat.tableau
On Tue, Jul 31, 2012 at 10:25 PM, Franco Saliola sali...@gmail.com wrote: On Tue, Jul 31, 2012 at 9:01 PM, Andrew Mathas andrew.mat...@sydney.edu.au wrote: Sorry, I have pushed the patch onto the queue and reinstated 9265 in the series file. Please let me know if there are any problems. Btw, on trac the patchbot is applying both the old patch and the new one. Could some please tell me how I get it to ignore the old patch. There is a directive that you can use to tell the patchbot which patches to apply. The syntax is: Apply: patch1, patch2, patch3, Two things to note. 1. You have to put the directive in a *comment*; the patchbot only looks for this directive in the comments (and not in the description). 2. (It seems that) The patches are applied in chronological order, no matter what order you specify in the list above. Nonetheless, it is also a good idea to include the list of patches to apply in the *description* since this makes life easier for the release manager and anyone looking to review the ticket. I'll go make this change to #9265. Now when you click on the patchbot swirl, it lists the correct patch. Franco --- -- 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.
Re: [sage-combinat-devel] install page for windows
On Mon, Jul 30, 2012 at 3:19 AM, Anne Schilling a...@math.ucdavis.edu wrote: Hi All! Travis just added a wiki page on how to install sage under windows http://wiki.sagemath.org/combinat/SageDevelWindows This looks great! Thanks for putting this together, Travis. PS: Franco, you promised Travis a reward for this! Indeed! :-) Franco -- -- 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.
Re: [sage-combinat-devel] Hopf algebra methods
Hello, On Wed, Jul 25, 2012 at 12:24 AM, Anne Schilling a...@math.ucdavis.edu wrote: On 7/24/12 6:06 PM, Daniel Bump wrote: The symmetric function patch #5457 is a big step towards being able to work with the Hopf algebra of symmetric functions. I am glad you appreciate the new functionalities! Here's an interesting fact. Recall that the elements of the symmetric function Hopf algebra can be interpreted as representations of the symmetric group. For example, the Schur polynomials correspond to the irreducible representations. (See Zelevinsky, Representations of finite classical groups, A Hopf algebra approach. Lecture Notes in Mathematics, 869.) What about the Hopf square map, which is the composition of the comultiplication and the multiplication? It may be checked using Mackey theory that this, applied to an irreducible representation gives the same answer as inducing the representation from S_n to the hyperoctahedral group (Weyl group of type B_n), then restricting it back to the symmetric group. The Hopf n-th power map similarly implements induction to other wreath products of cyclic groups. So if I want to compute the Hopf square, I can try ... sage: Sym = SymmetricFunctions(QQ) sage: s = Sym.s() sage: s[3].coproduct() s[] # s[3] + s[1] # s[2] + s[2] # s[1] + s[3] # s[] sage: s[]*s[3] + s[1]*s[2] + s[2]*s[1] + s[3]*s[] Then what? The last line should really be sage: s[[]]*s[3] + s[1]*s[2] + s[2]*s[1] + s[3]*s[[]] due to limitations in python. What I want is sage: s([])*s([3]) + s([1])*s([2]) + s([2])*s([1]) + s([3])*s([]) 2*s[2, 1] + 4*s[3] but I'd rather not have to retype the output, which is what I did here. Is there an automatic way of getting this? You can try sage: def mu(f): : Sym = SymmetricFunctions(QQ) : s = Sym.schur() : coeffs = f.monomial_coefficients() : return sum( coeffs[a]*s(a[0])*s(a[1]) for a in coeffs) : sage: f = s[3].coproduct() sage: mu(f) 2*s[2, 1] + 4*s[3] You can also define this using module_morphism on the basis elements, as follows. sage: Sym = SymmetricFunctions(QQ) sage: s = Sym.schur() sage: t = s.tensor_square() sage: mu = t.module_morphism(on_basis=lambda (a,b) : s[a]*s[b], codomain=s) sage: f = s[3].coproduct(); f s[] # s[3] + s[1] # s[2] + s[2] # s[1] + s[3] # s[] sage: mu(f) 2*s[2, 1] + 4*s[3] Perhaps this multiplication map should be part of the patch? The only thing I could not yet figure out is how to access s from the tensor product. The naive try to obtain the left tensor factor does not work sage: f s[] # s[3] + s[1] # s[2] + s[2] # s[1] + s[3] # s[] sage: f.monomials() [s[] # s[3], s[1] # s[2], s[2] # s[1], s[3] # s[]] sage: f.monomials()[0] s[] # s[3] sage: f.monomials()[0][0] 0 Optionally I'd like to be able to do stuff like apply the antipode to the second component ... sage: s([])*s([3]).antipode() + s([1])*s([2]).antipode() + s([2])*s([1]).antipode() + s([3])*s([]).antipode() 0 How can I do these things without having to retype it all? def mu_a(f): Sym = SymmetricFunctions(QQ) s = Sym.schur() coeffs = f.monomial_coefficients() return sum( coeffs[a]*s(a[0])*s(a[1]).antipode() for a in coeffs) sage: mu_a(f) 0 Continuing from above, we construct the endomorphism of the identity tensor the antipode as a module morphism: sage: id_tensor_antipode = t.module_morphism(on_basis=lambda (a,b) : tensor([s[a], s[b].antipode()]), codomain=t) Then we can compose this with the multiplication map defined above: sage: mu_a = mu * id_tensor_antipode sage: mu_a(f) 0 Franco -- -- 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.
Re: [sage-combinat-devel] combinatorial statistics
Hello Christian, I just pushed a change to composition.py which breaks your patch. Since you are actively working on this, I decided not to rebase your patch but instead disabled it. It is a very easy rebase in the import statements. Also, I disabled Mike's patch, which depends on yours. Please re-enable it as well when you enable yours: pp_function_for_dyck_words-mz.patch Franco -- On Thu, Jul 5, 2012 at 4:40 AM, Christian Stump christian.st...@gmail.com wrote: Hi Martin, one patch per class? that's completely up to you, I guess Another question: is it important to keep the number of statistics small? I.e., if a statistic can be constructed via a map, is it better *not* to implement it? (Eg., saliances and right-to-left-minima.) I usually do implement them, and add it then to the black list of the combinatorial map. Otherwise we would even not have maj or inv since the bijection sending maj to inv is also implemented. How about aliases? (I would like to have right-to-left-maxima be an alternative name to saliances...) we already use them some times. only the decorated one will appear, not the alias. best, christian -- 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. -- 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.
Re: [sage-combinat-devel] combinatorial statistics
On Thu, Jul 5, 2012 at 12:49 PM, Christian Stump christian.st...@gmail.com wrote: I just pushed a change to composition.py which breaks your patch. I rebased the patch and also enabled Mike's patch again. But now, I get the following error message after applying the queue, so I don't push the changed... Any idea (I am using 5.0)? -- sage: Building and installing modified Sage library files. Installing c_lib scons: `install' is up to date. Updating Cython code Building modified file sage/categories/action.pyx. Building modified file sage/categories/category_singleton.pyx. Building modified file sage/categories/morphism.pyx. Building modified file sage/categories/examples/semigroups_cython.pyx. Building modified file sage/structure/list_clone.pyx. Building modified file sage/structure/list_clone_demo.pyx. Building sage/structure/list_clone_timings_cy.pyx because it depends on sage/structure/list_clone.pxd. Building modified file sage/sets/finite_set_map_cy.pyx. Building modified file sage/combinat/dict_addition.pyx. Traceback (most recent call last): File setup.py, line 830, in module queue = compile_command_list(ext_modules, deps) File setup.py, line 790, in compile_command_list dep_file, dep_time = deps.newest_dep(f,m) File setup.py, line 697, in newest_dep for f in self.all_deps(filename, ext_module): File setup.py, line 678, in all_deps for f in self.immediate_deps(filename, ext_module): File setup.py, line 660, in immediate_deps self._deps[filename] = self.parse_deps(filename, ext_module) File setup.py, line 648, in parse_deps raise IOError, msg IOError: could not find dependency sage/combinat/enumeration_mod_permgroup.pxd included in sage/combinat/invariant_ring_perm_gps/invariant_cython.pyx. Error installing modified sage library code. I think you have to reset your guards. Option 1: sage -combinat qselect Option 2: sage -combinat update Franco -- -- 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.
Re: [sage-combinat-devel] bug in ._apply_module_morphism in freemodule.py or in Partitions or just in symmetric functions ?
On Fri, Jun 15, 2012 at 10:36 AM, Mike Zabrocki mike.zabro...@gmail.com wrote:
I agree with you that __len__ should be removed, especially if len(
finiteclass ) returns a value. But even if it doesn't then the correct
method to use is finiteclass.cardinality() anyway. Right?
About this ._apply_module_morphism() fix though. The segment of code that
is is in combinat/free_module.py currently reads:
if x == self.zero():
if not codomain:
B = self.basis()
keys = list( B.keys() )
if len( keys ) 0:
key = keys[0]
codomain = on_basis( key ).parent()
else:
raise ValueError, 'Codomain could not be determined'
return codomain.zero()
That is, it is trying to determine the codomain by picking an element of the
domain. But in the case when the domain doesn't exist (when would this
happen? I don't know how to trigger this) it raises a value error. Can I
replace this with the code?:
if x == self.zero():
if not codomain:
B = self.basis()
codomain = on_basis( B.first() ).parent()
return codomain.zero()
This looks good. I see two minor issues.
1) It will raise an error when B.first() is not defined. But
self.basis() returns a Family, so it shouldn't happen unless a user
redefines self.basis(). We could support this with the following:
B = Family(self.basis())
which will work provided that self.basis() is iterable.
2) Another issue is that the domain may be 0-dimensional:
sage: F = CombinatorialFreeModule(QQ, [])
sage: F.basis()
Finite family {}
sage: F.basis().first()
Traceback (most recent call last):
...
StopIteration
Should we worry about this? We could use a try-except statement to
catch this error:
if not codomain:
B = Family(self.basis())
try:
z = B.first()
except StopIteration:
raise ValueError, 'Codomain could not be determined'
codomain = on_basis(z).parent()
Franco
--
--
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.
Re: [sage-combinat-devel] Re: symmetric functions
On Fri, Jun 15, 2012 at 9:36 PM, Anne Schilling a...@math.ucdavis.edu wrote: Hi! I am encountering some problems with the tests in symmetric functions. This is with the sage-combinat queue applied to kschur-fix-as.patch. 1) When I do --- d099:sf anne$ sage -t sf.py sage -t devel/sage-combinat/sage/combinat/sf/sf.py ** File /Applications/sage-5.0/devel/sage-combinat/sage/combinat/sf/sf.py, line 585: sage: KB = Sym.kBoundedSubspace(3,1); KB Expected: 3-bounded Symmetric Functions over Rational Field Got: 3-bounded Sym --- I get the above error message. However from the command line I get the correct output. --- d099:sf anne$ sage -- | Sage Version 5.0, Release Date: 2012-05-14 | | Type notebook() for the GUI, and license() for information. | -- Loading Sage library. Current Mercurial branch is: combinat sage: Sym = SymmetricFunctions(QQ) sage: KB = Sym.kBoundedSubspace(3,1); KB 3-bounded Symmetric Functions over Rational Field --- What is going on? Do you get the same behavior? I think it is because of this doctest: sage: Sym.rename(Sym) sage: Sym Sym and UniqueRepresentation. So the object is somehow persisting from one doctest block to another. They are not completely independent it seems. I don't know how to fix this problem. 2) I am not quite sure what is missing in the following. Where do I need to add Realizations? sage: Sym = SymmetricFunctions(QQ['t']) sage: from sage.combinat.sf.new_kschur import KBoundedSubspace, KBoundedSubspaceBasis sage: KB = KBoundedSubspace(Sym,3) sage: ks = KB.kschur() sage: KBB = KBoundedSubspaceBasis(ks); sage: KBB.super_categories() --- AttributeError Traceback (most recent call last) /Applications/sage-5.0/devel/sage-combinat/sage/combinat/sf/ipython console in module() /Applications/sage-5.0/local/lib/python2.7/site-packages/sage/combinat/sf/new_kschur.pyc in super_categories(self) 203 R = self.base().base_ring() 204 category = GradedHopfAlgebrasWithBasis(R) if self.t == 1 else GradedCoalgebrasWithBasis(R) -- 205 return [Realizations(self.base()), category.Subobjects()] 206 207 class ParentMethods: /Applications/sage-5.0/local/lib/python2.7/site-packages/sage/categories/realizations.pyc in Realizations(self) 96 return RealizationsCategory.category_of(self) 97 else: --- 98 return getattr(self.__class__, Realizations)(self) 99 100 Category.Realizations = Realizations AttributeError: type object 'kSchur_with_category' has no attribute 'Realizations' There are some other patches that in the queue that fiddle with realizations. Perhaps try putting your patch below / above these patches? 3) Some of the test suites do not pass. sage: Sym = SymmetricFunctions(QQ) sage: from sage.combinat.sf.new_kschur import KBoundedSubspace sage: L3 = KBoundedSubspace(Sym,3,1) sage: TestSuite(L3).run() Where do I need to implement the missing methods? I have the entire queue applied, and I can't construct L3: sage: L3 = KBoundedSubspace(Sym,3,1) AttributeError: 'kSchur_with_category' object has no attribute 'product' I need to qpop to your patch to see the errors, but it takes too long to rebuild the queue and I don't have the time to look at this now. I hope some of this is helpful. Franco -- -- 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.
Re: [sage-combinat-devel] bug in ._apply_module_morphism in freemodule.py or in Partitions or just in symmetric functions ?
On Mon, Jun 11, 2012 at 10:54 PM, Mike Zabrocki mike.zabro...@gmail.com wrote: Hi all, In running some symmetric function code I ran across the problem that my code started freezing somewhere in the middle of the calculation. I tracked it down and I had assumed that it was in the changes that I had made to the symmetric function code. Nope. I went back to sage main and could recreate the same issue. I was also able to recreate the same sort of issue with plethysm and inner_plethysm. Easy fix: if value .is_zero() don't call the ._apply_module_morphism() Second easy fix: if value .is_zero() have ._apply_module_morphism() return 0 But is the problem deeper? It seems so. I found the code is freezing because ._apply_module_morphism is calling the following recreate-able issue: sage: s = SymmetricFunctions(QQ).s() # or s = SFASchur(QQ) in sage-main sage: list( s.basis() ) I was playing around with this in sage with all the combinat patches applied, and it actually returns an error: sage: s = SymmetricFunctions(QQ).s() sage: b = s.basis() sage: list(b) Traceback (most recent call last): ... NotImplementedError: infinite list But when I try this, I don't get an error: sage: k = b.keys() sage: list(k) Instead, it is running through the iterator. The discrepancy seems to lie with __len__: sage: len(b) Traceback (most recent call last): ... NotImplementedError: infinite list sage: len(k) Traceback (most recent call last): ... AttributeError: __len__ has been removed; use .cardinality() instead Perhaps it is time to remove this deprecation message in favor of the NotImplementedError above. Just deleting __len__ from CombinatorialClass fixes this discrepancy: sage: s = SymmetricFunctions(QQ).s() sage: b = s.basis() sage: k = b.keys() sage: list(k) Traceback (most recent call last): ... NotImplementedError: infinite list So, should we remove __len__ from CombinatorialClass? (Note that this doesn't solve Mike's original problem, but it does at least catch the bug.) Franco -- -- 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.
Re: [sage-combinat-devel] integer matrices
On Sat, Jun 9, 2012 at 5:54 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: On Fri, Jun 08, 2012 at 12:08:07AM -0400, Franco Saliola wrote: Is there something in sage that will return integer matrices with row sums (4, 4, 0, 5) and column sums (3, 7, 1, 0, 2) ? (for example) I have something that does this in the NCSF code on the queue, but I'm wondering whether it is already implemented. We had this in MuPAD-Combinat: http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/COMBINAT/integerMatrices.mu?revision=7608view=markup (see also the doc and tests in DOC/ and TESTS/ respectively) The generation was done recursively using integer vectors (i.e. IntegerListsLex). The counting was done using symmetric functions (which in turn, at some point in history, used the counting of integer matrices, yielding a recursive loop ...). This is essentially what I was doing in the ncsf internal products code, so I factored it out, made it into an enumerated set, added documentation (some of which I stole from the above), and put it in sage.combinat.integer_matrices. It's up on the queue and essentially complete. I should create a ticket for this Franco -- -- 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.
Re: [sage-combinat-devel] testing new symmetric function functionality
On Thu, Jun 7, 2012 at 12:26 PM, Mike Zabrocki mike.zabro...@gmail.com wrote:
Hey SFA users...
I've been working on a patch to change how symmetric functions are used in
the future. I will be deprecating some common functions soon on the sage
combinat queue and we will try to get this into sage in an upcoming version.
Starting soon: SFAxxx where xxx in {Schur, Monomial, Homogeneous,
Elementary, Power} will not be the way to access these functions.
Old notation:
sage: s = SFASchur(QQ)
sage: h = SFAHomogeneous(QQ)
sage: e = SFAElementary(QQ)
...
The new notation will be:
sage: SF = SymmetricFunctions(QQ)
sage: s = SF.schur() # or .s()
sage: h = SF.homogeneous() # or .h()
sage: e = SF.elementary() # or .e()
sage: p = SF.power() # or .p()
sage: m = SF.monomial() # or .m()
Let me also point out that you can define s, h, e, p, and m in one
line with the command:
sage: SF.inject_shorthands()
Moreover, LLT polynomials, Hall-Littlewood, Jack and Macdonald symmetric
functions have all been moved into SymmetricFunctions(R).
sage: Mac = SF.macdonald()
gives an error because q and t are not in the ring! (this is different
behavior than before where the q and t were added to the base ring)
Why can't SF.macdonald() just return the appropriate thing?
If you really are going to do this, then you need to improve the error message:
ValueError: parameter q must be in the base ring
Perhaps we can include in the error message the command that would
produce what the user wants?
Franco
--
New notation:
sage: SF = SymmetricFunctions(QQ['q','t'].fraction_field())
sage: Mac = SF.macdonald()
sage: MP = Mac.P() # or .Q() or .J() or .H() or .Ht()
sage: HL = SF.hall_littlewood()
sage: HLP = HL.P() # or .Q() or .Qp()
sage: Jack = SF.jack()
sage: JP = Jack.P() # or .Q() or .Qp() or .J()
sage: LLT = SF.llt(2) # 2 is the level here which needs to be specified
sage: HS = LLT.hspin() # .hcospin()
The real improvements are behind the scenes. Your field can be more general
than before and your q and t parameters should be something in that field.
sage: SF = SymmetricFunctions(QQ['x','y'].fraction_field()); (x,y) =
SF.base_ring().gens()
sage: MPxy = SF.macdonald(q=x,t=y).P()
sage: MPy5 = SF.macdonald(q=y,t=5).P()
sage: MPy5(MPxy[2,1])
Other changes include bringing .omega_qt(), .scalar_qt() and .nabla() to all
bases and adding q=value, t=value as optional parameters.
I could use some help testing. If you use symmetric functions and notice
any bad behavior please pass along odd doc tests.
If you want functionality does not seem to be part of these changes, please
feel free to add your two cents.
-Mike
--
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/-/O1XqNR_bbLUJ.
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.
--
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.
Re: [sage-combinat-devel] Problems with committing
Hello Andrew, On Wed, Jun 6, 2012 at 4:20 AM, Andrew Mathas andrew.mat...@gmail.com wrote: Hi, I have a patch (for tuples of partitions) which I want to commit to the queue and I have a second patch (for tuples of tableaux) that I have been working on which I don't want to commit yet. When I try committing from the first patch I get the error abort: cannot commit over an applied mq patch Can you include the exact command that you used to try this? so evidentially I'm doing something wrong. Is some one able to tell me what I should be doing?! I'm not sure that there is an easy way to commit only one patch and not another other. The reason is that the series file (the file that lists all the patches in the queue) will include the name of both patches, so if someone tries to apply the queue, they will get an error message about a missing patch. Here is one way to achieve this (i.e, remove the second patch from the queue, then commit): - suppose you have good.patch and bad.patch, and you only want to commit good.patch - hg export bad.patch ~/bad.patch # make a copy of the patch outside of sage - hg qrm bad.patch # deletes the patch from the queue - commit as usual - hg qimport ~/bad.patch # put that patch back into the queue I've also realised that I am slightly confused about the patch queue set up in that I do not know how the patch queue and the trac server relate. I've got a version of the PartitionTuple patch on the trac server already -- which I uploaded via the web interface. It seems to me that the patch queue and trac are independent. Correct. Would some one mind explaining to me what the point of each of them is? Here is one answer. The trac server tracks Sage development and anything that gets added to sage goes through the trac server. Although it is possible for several people to collaborate on a particular ticket, it is more difficult: each person posts their changes to the trac ticket; when a new patch is posted, it needs to be downloaded and applied to Sage. This can get cumbersome because you need to know the order in which the patches need to be applied and which ones to avoid (one can't delete patches posted on trac, so you often see comments like don't apply this patch). Part of the purpose of the patch queue is the make this process easier. It allows for several people to work on a given feature that builds upon other peoples' work even if these features are not yet in Sage. For example, Chris B, Mike Z and I are currently working on implementing the Hopf algebras of non-commutative symmetric functions and the quasisymmetric functions, which in turn builds upon patches that were written by Nicolas T and Jason B and some new functionality not yet in Sage. This would be very difficult to accomplish using just the trac server. A nice side-effect of this is that when we use the new functionality not yet in Sage it often leads to improvements to that code. I hope this is helpful. Maybe others can / will say more. Apologies for my silly questions! These are not silly questions! Franco -- -- 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.
Re: [sage-combinat-devel] import statement strange behaviour
On Fri, May 25, 2012 at 6:16 PM, Vincent Delecroix
20100.delecr...@gmail.com wrote:
What about allowing the user to pass cached_method (as a string) to
import_statements?
Now, the following works
sage: import_statement('cached_function')
from sage.misc.cachefunc import cached_function
Note that the option verbose should perhaps be True by default?
+1. The user should be aware that there are other possibilities, and
hopefully will pick accordingly. Perhaps print a blankline after the
warnings so that it is easy to distinguish the warnings from the blank
lines?
Instead of blankline I put
sage: import_statement(ZZ)
** Warning **: several names for that object: ZZ, Z
from sage.rings.integer_ring import ZZ
Thank you Franco for the feedback!
Thanks for your work on this!
By the way, you haven't pushed your latest changes.
Take care,
Franco
--
--
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.
Re: [sage-combinat-devel] import statement strange behaviour
On Fri, May 25, 2012 at 9:39 AM, Vincent Delecroix 20100.delecr...@gmail.com wrote: Potential workarounds: - Accept things as they are: that's just a corner case, it's easy for the user to fix the name after the import - Accept strings like cached_method as input as well as names for those cases I like it better. But that way there is no better method than parsing for finding its module! - Find some heuristic for those cases (usually the lower case is preferred to the upper case?) Nope. It really depends. Some funny guy may write integer_ring = IntegerRing() somewhere. Anyway, we should not waste too much time on that. +1 The last version of the patch seems better (it corrects the from 'sage.all import ZZ' into 'from sage.rings.integer_ring import ZZ' but keeps the problem of CachedMethod vs cached_method). What about allowing the user to pass cached_method (as a string) to import_statements? Note that the option verbose should perhaps be True by default? +1. The user should be aware that there are other possibilities, and hopefully will pick accordingly. Perhaps print a blankline after the warnings so that it is easy to distinguish the warnings from the blank lines? Franco -- -- 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] constructing the same poset twice
Is anyone else experiencing this problem: sage: P = lambda n : Poset([range(n), [(i,i+1) for i in range(0,n,2)]]) sage: time p = P(1); p Time: CPU 2.24 s, Wall: 2.60 s Finite poset containing 1 elements sage: time p = P(1); p ...takes much, much, much longer then 2s...still hasn't finished... Franco -- -- 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.
Re: [sage-combinat-devel] constructing the same poset twice
On Fri, May 25, 2012 at 11:46 AM, Christian Stump christian.st...@gmail.com wrote: sage: P = lambda n : Poset([range(n), [(i,i+1) for i in range(0,n,2)]]) sage: time p = P(1); p Time: CPU 2.24 s, Wall: 2.60 s Finite poset containing 1 elements sage: time p = P(1); p ...takes much, much, much longer then 2s...still hasn't finished... same here -- do you already know where that comes from? Nope. -- 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.
Re: [sage-combinat-devel] constructing the same poset twice
On Fri, May 25, 2012 at 12:02 PM, Mike Hansen mhan...@gmail.com wrote: If posets are unique, then the code is probably doing an equality test which could be taking up the time. Ah, that's probably it. -- 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.
Re: [sage-combinat-devel] Bug with trac_12959-improve_with_realizations-fs.patch
Hello Viviane, On Fri, May 25, 2012 at 6:16 AM, Viviane Pons p...@univ-mlv.fr wrote: Hi everyone, this patch is breaking Ambient spaces which breaks my patch for example, and probably lots of other stuff... I'm not sure what the problem is, so can somebody have a look or disable the patch if the person is not available (I did it on my local copy but I didn't want to push it because I have no idea what the patch does and where it is needed). sage: R = RootSystem(A3) sage: R.ambient_space() --- TypeError Traceback (most recent call last) /home/pons/sage-5.0/devel/sage-combinat/ipython console in module() /home/pons/sage-5.0/local/lib/python2.7/site-packages/sage/misc/cachefunc.so in sage.misc.cachefunc.CachedMethodCaller.__call__ (sage/misc/cachefunc.c:6299)() /home/pons/sage-5.0/local/lib/python2.7/site-packages/sage/misc/cachefunc.so in sage.misc.cachefunc.CachedMethod._instance_call (sage/misc/cachefunc.c:8524)() /home/pons/sage-5.0/local/lib/python2.7/site-packages/sage/combinat/root_system/root_system.pyc in ambient_space(self, base_ring) 674 if base_ring == ZZ and AmbientSpace.smallest_base_ring() == QQ: 675 return None -- 676 return AmbientSpace(self, base_ring) Disabling this patch will break other patches, so I pushed a different change instead. (I disabled the inheritance from BindableClass for CombinatorialFreeModule, which is a new, very, very experimental feature.) I hope this fixes things for you. Take care, Franco -- -- 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.
Re: [sage-combinat-devel] bug in poset
Hello Anne, On Wed, May 23, 2012 at 1:43 AM, Anne Schilling a...@math.ucdavis.edu wrote: On 5/22/12 6:17 PM, Franco Saliola wrote: Hello Anne, Darij, On Tue, May 22, 2012 at 2:50 PM, Darij Grinberg darijgrinb...@gmail.com mailto:darijgrinb...@gmail.com wrote: Hi Anne, For a finite poset perhaps the easiest would be to - start with a random element in the poset, assign rank 0 - look at all covers and cocovers and assign the rank according to the recurrence rank(x) = rank(y) + 1 if x covers y. - repeat with the new elements - if at any point an element is reached again and is assigned a different value from before, the poset is not graded; otherwise continue with new elements Add some constant to all ranks, so that the minimal rank is 0. You are right - I was trying to apply algebra too eagerly. This is basically a Dijkstra algorithm. Darij, do you think you can implement this? Here's a stupid implementation: http://mit.edu/~darij/www/rf.txt (to replace the rank_function implementation in sage/combinat/posets/hasse-diagram.py). Unfortunately I couldn't really test it in context since I have no idea how to make Sage recognize my changes to the sourcecode. (./sage -combinat upgrade notices the change but wants me to qrefresh, whatever this means; I haven't yet got around to learning hg.) I have checked that, when applied to a poset's Hasse diagram, it gives the right results. I created a ticket for this: http://trac.sagemath.org/sage_trac/ticket/12993 I'm going to post some comments for Darij there. Thank you, Franco! Does this mean you agree that this is a bug? Well, I agree that your poset has a rank function, so the rank_function method needs to be modified. And I think that P.is_ranked() should return True in this case (it will once the rank_function method is corrected). As for whether graded is a synonym for ranked, that's up for discussion. Stanley's Enumerative Combinatorics defines a graded poset as one in which all maximal chains have the same length. Since we have two notions here, perhaps we can include both. For example: - a poset is *ranked* if it admits a rank function; so P.is_ranked() will return True for Anne's example. - a poset if *graded* if all maximal chains have the same length; so P.is_graded() will return Fase for Anne's example. Thoughts? Other terms to distinguish between these two definitions? Some authors (Wachs, Björner, ...) use *pure* for graded in Stanley's sense. Darij, please also add more documentation to the is_ranked, is_graded rank_function methods to say how grading is defined (so that it is clear for future users). +1 Franco -- -- 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.
Re: [sage-combinat-devel] bug in poset
On Wed, May 23, 2012 at 9:32 AM, Anne Schilling a...@math.ucdavis.edu wrote: Hi Franco and Darij and ..., Hello Anne, Darij, On Tue, May 22, 2012 at 2:50 PM, Darij Grinberg darijgrinb...@gmail.com mailto:darijgrinb...@gmail.com wrote: Hi Anne, For a finite poset perhaps the easiest would be to - start with a random element in the poset, assign rank 0 - look at all covers and cocovers and assign the rank according to the recurrence rank(x) = rank(y) + 1 if x covers y. - repeat with the new elements - if at any point an element is reached again and is assigned a different value from before, the poset is not graded; otherwise continue with new elements Add some constant to all ranks, so that the minimal rank is 0. You are right - I was trying to apply algebra too eagerly. This is basically a Dijkstra algorithm. Darij, do you think you can implement this? Here's a stupid implementation: http://mit.edu/~darij/www/rf.txt (to replace the rank_function implementation in sage/combinat/posets/hasse-diagram.py). Unfortunately I couldn't really test it in context since I have no idea how to make Sage recognize my changes to the sourcecode. (./sage -combinat upgrade notices the change but wants me to qrefresh, whatever this means; I haven't yet got around to learning hg.) I have checked that, when applied to a poset's Hasse diagram, it gives the right results. I created a ticket for this: http://trac.sagemath.org/sage_trac/ticket/12993 I'm going to post some comments for Darij there. Thank you, Franco! Does this mean you agree that this is a bug? Well, I agree that your poset has a rank function, so the rank_function method needs to be modified. And I think that P.is_ranked() should return True in this case (it will once the rank_function method is corrected). As for whether graded is a synonym for ranked, that's up for discussion. Stanley's Enumerative Combinatorics defines a graded poset as one in which all maximal chains have the same length. Since we have two notions here, perhaps we can include both. For example: - a poset is *ranked* if it admits a rank function; so P.is_ranked() will return True for Anne's example. - a poset if *graded* if all maximal chains have the same length; so P.is_graded() will return Fase for Anne's example. Thoughts? Other terms to distinguish between these two definitions? Some authors (Wachs, Björner, ...) use *pure* for graded in Stanley's sense. Some references use graded and ranked as synonyms. However, I agree that Stanley's definition is different, so we might as well distinguish this in the code. But then I really pledge for good documentation stating the precise mathematical definition, so that the user knows what (s)he is testing. Currently there is no definition of what is meant by the various terms. There are some definitions in the documentation already: sage: P = Poset(([1,2,3,4],[[1,4],[2,3],[3,4]])) sage: P.is_graded? ... A poset is *graded* if it admits a rank function. ... sage: P.is_ranked? ... A poset is *ranked* if it admits a rank function. ... sage: P.rank_function? ... A *rank function* of a poset P is a function r ... Any suggestions on improving it to make things clearer for the user? Take care, Franco -- -- 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.
Re: [sage-combinat-devel] bug in poset
Hello Anne, Darij, On Tue, May 22, 2012 at 2:50 PM, Darij Grinberg darijgrinb...@gmail.comwrote: Hi Anne, For a finite poset perhaps the easiest would be to - start with a random element in the poset, assign rank 0 - look at all covers and cocovers and assign the rank according to the recurrence rank(x) = rank(y) + 1 if x covers y. - repeat with the new elements - if at any point an element is reached again and is assigned a different value from before, the poset is not graded; otherwise continue with new elements Add some constant to all ranks, so that the minimal rank is 0. You are right - I was trying to apply algebra too eagerly. This is basically a Dijkstra algorithm. Darij, do you think you can implement this? Here's a stupid implementation: http://mit.edu/~darij/www/rf.txt (to replace the rank_function implementation in sage/combinat/posets/hasse-diagram.py). Unfortunately I couldn't really test it in context since I have no idea how to make Sage recognize my changes to the sourcecode. (./sage -combinat upgrade notices the change but wants me to qrefresh, whatever this means; I haven't yet got around to learning hg.) I have checked that, when applied to a poset's Hasse diagram, it gives the right results. I created a ticket for this: http://trac.sagemath.org/sage_trac/ticket/12993 I'm going to post some comments for Darij there. Franco -- -- 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.
Re: [sage-combinat-devel] import statement strange behaviour
On Mon, May 21, 2012 at 5:38 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Bonjour Vincent! On Mon, May 21, 2012 at 11:24:09AM +0200, Vincent Delecroix wrote: In particular sage: sage: module = sys.modules[ZZ.__module__] sage: [key for key in module.__dict__ if module.__dict__[key] == ZZ] [] Here we are lucky enough that we can get the object through its class: sage: module = sys.modules[ZZ.__class__.__module__] sage: [key for key in module.__dict__ if module.__dict__[key] == ZZ] ['ZZ', 'Z'] This seems like a typical use case that such objects are instantiated in the same module as their class. Then, if all else fail, indeed recourse to find/grep (or maybe using search_src to avoid reimplementing that find/grep?). If this fails as well: oh well. import_statements is nothing but a little interactive convenience; it should work in most cases, but if it occasionally fails, so be it. If we get really annoyed, we will improve in a later iteration based on the found counter-examples. Once the import statement is determined, can we try to evaluate it and raise an error if it doesn't work? This would at least catch syntax errors like this: from sage.rings.rational_field import Rational Field Then we could try the next strategy, and so on. Franco -- -- 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.
Re: [sage-combinat-devel] NCSF / affine permutation patches
On Mon, May 21, 2012 at 12:46 PM, Chris Berg cb...@lacim.ca wrote: I don't know how to do that... I had been working in Tom's patch by mistake, but then I went to qrefresh, saw it was his patch, and then backed up all my changes, hg revert --all, and then went to my own patch. Was that not how I should do it? Sorry Tom! I backed up all my changes now, Tom if you know how to fix this then feel free to delete whatever. The thing is, there are two repositories of patches. If you would have done revert in .hg/patches, then this should have worked. I just pushed what I hope is a fix. Test and report. I went into the .hg/patches directory and reverted Tom's patch to revision 6724 (revision 6725 is the revision in which made the changes to Tom's patch). Here is what I did: hg revert -r6724 trac_12940_affine_permutations-td.patch Take care, Franco -- -- 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.
Re: [sage-combinat-devel] import statement strange behaviour
On Mon, May 21, 2012 at 9:38 AM, Vincent Delecroix 20100.delecr...@gmail.com wrote: Dear all, I push a last version of import_statements. Use it and break it... (good luck :-) Chris Berg just pointed out the following example where you don't get the correct import statement: sage: import_statements(cached_function) from sage.misc.cachefunc import CachedFunction It does work correctly for cached_method though: sage: import_statements(cached_method) from sage.misc.cachefunc import cached_method Passing verbose=True shows the problem: sage: import_statements(cached_function, verbose=True) Warning: several names for that object: ['CachedFunction', 'cached_function'] from sage.misc.cachefunc import CachedFunction sage: import_statements(cached_method, verbose=True) Warning: several names for that object: ['cached_method', 'CachedMethod'] from sage.misc.cachefunc import cached_method When there are several names, I think we should return the one that agrees with the name that was given by the user. The implementation uses mainly sys.modules (thank you Nicolas for that pointer). In the case the object is an instance of a class, the final check is done using sage_getsource/re instead of find/grep. If you run tests there is a very nice error: sage: import_statements(ZZ, verbose=True) Expected: [...] sage.all [...] from sage.all import ZZ Got: [...] __main__ [...] from sage.all import ZZ which looks like a bug as the behavior of the tester should be what we get in the command line version of Sage? Yes, it should be the same. This only seems to happen for the warning message. I suggest: - either just replace the sage.all / __main__ with ... in the doctest ; - or remove sage.all from the list of modules. If someone wants to import ZZ, they should not do it with: from sage.all import ZZ but instead with from sage.integer_ring import ZZ Take care, Franco -- -- 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.
Re: [sage-combinat-devel] Re: Hey
Désolé! J'ai lu trop vite. Erreur d'inattention. -- 2012/5/11 Nathann Cohen nathann.co...@gmail.com: Ah he, je peux le retrouver mais ca ne vient pas de mon exemple, c'est juste que j'avais oublié de mettre des () autour des deux paramètres ! J'essaie de remettre la main dessus :-) Nathann On 11 May 2012 22:00, Franco Saliola sali...@gmail.com wrote: Salut Nathann, Peux-tu nous envoyer l'exemple ? Franco -- 2012/5/10 Nathann Cohen nathann.co...@gmail.com: Y !!! Merci pour les infos. C'est plutôt sur sage-combinat devel qu'il faut poster ce genre de truc... Je fais suivre. Arg.. Oui, mais c'était pour écrire en francais et avoir des news au passage ! ;-) Coincé au lit par la grippe :-( Arg !!! Bon, j'espère que tu te sortiras vite de là :-/ Good luck !!! Nathann -- 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. -- 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. -- 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. -- 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.
Re: [sage-combinat-devel] sage-5.0.beta14 is out...
Hello Nicolas, On Wed, May 2, 2012 at 3:50 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: On Tue, May 01, 2012 at 09:14:08PM -0400, Franco Saliola wrote: I compiled sage-4.8 from scratch today, but the queue does not apply for me. The problem is with trac12215_weak_cached_function.patch. Shoot, sorry! I had fixed that, but forgot to push. It should be good now. Good news, bad news and good news. The good news is that with your fix, the queue applies cleanly on 4.8. The bad news is there is an import error on startup: No module named non_unital_algebras. Indeed, there is no such file. Maybe you forgot to push the file? Or did you guard the patch containing it? The good news is that if I comment out the corresponding import line in finite_dimensional_algebras_with_basis.py, then sage starts up properly. So we just need to find that file. By the way, I figure we should have sage-combinat working on 4.8 for the Sage Days next week, which is why I keep testing this. Franco -- -- 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.
Re: [sage-combinat-devel] Problems installing combinat
On Tue, Aug 2, 2011 at 4:55 PM, Tom Roby tro...@gmail.com wrote: I don't seem to be able to install the combinat patches needed to use some of the commands Greg Musiker is showing us at MSRI this week. I've done a fresh install of Sage, made sure that my Mac is in 64-bit mode, commented out all seven echo statements in Perhaps the server is down? Yes, the server is down. Here is the web interface: http://combinat.sagemath.org/patches Keep an eye on that. Once it's back up, you should be good to go. Unfortunately, I don't know how to fix the server. Franco -- -- 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] statistics on combinatorial objects
Hello everyone. Christian Stump, Chris Berg and I have been thinking about statistics on combinatorial objects in Sage. There are several already implemented in Sage, and we think that it would be very useful to have a means to identify. As a simple example, one might want to know all the statistics that are implemented for permutations (or tableaux, or words, or k-ratonslaveurs, ...) in order to output a table of values of these statistics. So the question is: how do we do this? We have been toying with the idea of implementing a decorator (like cached_method) for methods that are statistics. It would take as an argument the codomain of the statistic. Knowing the codomain would make it possible to ask for all integer-valued statistics, say. A typical example would be permutations and integer statistics: @combinatorial_statistic(codomain=Integers) def major_index(self): return ... Comments? Suggestions? Alternative ideas for implementations? Take care, Franco -- -- 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.
Re: [sage-combinat-devel] Missing patch
On Wed, Jul 6, 2011 at 11:53 AM, Franco Saliola sali...@gmail.com wrote: On Wed, Jul 6, 2011 at 11:22 AM, Viviane Pons p...@univ-mlv.fr wrote: The sage-combinat install did not work well, it seems that you need an hg username, but I thought that was not needed for the install itself, can anyone clarify ? It should no longer be necessary for the installation, but it might still be necessary for updating. Replying to myself: I already fixed the problem, and the fix will be in the next sage release (4.7.1); see #11296 for more information. Franco -- -- 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.
Re: [sage-combinat-devel] Missing patch
On Mon, Jul 4, 2011 at 10:49 AM, Anne Schilling a...@math.ucdavis.edu wrote:
In any case, some of Nicolas' patches do not apply right now. I tried to
disable
them, but then one needs to disable half of the queue as a consequence (also
some of Christian Stump's patches). He is on holidays right now, so you will
have
to wait until he is back, or Viviane could move her patches up in the queue.
I took a quick look at the rejection and it is a very minor change
(one line) to the Crystals category. All the other patches apply if we
ignore this rejection, so we just need to fix this one.
The rejection is below. It seems that we need to just add back the
line with the LazyImport, which defines the Finite attribute for the
category. Since you are familiar with the Crystals code, can you
confirm that this is the correct fix?
--- crystals.py
+++ crystals.py
@@ -1184,3 +1185,5 @@ class Crystals(Category):
self = self.f(i)
return self.to_lowest_weight(list = list + [i],
index_set = index_set)
return [self, list]
+
+Finite = LazyImport('sage.categories.finite_crystals', 'FiniteCrystals')
--
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.
Re: [sage-combinat-devel] Missing patch
On Mon, Jul 4, 2011 at 11:56 AM, Anne Schilling a...@math.ucdavis.edu wrote:
Hi Franco!
On 7/4/11 8:12 AM, Franco Saliola wrote:
On Mon, Jul 4, 2011 at 10:49 AM, Anne Schillinga...@math.ucdavis.edu
wrote:
In any case, some of Nicolas' patches do not apply right now. I tried to
disable
them, but then one needs to disable half of the queue as a consequence
(also
some of Christian Stump's patches). He is on holidays right now, so you
will
have
to wait until he is back, or Viviane could move her patches up in the
queue.
I took a quick look at the rejection and it is a very minor change
(one line) to the Crystals category. All the other patches apply if we
ignore this rejection, so we just need to fix this one.
The rejection is below. It seems that we need to just add back the
line with the LazyImport, which defines the Finite attribute for the
category. Since you are familiar with the Crystals code, can you
confirm that this is the correct fix?
--- crystals.py
+++ crystals.py
@@ -1184,3 +1185,5 @@ class Crystals(Category):
self = self.f(i)
return self.to_lowest_weight(list = list + [i],
index_set = index_set)
return [self, list]
+
+ Finite = LazyImport('sage.categories.finite_crystals',
'FiniteCrystals')
I get the same rejection and YES, this seems like the correct line for the
Finite attribute in the crystal category.
Will you go ahead and fix this, or do you want me to do so?
I'll do it. I'll write back in a few minutes once it's done.
Franco
--
--
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.
Re: [sage-combinat-devel] Missing patch
On Mon, Jul 4, 2011 at 12:35 PM, Franco Saliola sali...@gmail.com wrote:
On Mon, Jul 4, 2011 at 11:56 AM, Anne Schilling a...@math.ucdavis.edu wrote:
Hi Franco!
On 7/4/11 8:12 AM, Franco Saliola wrote:
On Mon, Jul 4, 2011 at 10:49 AM, Anne Schillinga...@math.ucdavis.edu
wrote:
In any case, some of Nicolas' patches do not apply right now. I tried to
disable
them, but then one needs to disable half of the queue as a consequence
(also
some of Christian Stump's patches). He is on holidays right now, so you
will
have
to wait until he is back, or Viviane could move her patches up in the
queue.
I took a quick look at the rejection and it is a very minor change
(one line) to the Crystals category. All the other patches apply if we
ignore this rejection, so we just need to fix this one.
The rejection is below. It seems that we need to just add back the
line with the LazyImport, which defines the Finite attribute for the
category. Since you are familiar with the Crystals code, can you
confirm that this is the correct fix?
--- crystals.py
+++ crystals.py
@@ -1184,3 +1185,5 @@ class Crystals(Category):
self = self.f(i)
return self.to_lowest_weight(list = list + [i],
index_set = index_set)
return [self, list]
+
+ Finite = LazyImport('sage.categories.finite_crystals',
'FiniteCrystals')
I get the same rejection and YES, this seems like the correct line for the
Finite attribute in the crystal category.
Will you go ahead and fix this, or do you want me to do so?
I'll do it. I'll write back in a few minutes once it's done.
I think it is fixed now. Give it a try and let me know that it works.
By the way, without that line defining Finite, there are 184 doctest
failures in the Crystals category; with that line all doctests pass
(including the doctests in the sage/combinat/crystals files).
Franco
--
--
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.
Re: [sage-combinat-devel] Re: [sage-devel] Call for vote: lrcalc as standard or optional spkg?
On Tue, Jun 28, 2011 at 11:04 AM, Florent Hivert florent.hiv...@univ-rouen.fr wrote: Hi, With Mike and Anne we are about to finalize an interface with lrcalc: -- #10333: An interface to Anders Buch's Littlewood-Richardson Calculator lrcalc The Littlewood-Richardson Calculator is a C library for fast computation of Littlewood-Richardson (LR) coefficients and products of Schubert polynomials. It handles single LR coefficients, products of and coproducts of Schur functions, skew Schur functions, and fusion products. All of the above are achieved by counting LR (skew)-tableaux of appropriate shape and content by iterating through them. Additionally, lrcalc handles products of Schubert polynomials. The web page of lrcalc is: http://math.rutgers.edu/~asbuch/lrcalc/ -- lrcalc weights 500Ko (100Ko of C code + administrative files + mercurial repo). It's GLPV2+ with no dependencies. The code is quite clean and so far proved to be portable: we used it in MuPAD-Combinat, under MacOS, various flavors of Linux, and CYGWIN; tests on solaris are welcome! One more argument for using it. Having it in standard Sage is a good step toward getting rid of Symmetrica which often causes problems and is no more maintained. lrcalc will progressively become a key low-level component for Sage's symmetric functions library. This evolution will be simpler if lrcalc is always available. I therefore would like to cast a vote. Should lrcalc become: Therefore: [X] A standard spkg [ ] An optional spkg [X] A standard spkg Franco -- -- 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.
Re: [sage-combinat-devel] Backward incompatible change for BinaryTree
On Mon, Jun 13, 2011 at 7:03 AM, Florent Hivert florent.hiv...@univ-rouen.fr wrote: So I'd like to have a vote for either one of those four options: 1. unimport BinaryTree from sage.misc.sage_ds and import them from combinat 2. leave think as such. Find a different name for the mathematical binary trees (eg: BinaryTreesCombinatorial). 3. rename BinaryTree from sage.misc.sage_ds (eg: BinaryTreesDataStructure) and import BinaryTree from combinat 4. something else ? 1 or 3, and mention in the documentation for BinaryTree (the combinatorial one) that sage.misc.sage_ds.BinaryTree exists, and that they are better suited for ... (like what you wrote in your follow-up email). Franco -- -- 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.
Re: [sage-combinat-devel] Monoid Algebras
On Thu, May 12, 2011 at 3:07 AM, Bruce brucewestb...@gmail.com wrote: and I expected AlgebrasWithFiniteBasis as well. See FiniteDimensionalAlgebrasWithBasis. Franco -- -- 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.
Re: [sage-combinat-devel] Monoid Algebras
On Wed, May 11, 2011 at 7:23 AM, Bruce brucewestb...@gmail.com wrote: What I now understand and I assume no-one actually said as it is too obvious (or maybe I was told and did not get it) is: To implement a new monoid I define a new class which inherits from Parent. The class definition has to include the line Parent.__init__(self,category=Monoids()) I don't think it is too obvious. Let me add the following, which may not help, but it is the way that I like to think about these things. There are two types of inheritance going on here: one mathematical; and one technical (the data type). The mathematical inheritance is via the category theory framework, as you did above by initializing with category=Monoids(). The other is the data structure, which in your example above is Parent. Note that it is possible to use other data types instead. For example, in order to implement a monoid algebra directly (without first implementing the monoid itself), you can use CombinatorialFreeModule. Then I also have to implement class methods which are listed by Monoids.ParentMethods Only the required ones, which *should* be marked by @abstract_method. I think there is a way to ask which methods are required, but I don't remember how. You can also implement methods for the elements in the attribute Element of your class (which is a class). See the examples in examples/semigroup.py. Then reading these files I have some further questions: What is the rationale for Family? I think the main rationale for Family is to provide a consistent interface for objects that model containers, regardless of the datatype used (list, dictionary, enumerated set, etc.). and what is ElementWrapper all about? Perhaps an example is best. Suppose your monoid elements are naturally described by strings. But strings do not have any knowledge about the monoid, so you can't write str1 * str2 in order to compute their product in the monoid. Essentially, by using ElementWrapper, you endow the object with information about its parent. (Technically, it is a new object that stores the original object in the attribute .value. It inherits methods via the category theory framework or through regular class inheritance.) I hope this helps. Franco -- -- 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] import error in patch queue
Hello everyone. I get an import error after I qpush the Nil-Coxeter algebra patch. Chris: in your latest push you deleted the file nil_coxeter.py, but I imagine you meant to rename it to nil_coxeter_algebra.py ? Did you make any other modifications besides the renaming ? Franco -- -- 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: import error in patch queue
On Sat, May 7, 2011 at 3:09 PM, Franco Saliola sali...@gmail.com wrote: I get an import error after I qpush the Nil-Coxeter algebra patch. There is another problem with the patch queue. I tried disabling Chris's patch, but then there was a failure in Christian's patch: applying trac_11187-finite_reflection_groups-cs.patch patching file sage/rings/universal_cyclotomic_field/universal_cyclotomic_field.py Hunk #1 FAILED at 817 1 out of 1 hunks FAILED -- saving rejects to file sage/rings/universal_cyclotomic_field/universal_cyclotomic_field.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_11187-finite_reflection_groups-cs.patch What is the policy here ? I can disable the offending patches so that the patch queue is guaranteed to work. I will need to disable 4 patches because some later patches don't apply cleanly either. -- -- 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.
Re: [sage-combinat-devel] combinat install failed with sage-4.7.rc1
On Wed, May 4, 2011 at 11:11 PM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Bonjour Samuel! On Wed, May 04, 2011 at 08:41:45PM +0200, slelievre wrote: I helped a colleague install sage (version 4.7.rc1) and told him to run sage -combinat install The combinat install failed, here are the last few lines that were printed as it was installing. applying sage-4.7.1.patch patch sage-4.7.1.patch is empty transaction abort! rollback completed cleaning up working directory...done abort: no username supplied (see hg help config) Abort Is this because combinat is not ready for 4.7.rc1 yet? The patches should apply fine on 4.7.rc1 (modulo a bunch that need to be rebased, but are guarded out). Or does it mean he should first create a .hgrc file? In principle, a .hgrc file should not be needed. But I have had other similar reports. Investigating a bit further, it seems that hg can't apply an empty patch if it is not given a user name: zephyr-~mkdir blah zephyr-~cd blah zephyr-~/blahhg init zephyr-~/blahhg import ~sp/sage-4.7.1.patch application de /opt/sage/devel/sage-combinat/.hg/patches/sage-4.7.1.patch abandon : no diffs found zephyr-~/blahhg qimport ~sp/sage-4.7.1.patch ajout de sage-4.7.1.patch à la liste de patchs (fichier series) zephyr-~/blahhg qpush application de sage-4.7.1.patch le patch sage-4.7.1.patch est vide nettoyage du répertoire de travail...effectué abandon : no username supplied (see hg help config) Yikes, yet another empty bug! We should report this to mercurial. Franco is going to work aroung this in the Sage-Combinat script. Patch ready for review at: http://trac.sagemath.org/sage_trac/ticket/11296 Franco -- -- 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.
Re: [sage-combinat-devel] Re: LACIM + GASCOM
- Lastly, from memory, among the developpers, there will be Sébastien, Vincent, Franco (not sure about him), Christian (Stump), you and I. I will definitely be there! Franco -- -- 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] Re: an example of a graded algebra with basis
On Thu, Jun 24, 2010 at 6:40 PM, Nicolas M. Thiery
nicolas.thi...@u-psud.fr wrote:
On Thu, Jun 24, 2010 at 01:00:44PM -0700, John H Palmieri wrote:
What about two methods, degree and max_degree? (The second being
defined only when the indexing set is naturally ordered.)
I'd be happy with that. Then depending on the situation, people could
set degree equal to max_degree or have them be distinct.
It's interesting to see how different use cases we can have :-)
I can go with the above as a starter. Most likely we will set degree =
max_degree quite often, and when we will have a precise idea of the
perimeter of the use cases, we will put this in an appropriate
category.
Great. That's settled. Both degree and max_degree.
In principle this is fine, but I'm sure I've seen situations where
it's zero. Here's a sort of stupid situation:
sage: A = GradedAlgebrasWithBasis(QQ).example(generators=(x, y),
degrees=(2, 3))
sage: a = A.term((2,3), 0)
sage: a.monomial_coefficients()
{(2, 3): 0}
- d[mono] should be an element of R, so you don't need to coerce it into R.
Well, a method like term(tuple, coeff) doesn't coerce coeff to be in
R: if I work over GF(2) instead of QQ, then a = A.term((2,3), 12)
should equal zero (although it doesn't) and it should be ignored when
computing degrees. I suppose this is a mistake by the user (me),
since the documentation for term says that the coefficient should be
in the base ring, but still.
For this example code, I'd rather have the code be overly careful at
the expense of being efficient.
This is a huge bug. This is the datatype, so we can assume it meets its
specifications (that the coefficients are all non-zero and all belong to
the ring). Otherwise, the code will get cumbersome with checks of
coefficients being non-zero and ring containment, not to mention the
redundancy in checking the coefficients repeatedly. The element
construction mechanism should take care of this once and for all (and it
should have an option to bypass these checks).
Here is another bad example:
sage: s = SFASchur(ZZ)
sage: a = s._from_dict({Partition([1]):0})
sage: a
0
sage: dict(a)
{[1]: 0}
sage: a = s.element_class(s,{Partition([1]):1/2})
sage: a
1/2*s[1]
In light of this, I understand John's apprehension to avoid coercing and
checking of coefficients, but I maintain this is a bug. Do others agree?
Should I open a ticket?
Ok, we should document that passing 0 as coeff is an abuse of
A.term. And there probably should be an assertion check in A.term (as
well as for the requirement of the coeff to be in the base ring).
+1 for the assertion check in A.term.
- It is more efficient to check the degree of a monomial as soon as you
compute it rather than computing them all and then comparing. Here is
some code that does this.
monomials = self.monomial_coefficients().keys()
if monomials:
deg = self.parent().degree_on_basis
d = deg(monomials.pop())
return all(deg(mono)==d for mono in monomials)
else:
return True
I really should mark monomial_coefficients() to be deprecated in favor
of iteration and other accessors.
for (i, c) in self: ...
I didn't know about this! Cool.
The code above also has the inconvenient to force a copy of the list
of indices (in particular because of the write access). The following
variant leaves the door (in a future optimized implementation of
FreeModules) to run through the indices in-place:
degree = None
deg = self.parent().degree_on_basis()
for i in self.support():
if degree is None:
degree = deg(i)
elif deg(i) != degree:
return False
return True
I chose self.monomial_coefficients().keys() over self.support() because the
later returned a sorted list and in this case we don't care about sorting.
Again, this is generic code that should be lifted. Perhaps we should start
working on this lifting. Do we need a GradedCombinatorialFreeModule? or
does this belong to some category? probably both?
I think that the category GradedModuleWithBasis would seem like a
natural place to start, but other people know this part of the Sage
library a lot better than I do.
This definitely belongs to
GradedModuleWithBasis. (Combinatorial)FreeModule is really just a
specific (but useful!) implementation of the data structure and very
low level accessors for free module and their elements.
If someone else wants to start working on the lifting, please cc me
(jhpalmieri) on any relevant tickets. I don't think I'll be working
on it soon.
If no one beats me to review this ticket, I'll do that in my
reviewer's patch. But that won't be before about two weeks ...
I volunteer to review the reviewer's patch.
Franco
--
--
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] Re: [sage-algebra] Re: an example of a graded algebra with basis
On Thu, Jun 24, 2010 at 12:31 PM, John H Palmieri jhpalmier...@gmail.com wrote: 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. What about two methods, degree and max_degree? (The second being defined only when the indexing set is naturally ordered.) - 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 I've taken a quick look, and have some comments on your code for is_homogenous: R = self.base_ring() d = self.monomial_coefficients() if len(d) == 0: return True deg_list = [self.parent().degree_on_basis(mono) for mono in d if R(d[mono]) != 0] return max(deg_list) == min(deg_list) - d[mono] should never, ever, be 0, so you can safely remove that check. - d[mono] should be an element of R, so you don't need to coerce it into R. - It is more efficient to check the degree of a monomial as soon as you compute it rather than computing them all and then comparing. Here is some code that does this. monomials = self.monomial_coefficients().keys() if monomials: deg = self.parent().degree_on_basis d = deg(monomials.pop()) return all(deg(mono)==d for mono in monomials) else: return True Again, this is generic code that should be lifted. Perhaps we should start working on this lifting. Do we need a GradedCombinatorialFreeModule? or does this belong to some category? probably both? Franco -- -- 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.
Re: [sage-combinat-devel] Re: un bug ?
2010/6/9 Florent Hivert florent.hiv...@univ-rouen.fr: Hi Frédéric, dans les fonctions symetriques p([m/n]) ne marche pas, quand n est un diviseur de m.. par exemple, p([2/1]) devrait retourner p([2]).. Actually the problem in not a problem of symmetric functions but a problem in partitions: sage: Partition([2/1]) ... ValueError: [2] is not a valid partition This is because 2/1 does not belongs to the ring of integer but to the field of rational numbers: sage: (2/1).parent() Rational Field Actually, it does belong to the ring of integers: sage: 2/1 in ZZ True What would be the meaning of sage: Partition([5 / 2]) ... ValueError: [5/2] is not a valid partition This could be surprising but I'm bot sure it is a bug. I think there is a bug. We should decide either to accept only Integers or to coerce to Integer. Right now it is not consistent: Partition accepts ints and Integers and ignores anything Python-equal to 0: sage: s = SFASchur(QQ) sage: p = Partition([Integer(2), int(1), QQ(0), s.zero(), matrix()]) sage: p [2, 1] Note that the output is a mix of ints and Integers! sage: map(type, p) [type 'sage.rings.integer.Integer', type 'int'] I think there is no need to explain why this causes lots of trouble. Either way, the error message should be more descriptive. It would explain why [2/1] is not a valid partition. Franco -- -- 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] errors in the queue
The following patches do not apply cleanly against sage-4.4.3. hg qpush -a ... errors during apply, please fix and refresh trac_8490_review-sl.patch errors during apply, please fix and refresh categories-tutorial.patch errors during apply, please fix and refresh trac_9065-facade_parents-nt.patch errors during apply, please fix and refresh trac_7980-multiple-realizations-nt.patch errors during apply, please fix and refresh trac_8933-subquotient_module_with_basis-fh.patch errors during apply, please fix and refresh finite_semigroup-nt.patch errors during apply, please fix and refresh trac_8589_feature_group_algebras_vf.patch Is anyone else experiencing this? Franco -- -- 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.
Re: [sage-combinat-devel] errors in the queue
Thanks for the quick replies, Anne and Nicolas! I decided to scrap my branch and start again from scratch. No problems with the queue now, but I am having the same problem that laurent reported in another thread. I'll go post to that thread now. Franco -- On Thu, Jun 10, 2010 at 2:07 PM, Anne Schilling a...@math.ucdavis.edu wrote: Franco Saliola wrote: The following patches do not apply cleanly against sage-4.4.3. hg qpush -a ... errors during apply, please fix and refresh trac_8490_review-sl.patch errors during apply, please fix and refresh categories-tutorial.patch errors during apply, please fix and refresh trac_9065-facade_parents-nt.patch errors during apply, please fix and refresh trac_7980-multiple-realizations-nt.patch errors during apply, please fix and refresh trac_8933-subquotient_module_with_basis-fh.patch errors during apply, please fix and refresh finite_semigroup-nt.patch errors during apply, please fix and refresh trac_8589_feature_group_algebras_vf.patch Is anyone else experiencing this? For me everything works with sage-4.4.3 (which I just installed last night). Anne -- 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. -- 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.
Re: [sage-combinat-devel] Error while installing sage/combinat
On Thu, Jun 10, 2010 at 7:56 AM, laurent bobelin laurent.bobe...@gmail.com wrote: Hi, I'm not pretty sure that's the good mailing list to post this mail to. First, I'm absolutely new to sage and combinat (I've installed sage in order to use the later). So, I went for the whole process yesterday, got the sources, compiled it all, did the sage -combinat install, then tried to got sage tutorial example to work. Command-line interface was whining when I started it, because the stuff was trying to import some python file (namely generation_list_upto_permgroup.py) and each time I was typing in a command it was answering me that Integer was unknown (or something like this). Notebook node was not whining at start up but did the 'integer ? what's this ? thing as well as command-line did. Command line told me to try a %upgrade, but it failed (well, %upgrade went nicely, but did not solved my problem). I get the same error on a fresh install of sage-4.4.3. That file is in a directory created by the patch invariant_ring_permutation_group-nb.patch So I suspect that NB forgot to do an 'hg add' on that file. Franco -- -- 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-Coxeter
2009/11/8 Nicolas M. Thiery nicolas.thi...@u-psud.fr: Dear Sage-Combinat and root system developers, Some good news: Christophe Hohlweg and a student of him are going to join us for more root system fun (porting Christophe's Cambrian code)! Welcome aboard, Christophe. ;-) -- --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
