[sage-combinat-devel] Relabelled cartan types
Hi Anne, Mark, Jesus,
I just pushed an updated version of #13724 which should fix the
issues/missing features of relabelled cartan types:
sage: ct = CartanType([G,2]).relabel({1:2,2:1})
sage: ct.affine()
['G', 2, 1] relabelled by {0: 0, 1: 2, 2: 1}
sage: ct.symmetrizer()
Finite family {1: 3, 2: 1}
sage: ct.root_system().ambient_space()
Ambient space of the Root system of type ['G', 2] relabelled by {0: 0, 1:
2, 2: 1}
Please try out and shake it up!
One thing I haven't done yet is to handle the dual of G_2 and F4:
sage: ct = CartanType(['G',2]).dual()
sage: ct.affine()
One option would be to define the dual of G_2 as a relabelled G_2 (and
the same for F4), which would be two trivial methods to add. I am just
wondering whether there is any useful info we would loose by not
knowing that they are dual types.
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.
Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
hi there. On Fri, Apr 12, 2013 at 05:13:14PM -0600, David Roe wrote: But speaking as someone who contributes a lot to the Sage library itself, I'm strongly in support of Robert Bradshaw's proposal that we combine the different Sage repositories (root, devel, script and ext). It's much easier to work on issues that involve code in these different repositories once you only have to make a commit to a single unified repo. i'm not a sage developer, but i get your point (apart from root - which doesn't contain a single line of code). missing useful git support for submodules is the force appearently. I'm not sure whether the spkgs you refer to correspond to the four repositories I mentioned above, but if so then the merging is intended to be permanent. in turn, i cannot associate any of the four repositories above to the (former) spkg sage.spkg. additionally http://hg.sagemath.org/sage-root is dead, but iirc it contains the toplevel Makefile and README. i think, we are talking about the same merge... To the git transition team: Have you considered using git submodules for the different Sage components? It would certainly solve this issue. Would it also have other advantages? Is there a reason not to do it? Exactly what do you mean by different Sage components? I do know that there was some discussion of git submodules, but it was discarded for technical reasons that I don't recall. components are all non-packaging/distribution related parts. like sage-scripts, sage-notebook, extcode, sage-tex the python modules and the c library. these were (before the git-transition) more or less cleanly split from each other. guess why (who did this?). also, all packages had a unified interface (the spkg-install script), and were treated alike by the top-level-stuff (okay, they should have been -- i don't know for sure). regards felix PS: yes i could think of a roadmap do deal with most of this. but its more work and less distribution-friendly. lets burn all bridges first. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Global options
On Saturday, April 13, 2013 4:36:47 AM UTC+1, Andrew Mathas wrote: One advantage of this is of course would be tab-completion for the options. I'm not entirely sure about renaming the existing methods, however. The methods for a GlobalOptions object are currently: category, db, default_value, dispatch, dump, dumps, rename, reset, reset_name, save, version Does GlobalOption benefit from subclassing SageObject? Which category is it in? Whats the purpose of the rename method? This is not an object that makes a lot of sense on its own, so why should it be on the same footing as mathematical objects that you commonly generate on the Sage command line? In any case you'd need to override __dict__ or __dir__ to make the A.options.foobar tab-completion work, so you could just as well hide useless methods. Though perhaps it would be best to not put in useless methods to start with. I see two different use cases: - global options which control the general behaviour of one or more classes (as with the currently implemented global_options methods of Partitions, Tableaux, PartitionTuples, ...) - options which control how particular instances of class function Encouraging global_options for the former and options for the latter would make sense So whats global in GlobalOptions? Presumably the instance options are the same as the global options, just with a different scope? Is that implemented? Shouldn't we give every parent then options() / global_options() for consistency? -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Webxcas
This was posted over on the mathjax mailing list, and looked interesting to people here: Original Message Subject:[mathjax-users] Webxcas Date: Sat, 13 Apr 2013 01:44:27 -0700 (PDT) From: lucchic...@gmail.com Reply-To: mathjax-us...@googlegroups.com To: mathjax-us...@googlegroups.com Hi, I find webxcas quite interesting http://www-fourier.ujf-grenoble.fr/~parisse/webxcas.html . It's impressive emscripten can convert c++ into javascript. Its benefits seem to be: - Entirely in javascript (no need to worry about security or compatibility) - Quite powerful being based on Xcas - Simple to use - no internet connection need Its only downside seems to be it doesn't look user friendly yet (the layout seems a bit squashed, the text maybe a bit too small, the appearance possibly a little bland) but these are all minor issues. Also the generated code is difficult to decipher it might be worthwhile putting it side by side with the c++ code. What i want is to improve the look. May be MathJax can convert the ouput expressions to MathML. How can i convert normal expressions to MathML with MathJax ? Thank you -- You received this message because you are subscribed to the Google Groups MathJax Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mathjax-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
