Re: [sage-combinat-devel] queue broken
Hi! There is a break in sage between patch trac_12895-subcategory-methods-nt.patch trac_8327_universal_cyclotomic_field-cs.patch fixed -- it was actually Mark closing the last link for the import loop by importing from sage.graphs.digraph import DiGraph in categories/weyl_groups. I updated his patch accordingly (Mark, please pull my changes before changing your patch!). I still don't know how to properly do the importing. E.g., here we have ... -- 243 from sage.combinat.free_module import CombinatorialFreeModule ... --- 28 from sage.categories.all import ModulesWithBasis ... -- 126 from weyl_groups import WeylGroups 127 from finite_weyl_groups import FiniteWeylGroups 128 from affine_weyl_groups import AffineWeylGroups why does something low level like combinatorial free module or modules with basis import weyl groups ? Or are categories always considered to be lower ? 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.
Re: [sage-combinat-devel] queue broken
Hi, unfortunately, the queue is still broken at trac_12940_affine_permutations-td.patch. 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.
[sage-combinat-devel] NCSF / affine permutation patches
Hi Chris, Tom, Apparently, NCSF code got accidently qrefreshed in trac_12940_affine_permutations-td.patch, causing the latter to not apply anymore. I temporarily disabled it. Chris, I guess you can simply cut the relevant hunks out of Tom's patch, and check that you already have all the changes in your patches. 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 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
On Mon, May 21, 2012 at 09:32:02AM +0200, Christian Stump wrote: Or are categories always considered to be lower ? Taken from: http://groups.google.com/group/sage-combinat-devel/msg/15221ad8016af193 (which btw should be discussed on sage-devel and put in the dev manual) -- To avoid import loops, I try to stick to the following order: - Python modules - Misc - Categories - Stuff in sage.structure - Basic parents (NN, QQ, ...) - Rest of the stuff and a module in one of the above items should only import modules from higher items. E.g. a module in sage.categories can import from a module in sage.misc, but not reciprocally. -- According to the above rules, a category file should not import stuff like DiGraph or CombinatorialFreeModule (but that's ok within its methods, or using lazy imports). why does something low level like combinatorial free module or modules with basis import weyl groups ? That's because of the all in: from sage.categories.all import ModulesWithBasis Given the above rules, it's in principle ok for combinatorial free module to import all categories. However, for extra safety, it would indeed be better to use from sage.categories.modules_with_basis. 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 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
On Mon, May 21, 2012 at 09:36:57AM +0200, Christian Stump wrote: unfortunately, the queue is still broken at trac_12940_affine_permutations-td.patch. Fixed. See other thread (NCSF/trac_12940_affine_permutations-td.patch) 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 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
Fixed. See other thread (NCSF/trac_12940_affine_permutations-td.patch) thx, but don't forget to push, please! -- 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] Positive roots by heights and TransitiveIdealGraded
Hi Christian, In CC: Vivien, Jean-Philippe, By the way: positive_roots_by_height would be best implemented by adding this feature into TransitiveIdealGraded. Ideally, one could do: for x in H.positive_roots().subset(grade=3): Or at least, in the short run, and consistently with SearchForest: for x in H.positive_roots().elements_of_depth_iterator(3): In general, TransitiveIdeal and friends would need some love. Please create a ticket about it. PS: I discussed on Friday with Vivien Ripoll, and they need precisely this feature for positive roots in their project with Jean-Philippe Labbé. You might want to team up with the later, since you are both in Berlin, right? 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 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] root lattice realizations and Weyl groups
On Sun, May 20, 2012 at 01:48:30PM -0700, Anne Schilling wrote: Mark just pushed a patch (coxeter-ms.patch) which is in conflict with your patch applying trac_12882-generalized_cartan_matrix_as_dynkin_diagram_input-cs.patch applying trac_11187-finite_reflection_groups-cs.patch In such case, you might want next time to disable one of the two patches, to avoid breaking the queue for others for a non trivial amount of time. 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 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
2012/5/20, Nicolas M. Thiery nicolas.thi...@u-psud.fr:
On Sun, May 20, 2012 at 11:07:16AM +0200, Vincent Delecroix wrote:
Hello,
On Fri, May 18, 2012 at 07:36:51AM -0700, Frédéric Chapoton wrote:
trying to test my own files on sage 5.0, it seems that it takes many
import statements. Some of them behave strangely :
sage: import_statements(euler_phi)
from sage.rings.arith import Number of positive integers =n but
relatively prime to n
sage: import_statements(QQ)
from sage.rings.rational_field import Rational Field
Now with import_statements-vd.patch applied
{{{
sage: import_statements(euler_phi)
from sage.rings.arith import euler_phi
sage: import_statements(QQ)
from sage.all import QQ
}}}
The hack is very weak (uses find and grep from the shell) but mainly
works. Feel free to improve.
Thanks!
Now that I think about it, here is a variant to recover the name under
which the object is stored in its module:
sage: module = sys.modules[euler_phi.__module__]
sage: [key for key in module.__dict__ if module.__dict__[key] ==
euler_phi]
['euler_phi']
Of course it's not robust if the object has an alias in this
module. And if the object is stored in a module while its class is
defined in a different module.
In particular
sage: sage: module = sys.modules[ZZ.__module__]
sage: [key for key in module.__dict__ if module.__dict__[key] == ZZ]
[]
Do the following is more safe?
1) treat the case of the object being a module itself
2) try to see if the object is defined in the same module as its
class (what Nicolas suggested)
3) make a lazy search using globals() and find/grep (what I wrote in the patch)
the case of euler_phi is done with 2) while the case of ZZ is done
with 3). Remains the problems of aliases... any concrete example?
Vincent
--
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
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. 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 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] import statement strange behaviour
Dear all, I push a last version of import_statements. Use it and break it... (good luck :-) 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? 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 +1 Cheers, Vincent -- 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] bug in poset
Hi! Isn't the following a big bug in posets in sage: sage: P = Poset(([1,2,3,4],[[1,4],[2,3],[3,4]]), facade = True) sage: P.is_graded() False The definition of grading is that all maximal chains of every interval have the same length. This is given in the above poset, but sage says it is not graded. How should this be fixed? Cheers, 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-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
The definition of grading is that all maximal chains of every interval have the same length. This is given in the above poset, but sage says it is not graded. The problem here is what people consider a rank function on a poset. Do we want that all minimal elements have value 0 ? Then your poset is indeed not graded. Or do we only want that some element has value 0 ? Then your poset is graded. But if we take the later, what are then the levels of a poset? Are all minimal elements in level 0 (which seems to me like a good choice), or are the levels given by your grading? I think you're right since the existence of a rank function seems to be common sense as the definition (http://en.wikipedia.org/wiki/Graded_poset) (this is equivalent to your definition for locally finite posets). But then, we have to make a choice for the levels of a poset. My 2 cents, 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.
Re: [sage-combinat-devel] bug in poset
On 5/21/12 8:11 AM, Christian Stump wrote: The definition of grading is that all maximal chains of every interval have the same length. This is given in the above poset, but sage says it is not graded. The problem here is what people consider a rank function on a poset. Do we want that all minimal elements have value 0 ? No. I think this is not the correct definition. Then why not maximal element? It does not seem like a sensible definition. I agree that the algorithm to compute the rank function might not be so nice any longer, but that should not be a reason to use the wrong definition. Then your poset is indeed not graded. Or do we only want that some element has value 0 ? Yes, some element has rank 0. Or in fact all that I care about is that if y covers x then (*) rank(y) = rank(x)+1. The normalization is not that important. Then your poset is graded. But if we take the later, what are then the levels of a poset? Are all minimal elements in level 0 (which seems to me like a good choice), or are the levels given by your grading? The grading is defined by (*). If the poset is connected, then this completely fixes the rank function up to an overall additive constant. If there are disconnected components, one may want to use a particular convention for the additive constant. I think you're right since the existence of a rank function seems to be common sense as the definition (http://en.wikipedia.org/wiki/Graded_poset) (this is equivalent to your definition for locally finite posets). But then, we have to make a choice for the levels of a poset. My 2 cents, Christian Best, 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-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
Hi Anne,
Isn't the following a big bug in posets in sage:
sage: P = Poset(([1,2,3,4],[[1,4],[2,3],[3,4]]), facade = True)
sage: P.is_graded()
False
The definition of grading is that all maximal chains of every interval
have the same length. This is given in the above poset, but sage says
it is not graded.
The code seems to assume that the poset has a least element. It uses
the level_sets() function of sage/graphs/digraph.py to compute the
level sets of the Hasse diagram of the poset; then it assumes that the
0-th level set (i. e., the set of vertices having no predecessor) must
be the 0-th rank of the grading, that the 1-st level set (i. e., the
set of vertices having all their predecessors in the 0-th level set
but not lying therein themselves) must be the 1-th rank, that the 2-nd
level set (i. e., the set of vertices having all their predecessors in
the =1-st level sets but not lying therein themselves) must be the
2-nd rank, etc. In the case of your P, the 0-th level set is {1,2},
and then we get a rank mismatch at vertex 4.
How should this be fixed?
I am wondering about that too. My first idea would be Gaussian
elimination, with each covering relation (P.cover_relations()) giving
an equation of the form a_i - a_j = 1. Not sure this is anywhere near
optimal, though. The nice thing about systems of linear equations with
every equation containing only 2 nonzero coefficients is that, if you
perform Gaussian elimination on such a system, it retains this
property (that every equation has only 2 nonzero coefficients) all the
way through (this is even true for Gröbner basis, keyword binomial
basis IIRC), so it is a very sparse-matrix problem, but I don't know
whether Sage has any code optimized for this case.
Best regards, and sorry if this was all known already,
Darij
--
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] cartan_matrix conventions
Hi Hugh,
If you want to add documentation stating which precise conventions are used, I
think that
is a good idea. At this point I would not change the convention, especially
since it is
possible to relabel the vertices as well in sage.
Best,
Anne
On 5/21/12 8:07 AM, Hugh Thomas wrote:
Hi!
Nicolas suggested that I bring to the list a discussion which he, Christian,
and I were having.
I was looking at Cartan matrices, and noticed that
sage: CartanType('B',4).cartan_matrix()
gives you
[ 2 -1 0 0]
[-1 2 -1 0]
[ 0 -1 2 -1]
[ 0 0 -2 2]
and if you look in your handy copy of Bourbaki's Lie Groups and Lie
Algebras, you see that this is transposed compared to what he tells you.
So, I was going to write a message to the list complaining about that, but
then I investigated a little bit further. It turns out there are two
conventions for Cartan matrices, the Bourbaki
convention, and the Kac/Fulton-Harris/Fomin-Zelevinsky/us convention, and the
two conventions are transposed with respect to each other.
This is not really a problem, but I think it would be good to include a
precise statement of what our convention is in the documentation for the
cartan_type method. And I guess, in order to do that,
it would be for the best to be sure that I actually have correctly understood
the situation. So if anything I said seems fishy, please jump in.
Also, I guess it's worth mentioning that while looking into this, I also
found that the twisted affine type naming conventions differed in a couple of
respects from what's on Wikipedia at
http://en.wikipedia.org/wiki/Dynkin_diagram#Affine_Dynkin_diagrams However, I
think that's just because Wikipedia was wrong (gasp!). I made one change
there, and left a note on the talk page about
the other necessary change. So I don't think this is anything we need to
worry about further. (Though, again, if you're interested, and what I said
seems wrong, please let me know.) A good
reference for the twisted diagrams is Kac's infinite dimensional Lie
algebras, p. 55, which you can preview on Google Books.
cheers,
Hugh
--
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/-/EMRjKhrzAzoJ.
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.
--
Anne Schilling E-mail: a...@math.ucdavis.edu
Professor Web:http://www.math.ucdavis.edu/~anne
Department of Mathematics Office: MSB 3222
University of CaliforniaPhone: (530) 554 2326
One Shields Ave Fax:(530) 752 6635
Davis, CA 95616
--
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
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. Chris On Mon, May 21, 2012 at 3:40 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi Chris, Tom, Apparently, NCSF code got accidently qrefreshed in trac_12940_affine_permutations-td.patch, causing the latter to not apply anymore. I temporarily disabled it. Chris, I guess you can simply cut the relevant hunks out of Tom's patch, and check that you already have all the changes in your patches. 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 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] 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] bug in poset
On 5/21/12 8:09 AM, Darij Grinberg wrote:
Hi Anne,
Isn't the following a big bug in posets in sage:
sage: P = Poset(([1,2,3,4],[[1,4],[2,3],[3,4]]), facade = True)
sage: P.is_graded()
False
The definition of grading is that all maximal chains of every interval
have the same length. This is given in the above poset, but sage says
it is not graded.
The code seems to assume that the poset has a least element. It uses
the level_sets() function of sage/graphs/digraph.py to compute the
level sets of the Hasse diagram of the poset; then it assumes that the
0-th level set (i. e., the set of vertices having no predecessor) must
be the 0-th rank of the grading, that the 1-st level set (i. e., the
set of vertices having all their predecessors in the 0-th level set
but not lying therein themselves) must be the 1-th rank, that the 2-nd
level set (i. e., the set of vertices having all their predecessors in
the =1-st level sets but not lying therein themselves) must be the
2-nd rank, etc. In the case of your P, the 0-th level set is {1,2},
and then we get a rank mismatch at vertex 4.
How should this be fixed?
I am wondering about that too. My first idea would be Gaussian
elimination, with each covering relation (P.cover_relations()) giving
an equation of the form a_i - a_j = 1. Not sure this is anywhere near
optimal, though. The nice thing about systems of linear equations with
every equation containing only 2 nonzero coefficients is that, if you
perform Gaussian elimination on such a system, it retains this
property (that every equation has only 2 nonzero coefficients) all the
way through (this is even true for Gröbner basis, keyword binomial
basis IIRC), so it is a very sparse-matrix problem, but I don't know
whether Sage has any code optimized for this case.
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.
Darij, do you think you can implement this?
Best,
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-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
When there are several names, I think we should return the one that agrees with the name that was given by the user. I really don't know how we can obtain the name used inside the function. We should somewhat access the stack of calls of the console (as the calls import_statement(CachedFunction) and import_statements(cached_function) are semantically the same). What you would expect from the following non-examples sage: z_not_ZZ = ZZ sage: import_statements(z_not_ZZ) and the trickier sage: import_statements(1) and the even trickier sage: f = lambda x: return cached_function sage: import_statements(f()) 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 We can add an exception for it (and even remove sage.all from the list of modules ?). But then, why is there ZZ = IntegerRing() in the file all.py? Simply removing sage.all from the available modules leads to sage: import_statements(ZZ) from sage.coding.linear_code import ZZ More generally, there are many files where it is written ZZ = IntegerRing(). I think this should be avoided. Are there some coding coventions about instanciations within modules? Best, Vincent -- 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
On 5/21/12 12:52 AM, Nicolas M. Thiery wrote: On Mon, May 21, 2012 at 09:32:02AM +0200, Christian Stump wrote: Or are categories always considered to be lower ? Taken from: http://groups.google.com/group/sage-combinat-devel/msg/15221ad8016af193 (which btw should be discussed on sage-devel and put in the dev manual) -- To avoid import loops, I try to stick to the following order: - Python modules - Misc - Categories - Stuff in sage.structure - Basic parents (NN, QQ, ...) - Rest of the stuff and a module in one of the above items should only import modules from higher items. E.g. a module in sage.categories can import from a module in sage.misc, but not reciprocally. -- Is this a rule for the import statements at the beginning of the file? I am currently implementing an __iter__ method for the category of Crystals. But without any further import statements, I get an import loop just by adding this method. How can I debug this? Cheers, 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-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: Permutations and trac ticket #8392
I don't really know; you probably want to ask on sage-devel. Will do. Thanks. Now to properly separate out the generalized permutations / two-line array / biwords, I'm thinking of creating two new classes. The first I'd call TwoLineArray which inherits from CombinatorialObject which takes/holds a pair of lists as in Stanley. Perhaps it would be better to call this Biword and inherit from Word (or whatever the appropriate class might be)? The second I'd call GeneralizedPermutation_class which inherits from CombinatorialObject and hold a single list of integers, then I'd have Permutation_class inherit from here. The reason being is that this would now prevent the user from doing operations that require honest permutation (i.e. with no repeats). I'd want these two separate classes because the GeneralizedPermutation_class would just have an implied [1, 2, ...,n] as the top array and we wouldn't need to store about this. Thanks, Travis -- 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/-/5SJ_Fu4Va4IJ. 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
On Mon, May 21, 2012 at 01:24:38PM -0700, Anne Schilling wrote: On 5/21/12 12:52 AM, Nicolas M. Thiery wrote: -- To avoid import loops, I try to stick to the following order: - Python modules - Misc - Categories - Stuff in sage.structure - Basic parents (NN, QQ, ...) - Rest of the stuff and a module in one of the above items should only import modules from higher items. E.g. a module in sage.categories can import from a module in sage.misc, but not reciprocally. -- Is this a rule for the import statements at the beginning of the file? Yes. Well, that's the rule I follow myself, and would tend to recommend. I guess it's time to open the debate about this on sage-devel (though I won't be able to do it before I come back from China). I am currently implementing an __iter__ method for the category of Crystals. But without any further import statements, I get an import loop just by adding this method. This should not occur. Make sure that this really is the only change. How can I debug this? Usually the traceback is quite informative on which module import which. Then you have to figure out where it's most natural to break the loop. 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 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] Littelmann path crystals
Hi! Mark Shimozono and I are cross refereeing the Littelmann path patch for crystals which is currently in the sage-combinat queue trac_12251-littelmann-as.patch If you have any comments, please let us know. Otherwise, it will hopefully go into sage soon. Best, 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-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
Hi, On Mon, May 21, 2012 at 10:12:16PM +0200, Vincent Delecroix wrote: When there are several names, I think we should return the one that agrees with the name that was given by the user. I really don't know how we can obtain the name used inside the function. We should somewhat access the stack of calls of the console (as the calls import_statement(CachedFunction) and import_statements(cached_function) are semantically the same). What you would expect from the following non-examples I don't have time to investigate nor to read the full discussion... So I'm just trowing some random idea hoping this helps. Did someone had a look at file:///home/florent/doc/Python-Docs/python-docs-html/library/inspect.html in partcular function - func_code - co_name Florent -- 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.
