Re: [sage-combinat-devel] Re: Compositions in reverse order?
Dear Jean-Yves, OK, but there is some inconsistent behavior, anyway: sage: P=Partitions(4) sage: len(P) 5 sage: C=Compositions(4) sage: len(C) --- AttributeErrorTraceback (most recent call last) /home/jyt/monge/TEX/QSCHUR/ipython console in module() /home/jyt/src/sage-5.4.1/local/lib/python2.7/site-packages/sage/combinat/combinat.py in __len__(self) 972 AttributeError: __len__ has been removed; use .cardinality() instead 973 -- 974 raise AttributeError, __len__ has been removed; use .cardinality() instead 975 976 def count(self): AttributeError: __len__ has been removed; use .cardinality() instead sage: R=reversed(P) sage: list(R) [[1, 1, 1, 1], [2, 1, 1], [2, 2], [3, 1], [4]] Yes ! As you probably already guessed, everything is not yet in a clean state... The first call should raise the same error than the second one. We can't answer consistently to len because Python specified it as being a machine integer. This is much too small for cardinality of combinatorial set and prevent for returning infinity. So as the error message tell you, please write sage: P=Partitions(4) sage: P.cardinality() 5 sage: P=Partitions(4000) sage: P.cardinality() 1024150064776551375119256307915896842122498030313150910234889093895 sage: P=Partitions() sage: P.cardinality() +Infinity And indeed, I think that sage: len(Compositions(4000)) [...] AttributeError: __len__ has been removed; use .cardinality() instead Is a much clean behavior than: sage: len(Partitions(4000)) [...] RuntimeError: maximum recursion depth exceeded in cmp A++ 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.
Re: [sage-combinat-devel] Re: Compositions in reverse order?
Yes ! As you probably already guessed, everything is not yet in a clean state... The first call should raise the same error than the second one. I understand, but in this case, one should teach reversed to use Cardinality instead of __len__. And this is python, not sage ... -- 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/-/3XiisWOYN_gJ. 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] Internal caching in symmetric functions
Hi! Currently we made some progress in fixing Sage's memory leaks that came from overly-eager permanent caching. However, as it turned out in trac ticket #12313, some code related with symmetric functions, specifically code introduced in #13762, heavily relies on having permanent caches. In particular, one gets a very dramatic speed regression, as soon as tiny little parents such as Partitions of the integer 1 can be garbage collected (which apparently has not been the case prior to #12313). Allow me to draw your attention to #13991, where we try to amend it. In particular, note Nils' concluding remarks in comment:10. Perhaps the combinat tribe can give us some hints? Best regards, Simon -- 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] Rebased on top of trac_11641-combinatorial_maps_decorator-cs.patch
Hi, I just allowed myself to rebase the following patches on top of trac_11641-combinatorial_maps_decorator-cs.patch which should get merged soon into Sage: - permutation_inverse-vd.patch - trac_13074-tuples-of-tableaux-am.patch - trac_13605-partition_options-ts.patch - trac_8703-trees-fh.patch 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] Re: Compositions in reverse order?
Hey everyone, On Wednesday, January 23, 2013 3:42:55 AM UTC-8, Jean-Yves Thibon wrote: Yes ! As you probably already guessed, everything is not yet in a clean state... The first call should raise the same error than the second one. I understand, but in this case, one should teach reversed to use Cardinality instead of __len__. And this is python, not sage ... We could do this by just implementing the __reversed__() method in (the to be deprecated) CombinatorialClass. However on the deprecation note, we will need to decide whether or not __len__() and __reversed__() should be added to the (Finite) EnumeratedSets category. Without knowing exactly how sage handles __getitem__() with sage Integers passed in (my belief is everything is converted to machine ints and uses the python list (which is an array in memory [1]) ), I feel like we should leave __len__() alone since if we are trying to create/manipulate a list longer than int (and hence the machine) can handle, you need a better data structure and storage method and __len__() should fail in the same way as trying to create/retrieve the list. [1] http://stackoverflow.com/questions/914233/what-is-the-underlying-data-structure-for-python-lists Best, 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/-/rXatiGt2fAoJ. 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] Sage-combinat won't run with #12940 applied
Hi All, I have just disabled #12940 because when trac_12940_affine_permutations-td.patch is applied and you start sage you hit the error: *snip* --- 26 from affine_permutations import AffinePermutationGroup 27 28 #PerfectMatchings ImportError: cannot import name AffinePermutationGroup Error importing ipy_profile_sage - perhaps you should run %upgrade? WARNING: Loading of ipy_profile_sage failed. With #12940 out of the queue, everything applies, builds and runs so I have disabled this patch. Andrew -- 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/-/Z55Xi2hU8YYJ. 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: Compositions in reverse order?
The problem is that, for the average user, Partitions(n), or Compositions(n), or Whatever(n) is expected to behave like, say, xrange(n). Removing __len__ breaks basic python functionalities, results in head scratching (What am I doing wrong?), and drives the user to a hack-oriented programming style. For algebraic purposes, I have never seen partitions of more than 25 or compositions of more than 16, let alone permutations of more than 14 . For number theory or enumerative combinatorics, one needs much larger values, but a user trying to generate more than 2**62 = 4611686018427387904 objects will probably accept an overflow error. So, why not let __len__ try to return int(cardinality) and throw and exception if it is too large? -- 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/-/ou74j7SCMasJ. 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-combinat won't run with #12940 applied
Hi Andrew, I sent an e-mail about this recently. You need to delete the directory affine_permutations/ in the build files (since Tom previously had a directory affine_permutations/ and now changed it to a file affine_permutations.py in /combinat). Tom, this might not happen (and not every user would separately have to delete these directories by hand) if you changed the file to affine_permutation without the s, which I think it should be anyway. Best, Anne On 1/23/13 8:49 PM, Andrew Mathas wrote: Hi All, I have just disabled #12940 because when trac_12940_affine_permutations-td.patch is applied and you start sage you hit the error: *snip* --- 26 from affine_permutations import AffinePermutationGroup 27 28 #PerfectMatchings ImportError: cannot import name AffinePermutationGroup Error importing ipy_profile_sage - perhaps you should run %upgrade? WARNING: Loading of ipy_profile_sage failed. With #12940 out of the queue, everything applies, builds and runs so I have disabled this patch. Andrew -- 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-devel] Re: Theory of Computer Algebra Systems
On Tue, Jan 22, 2013 at 10:39:01AM -0800, Volker Braun wrote: Its probably impossible to have one book about CAS. But please keep the suggestions coming ;-) Computer Algebra Handbook: Foundations, Applications, Systems by Johannes Grabmeier, Erich Kaltofen and Volker Weispfenning This is at least 10 years old too, but contains an overview of many areas of computer algebra. I think much of it is still relavant today. - Frithjof -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] unable to coerce class 'numpy.matrixlib.defmatrix.matrix' to an integer
Hi,
I'm loading some matrix to do a benchmark and got a error when load some
matrix (one of then can be found at
http://www.cise.ufl.edu/research/sparse/MM/LPnetlib/lp_qap12.tar.gz). A minimal
example and the log of error are below
sage: import scipy.io.mmio
sage: A = scipy.io.mmio.mmread('MM/LPnetlib/lp_qap12/lp_qap12.mtx')
sage: A = A.todense()
sage: A = matrix(A)
---
TypeError Traceback (most recent call last)
/home/raniere/documents/cnpq_126874_2012-3/ipython console in module()
/home/raniere/opt/sage/local/lib/python2.7/site-packages/sage/matrix/constructor.pyc
in matrix(*args, **kwds)
629
630 elif str_dtype.count('int') == 1:
-- 631 m = matrix(ZZ, [list(row) for row in
list(num_array)])
632
633 elif str_dtype.count('object') == 1:
/home/raniere/opt/sage/local/lib/python2.7/site-packages/sage/matrix/constructor.pyc
in matrix(*args, **kwds)
666 ring = rings.ZZ
667
-- 668 return matrix_space.MatrixSpace(ring, nrows, ncols,
sparse=sparse)(entries)
669
670
/home/raniere/opt/sage/local/lib/python2.7/site-packages/sage/matrix/matrix_space.pyc
in __call__(self, entries, coerce, copy, rows)
514 deprecation(13012, 'rows=True/False' parameter is
deprecated!)
515 return self.matrix(entries, coerce, copy, rows)
-- 516 return self.matrix(entries, coerce, copy)
517
518 def change_ring(self, R):
/home/raniere/opt/sage/local/lib/python2.7/site-packages/sage/matrix/matrix_space.pyc
in matrix(self, x, coerce, copy, rows)
1361 x = list_to_dict(x, m, n)
1362 copy = False
- 1363 return MC(self, x, copy=copy, coerce=coerce)
1364
1365 def matrix_space(self, nrows=None, ncols=None, sparse=False):
/home/raniere/opt/sage/local/lib/python2.7/site-packages/sage/matrix/matrix_integer_dense.so
in sage.matrix.matrix_integer_dense.Matrix_integer_dense. __init__
(sage/matrix/matrix_integer_dense.c:7752)()
/home/raniere/opt/sage/local/lib/python2.7/site-packages/sage/structure/parent.so
in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:7228)()
/home/raniere/opt/sage/local/lib/python2.7/site-packages/sage/structure/coerce_maps.so
in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/
structure/coerce_maps.c:3547)()
/home/raniere/opt/sage/local/lib/python2.7/site-packages/sage/structure/coerce_maps.so
in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/
structure/coerce_maps.c:3449)()
/home/raniere/opt/sage/local/lib/python2.7/site-packages/sage/rings/integer.so
in sage.rings.integer.Integer.__init__ (sage/rings/integer.c:7814)()
TypeError: unable to coerce class 'numpy.matrixlib.defmatrix.matrix' to
an integer
I really appreciate any help to solve this problem.
Raniere
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Graph theory roadmap
Hello! This question is related to the following page http://trac.sagemath.org/sage_trac/wiki/GraphTheoryRoadmap As one can see the last time it was modified was 3 years ago. Now in the meantime many new things appeared in Mathematica as well as in Sage. So I am wondering if the page is obsolete now? Is there a new way we track the progress and feature list for the graph theory component? If not then I'd like to make a few updates to the page (and encourage others to do as well) so that we can get a better picture of what still needs to be done in the graph theory component and what is already implemented. Is anyone interested in checking what is present in the new version of Mathematica and is lacking in Sage? Best, Jernej -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Graph theory roadmap
Jernej, While somebody is at this, Maple has graphs, too. On Wed, Jan 23, 2013 at 11:52 AM, Jernej Azarija azi.std...@gmail.com wrote: Hello! This question is related to the following page http://trac.sagemath.org/sage_trac/wiki/GraphTheoryRoadmap As one can see the last time it was modified was 3 years ago. Now in the meantime many new things appeared in Mathematica as well as in Sage. So I am wondering if the page is obsolete now? Is there a new way we track the progress and feature list for the graph theory component? If not then I'd like to make a few updates to the page (and encourage others to do as well) so that we can get a better picture of what still needs to be done in the graph theory component and what is already implemented. Is anyone interested in checking what is present in the new version of Mathematica and is lacking in Sage? Best, Jernej -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: unable to coerce class 'numpy.matrixlib.defmatrix.matrix' to an integer
On Jan 23, 9:41 am, Raniere Silva ra092...@ime.unicamp.br wrote:
Hi,
I'm loading some matrix to do a benchmark and got a error when load some
matrix (one of then can be found
athttp://www.cise.ufl.edu/research/sparse/MM/LPnetlib/lp_qap12.tar.gz). A
minimal
example and the log of error are below
sage: import scipy.io.mmio
sage: A = scipy.io.mmio.mmread('MM/LPnetlib/lp_qap12/lp_qap12.mtx')
sage: A = A.todense()
sage: A = matrix(A)
---
TypeError: unable to coerce class 'numpy.matrixlib.defmatrix.matrix' to
an integer
It seems like sage's matrix doesn't know how to interpret this kind
of object. numpy's matrices probably have a way of turning them into a
list of entries, (either concatenated rows or a list of rows). You can
use either of those to create a sage matrix.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Messing up hash and cmp with UniqueRepresentation
Hi! At #13991, we try to fix a speed regression that comes from the fact that Partitions(n) is not a unique parent, combined with #12313 making the caching of homsets depend on identity (not equality) of domain resp. codomain. While trying to use UniqueRepresentation on Partitions_n and related classes, I found the following: sage: class C(UniqueRepresentation, CombinatorialClass): pass : sage: C.__cmp__.__module__ 'sage.combinat.combinat' sage: C.__eq__.__module__ 'sage.structure.unique_representation' sage: C.__hash__.__module__ 'sage.structure.unique_representation' Isn't that a total mess? Is there a reason why UniqueRepresentation provides __eq__ and __hash__, but not __cmp__? Cheers, Simon -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Messing up hash and cmp with UniqueRepresentation
PS: sage: class MyClass(UniqueRepresentation, CombinatorialClass): : def __init__(self, n): : self.n = n : CombinatorialClass.__init__(self) : def __repr__(self): : return Level %s%self.n : sage: A = MyClass(1) sage: B = MyClass(2) sage: A == B False sage: A == MyClass(1) True sage: %timeit A==B 625 loops, best of 3: 2.34 µs per loop sage: %timeit A is B 625 loops, best of 3: 253 ns per loop Since MyClass inherits from UniqueRepresentation, comparison should be by identity. But I thought that == would rely on __eq__ (which *is* provided by UniqueRepresentation). Are the 2 microseconds really the to-be-expected overhead of calling UniqueRepresentation.__eq__? Or is A==B relying on __cmp__ and not on __eq__? Best regards, Simon -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Messing up hash and cmp with UniqueRepresentation
At #13991, we try to fix a speed regression that comes from the fact that Partitions(n) is not a unique parent Hi Simon, I'm currently reviewing a patch #13605 by Travis Scrimshaw which, among other things, makes Partitions into unique parents. Andrew -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Messing up hash and cmp with UniqueRepresentation
On Jan 23, 2:43 pm, Simon King simon.k...@uni-jena.de wrote: Since MyClass inherits from UniqueRepresentation, comparison should be by identity. But I thought that == would rely on __eq__ (which *is* provided by UniqueRepresentation). Are the 2 microseconds really the to-be-expected overhead of calling UniqueRepresentation.__eq__? I guess so, because all indication is that MyClass does compare by identity. Note that CombinatorialClass does not have an __eq__ and that its __cmp__ is by string repr (whatever the wisdom of that is). However, if we ensure two distinct instances have the same repr, we still get: sage: A=MyClass(1) sage: B=MyClass(2) sage: A Level 1 sage: B Level 2 sage: B.n=1 sage: B Level 1 sage: repr(A) == repr(B) True sage: A is B False sage: A == B False The fact that UniqueRepresentation does not provide __cmp__ is not strange. The rich comparison methods are preferred, and UniqueRepresentation chooses not to implement __lt__ and __gt__. Your cython version will have to return NotImplemented for those. Great work, by the way! It's interesting to see that parents being unique is now required for coercion to work efficiently. -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Messing up hash and cmp with UniqueRepresentation
Hey Simon and Nils, On Wednesday, January 23, 2013 2:28:44 PM UTC-8, Simon King wrote: Hi! At #13991, we try to fix a speed regression that comes from the fact that Partitions(n) is not a unique parent, combined with #12313 making the caching of homsets depend on identity (not equality) of domain resp. codomain. While trying to use UniqueRepresentation on Partitions_n and related classes, I found the following: sage: class C(UniqueRepresentation, CombinatorialClass): pass : sage: C.__cmp__.__module__ 'sage.combinat.combinat' sage: C.__eq__.__module__ 'sage.structure.unique_representation' sage: C.__hash__.__module__ 'sage.structure.unique_representation' Isn't that a total mess? Is there a reason why UniqueRepresentation provides __eq__ and __hash__, but not __cmp__? I thought __cmp__() is only called if __eq__() is not implemented? I almost feel like we should try to push comparisons by is (identity) rather than == (equality) for unique parents. Side notes, CombinatorialClass is (going to be) deprecated and I believe python 3 is deprecating __cmp__() as well. Also please forgive the naive question, but is there any reason for a Parent to not be a UniqueRepresentation? Thanks, Travis -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] translations of a paragraph into German and French needed in #13657
To wrap up http://trac.sagemath.org/sage_trac/ticket/13657 we need translations (for the Sage tutorial) of the following pargraph into German and French: For computing eigenvalues and eigenvectors of matrices over floating point real or complex numbers, the matrix should be defined over ``RDF`` (Real Double Field) or ``CDF`` (Complex Double Field), respectively. If no ring is specified and floating point real or complex numbers are used then by default the matrix is defined over the ``RR`` or ``CC`` fields, respectively, which do not support these computations for all the cases:: For your entertainment, that's my humble attempt to fix the German one: (hopefully it's easier to correct than to redo from scratch :-)) Zur Berechnung von Eigenwerten und Eigenvektoren fuer Matrizen ueber Gleitcomma reellen oder komplexen Zahlen, sollte die Matrix ueber ``RDF`` (Real Double Field) oder bzw.`` CDF `` (Complex Doppel Field) definiert werden. Wenn keine Ring angegeben ist, und Gleitkomma reellen oder komplexen Zahlen werden verwendet, standardmaessig sollte die Matrix ueber die ``RR`` oder bzw. ``CC`` Koerper, die nicht fuer alle Faelle diese Berechnungen unterstuetzt, definiert werden:: I've already added a Russian translation. By the way, does anyone know why http://trac.sagemath.org/sage_trac/attachment/ticket/13657/trac_13657-linal_RDF.ru.patch looks as if the encoding is wrong? The patch, and the corresponding file doc/ru/tutorial/tour_linalg.rst, have utf-8 encoding. Is it a trac bug? Thanks, Dima -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Graph theory roadmap
On 2013-01-23, Tom Boothby tomas.boot...@gmail.com wrote: Jernej, While somebody is at this, Maple has graphs, too. and GAP has its graphs, which are very efficient in case there are lots of automorphisms: http://www.maths.qmul.ac.uk/~leonard/grape/manual/chapters.htm Sage does include the corresponding GAP package, GRAPE in its optional packages (gap_packages spkg). We talked about building a Sage backend to this at some point. This ought to be mentioned in the roadmap... On Wed, Jan 23, 2013 at 11:52 AM, Jernej Azarija azi.std...@gmail.com wrote: Hello! This question is related to the following page http://trac.sagemath.org/sage_trac/wiki/GraphTheoryRoadmap As one can see the last time it was modified was 3 years ago. Now in the meantime many new things appeared in Mathematica as well as in Sage. So I am wondering if the page is obsolete now? Is there a new way we track the progress and feature list for the graph theory component? If not then I'd like to make a few updates to the page (and encourage others to do as well) so that we can get a better picture of what still needs to be done in the graph theory component and what is already implemented. Is anyone interested in checking what is present in the new version of Mathematica and is lacking in Sage? Best, Jernej -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Messing up hash and cmp with UniqueRepresentation
Hi Andrew, On 2013-01-23, Andrew Mathas andrew.mat...@gmail.com wrote: At #13991, we try to fix a speed regression that comes from the fact that Partitions(n) is not a unique parent I'm currently reviewing a patch #13605 by Travis Scrimshaw which, among other things, makes Partitions into unique parents. Thank you! I made it a dependency for #13991, and it could actually be that it is enough to fix the regression. Best regards, Simon -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] translations of a paragraph into German and French needed in #13657
Dima, I can make the translation into French. == Pour calculer les valeurs propres et les vecteurs propres d'une matrice à coefficients flottants réels ou complexes, la matrice doit être définie respectivement sur RDF (Real Double Field) ou CDF (Complex Double Field). Si aucun anneau n'est spécifié et si on utilise des coefficients réels ou complexes, alors la matrice est définie par défaut respectivement sur les corps RR ou CC, corps qui ne permettent pas d'effectuer ces calculs dans tous les cas. === Note: - I do not translate Real Double Field and Complex Double Field (Corps des réels doubles does not mean many things. - In good French sghould be replaced by Le 24/01/2013 03:20, Dima Pasechnik a écrit : To wrap up http://trac.sagemath.org/sage_trac/ticket/13657 we need translations (for the Sage tutorial) of the following pargraph into German and French: For computing eigenvalues and eigenvectors of matrices over floating point real or complex numbers, the matrix should be defined over ``RDF`` (Real Double Field) or ``CDF`` (Complex Double Field), respectively. If no ring is specified and floating point real or complex numbers are used then by default the matrix is defined over the ``RR`` or ``CC`` fields, respectively, which do not support these computations for all the cases:: For your entertainment, that's my humble attempt to fix the German one: (hopefully it's easier to correct than to redo from scratch :-)) Zur Berechnung von Eigenwerten und Eigenvektoren fuer Matrizen ueber Gleitcomma reellen oder komplexen Zahlen, sollte die Matrix ueber ``RDF`` (Real Double Field) oder bzw.`` CDF `` (Complex Doppel Field) definiert werden. Wenn keine Ring angegeben ist, und Gleitkomma reellen oder komplexen Zahlen werden verwendet, standardmaessig sollte die Matrix ueber die ``RR`` oder bzw. ``CC`` Koerper, die nicht fuer alle Faelle diese Berechnungen unterstuetzt, definiert werden:: I've already added a Russian translation. By the way, does anyone know why http://trac.sagemath.org/sage_trac/attachment/ticket/13657/trac_13657-linal_RDF.ru.patch looks as if the encoding is wrong? The patch, and the corresponding file doc/ru/tutorial/tour_linalg.rst, have utf-8 encoding. Is it a trac bug? Thanks, Dima -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. attachment: tdumont.vcf
[sage-devel] Re: translations of a paragraph into German and French needed in #13657
On 01/24/2013 10:20 AM, Dima Pasechnik wrote: I've already added a Russian translation. By the way, does anyone know why http://trac.sagemath.org/sage_trac/attachment/ticket/13657/trac_13657-linal_RDF.ru.patch looks as if the encoding is wrong? The patch, and the corresponding file doc/ru/tutorial/tour_linalg.rst, have utf-8 encoding. Is it a trac bug? Probably it is a trac bug. The patch looks fine here in vim. -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
