from:"Nicolas M. Thiery"

Hi Mark!

On Thu, Jun 11, 2015 at 06:44:04PM -0400, Mark Shimozono wrote:
 I require a method which, given a sage category of a module,
 returns the ring which acts upon it.

 There is a method :meth:`ModulesWithBasis.base_ring`
 which is supposed to give the base ring of a module (rather than
 that of a category of modules) but it is broken.

 The base ring is stored as an attribute. However unlike methods,
 attributes are not inherited by sage subcategories.
 Thus it is necessary to search the category tree to find
 a suitable leaf which possesses the base ring attribute.

Following the issues you had mentioned in Davis, since #1
Modules.SubcategoryMethods.base_ring provides a default implementation
of base_ring so that A(XXX).base_ring() returns XXX for any
subcategory A(XXX) of Modules(XXX).

XXX may indeed be either a ring or a category thereof, depending on
how the category was created.

 At any rate, in the given example, passage to the category has the
 effect of forgetting needed information.

Can you describe more precisely your use case? Do you have an example
where you only have the category under hand, and still need to know
explicitly the base ring?

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: strange category

On Fri, Jun 12, 2015 at 08:28:15AM -0400, Mark Shimozono wrote:
 To do this entirely correctly each functorial construction needs to know what 
 properties it
 respects; otherwise the new composite object may possess properties that 
 don't make sense,
 even when all its pieces have the property.

I am not sure to follow.

Here the goal of the logic is to detect what's the most specific
common category C of a collection of parents.

How each functorial construction deduces from C, the properties of the
composite object is an independent logic, isn't it?

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: strange category

On Fri, Jun 12, 2015 at 08:46:34AM -0400, Mark Shimozono wrote:
 One last question: how do morphisms of modules know they can be tensored?

Like parents or elements: because they (should) have a tensor
method?

(I may have misunderstood your question ...)

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: strange category

On Fri, Jun 12, 2015 at 07:27:51AM -0400, Mark Shimozono wrote:
 I'm implementing smash products of AlgebrasWithBasis,
 which are tensor products of algebras with not-necessarily-componentwise
 product.  When the tensor factors are themselves tensor products,
 I don't want to use the default tensor product construction, which flattens
 tensors (good for linear operations but disastrous for the above purpose).

Yup.

 My solution was to allow the tensor product construction to admit a
 category suggestion, which is then used to choose a new grouped tensor
 implementation or the usual flattened one.
 
 The smash product only makes sense when the algebras are over the
 same base ring.
 
 Sometimes I want to choose the flattened tensor even when the factors
 are all algebras and sometimes of course I want the grouped tensor product.

Ok, thanks for the description.

We encountered something similar when playing with cartesian products
with Vincent. When A and B are modules over different base rings RA
and RB (but same base ring category),

cartesian_product(A,B)

should not be in Modules(Rings()). Currently, the category for the
cartesian product is obtained by starting from the meet of the
category of A and the category of B; this should be refined to take
into account the base rings of A and B. So probably we want some
method

meet_category_of([A,B,...])

which implements this logic, starting from the parents and not only
from their categories.

I am not sure:

- Where to put such a method (and what its name should be). As a
  starter, let's take sage.categories.category.meet_category_of.

- How to implement it; I guess we can start by doing the usual meet,
  and then hardcoding the special rule for modules; maybe later we
  will have other use cases guiding us toward something more general.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: strange category

On Fri, Jun 12, 2015 at 12:59:10PM -0400, Mark Shimozono wrote:
 How does sage know to supply them with a tensor method?

See ModulesWithBasis.ParentMethods.tensor and
ModulesWithBasis.ElementMethods.tensor. Those could be lifted to
Modules if we had more general implementations.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: remove combinat/mupad from sagemath website

2015-06-09 Thread Nicolas M. Thiery

On Mon, Jun 08, 2015 at 03:56:55PM +0200, Nathann Cohen wrote:
 Yes, that's what I did this morning. It's a pull request, waiting to
 be accepted.

Great. I don't have write access on this repository, so just put a +1
there (and made a further pull request going one step further:
removing the link from the Sage citations to the MuPAD-Combinat
citations).

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: remove combinat/mupad from sagemath website

2015-06-09 Thread Nicolas M. Thiery

Hi Harald,

 ...

Thanks for your reorganization work on the web site; it's in
particular very convenient to now be able to propose changes with our
usual collaborative tools!

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: remove combinat/mupad from sagemath website

2015-06-08 Thread Nicolas M. Thiery

On Mon, Jun 08, 2015 at 09:51:36AM +0200, Nathann Cohen wrote:
 I did not propose to remove sage-combinat's publications list (which
 will be merged on a common page), I was only talking about
 mupad-combinat.

Indeed. But Anne raised a point which I had overseen: the URL

http://www.sagemath.org/library-publications-combinat.html

has been advertised in several places, including grant documents. We
don't necessarily need to keep the page itself there, but then we need
a redirection.

 On the other hand, while I understand that you may have to keep your
 bibliography up-to-date, I don't see why you should keep your
 project's data on Sage's website and not on sage-combinat's website.

Sage-Combinat is part of Sage. Sage-Combinat's website is a page on
the Sage wiki. The Sage-Combinat's NSF grant benefited Sage at large.
I don't see the point of suddenly having to duplicate the
infrastructure.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: remove combinat/mupad from sagemath website

2015-06-08 Thread Nicolas M. Thiery

On Mon, Jun 08, 2015 at 09:48:17AM +0200, Nathann Cohen wrote:
 I don't doubt it. But perhaps you should stop considering Sage's
 website as a convenient way to store your pages. It strikes me at the
 moment that I am the one trying to rearrange sage-combinat's and
 mupad-combinat's bibliography, while your role is to tell me how you
 want it arranged. The time that you save for yourself is the time
 that others (e.g. me) spend managing what you don't want to think
 about.

Why do you need to rearrange/manage those pages at all? Just leave
them as they are. I don't see the cost of this.


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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: remove combinat/mupad from sagemath website

2015-06-07 Thread Nicolas M. Thiery

Hi,

First: thank you Nathann for your work on the web site! Simplification
is good.

On Sun, Jun 07, 2015 at 02:28:12AM -0700, Nathann Cohen wrote:
 More precisely, I propose to:
 
 - Remove the Publications Mupad page.
 
   This software is not Sage, is not part of Sage either, and has not been
   maintained for the past 7 years according to its website. This page of
   publications is also unmaintained, e.g. there is a 'preprint' from 1999.
 
 - Merge Publications Sage and Publications Combinat into one page:
 
   (by 'merging' I mean having them all on one page, first the 'pure-sage'
   publications then the 'combinat' publications in another group)
 
   For a while, there would be a redirection from the current sage-combinat
   publication page to the right place in the merged 'all-publications' page

I don't have a strong opinion. Here is a collection of thoughts.

- It's important to keep track of publications using Sage in order to
  have some sort idea of the usefulness of all the work we put into
  it. I further believe it's important to refine this further, to have
  some idea of the usefulness of the work we put in each of the
  various areas of Sage. There is nothing specific about combinatorics
  here: being able to roughly tell how many publications used e.g. the
  number theory or the graph code, or GAP, or ... would be good.  See
  e.g. what's done in Magma:

https://magma.maths.usyd.edu.au/magma/citations/

- As a bunch of code, MuPAD-Combinat is indeed dead. I am in fact
  amazed to occasionally hear that some people are still using it,
  despite its development being stopped since 7 years now, by an
  explicit decision. However a software project is also very much
  about the accumulated know how, and the community; both of those are
  still alive, reincarnated and very much expanded in Sage.

- It was useful for us, and still is, to keep track of the
  publications citing MuPAD-Combinat and Sage-Combinat. At the time,
  Minh and Harald offered us to use the same infrastructure as for the
  Sage list for both, which was very convenient.

So now, what to do from there?

- The MuPAD-Combinat citation list is unlikely to evolve much more. I
  agree that there is no compelling reason to have a link sagemath.org
  - Library - Citations MuPAD; so if you want to remove that link,
  that's fine with me. On the other hand, there probably isn't much
  cost nor confusion involved in keeping the page:

http://www.sagemath.org/library-publications-mupad.html

  just to save the time on relocating it elsewhere. Also I would find
  natural to have a link from the Sage-Combinat list to that list,
  with a word of explanation.

- Rather than having two citation pages, one for Sage, and one for
  Sage-Combinat, it would indeed seem natural to me to have a single
  page containing all citations, with some tagging mechanism allowing
  the extraction of citations mentioning a particular area of Sage, as
  is done for e.g. Magma (quite often a citation could refer to
  several areas of Sage; tags are a good way to reflect this).

  What you propose is some sort of first step in this direction.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: remove combinat/mupad from sagemath website

2015-06-07 Thread Nicolas M. Thiery

On Sun, Jun 07, 2015 at 11:44:10PM +0200, Nathann Cohen wrote:
  No. Please reread.
 
 Same result. Care to make yourself clearer?

   Nicolas:
   On the other hand, there probably isn't much
   cost nor confusion involved in keeping the page:
 
 http://www.sagemath.org/library-publications-mupad.html
 
   just to save the time on relocating it elsewhere.

I'd appreciate if you would keep that page where it is.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: remove combinat/mupad from sagemath website

2015-06-07 Thread Nicolas M. Thiery

On Sun, Jun 07, 2015 at 11:35:35PM +0200, Nathann Cohen wrote:
  With the amendments I mention above, I am ok with it.
 
 I noted two:
 1) A link from the new (merged) page to the Mupad-combinat page

Yes.

 2) You will relocate the mupad page to mupad-combinat's home page, and
 send me an email when it is done so that we can remove it from Sage's
 server and update the links.

No. Please reread.


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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] How to set the category of finite Coxeter groups properly?

2015-06-04 Thread Nicolas M. Thiery

Hi Christian!

On Thu, Jun 04, 2015 at 03:52:57PM -0500, Christian Stump wrote:
 But if I add a method CoxeterGroups().Finite().super_categories
 returning that,

For an axiom category like CoxeterGroups.Finite, the method
super_categories is implemented to automatically deduce the super
categories from the axiom Finite and the base category
CoxeterGroups. Overriding super_categories to specify additional
super categories breaks this; so instead one need to implement
extra_super_categories.

 I run into trouble:
 
 1. Now, the repr of CoxeterGroups().Finite() is Category of finite
 well generated coxeter groups. How do I get rid of the well
 generated there?

Here, since the base category and axiom for FiniteCoxeterGroups is not
specified explicitly, the repr is built automatically from the repr of
the base category and the axioms that are not axioms of the base
category. This is just a heuristic and is not always perfect. If the
problem still appears once the super categories are fixed, you can
work around it by adding this line:

class FiniteCoxeterGroups:

_base_category_class_and_axiom = (CoxeterGroups, Finite)


 2. Many doctests in CoxeterGroups().Finite() now fail. I do not
 understand how doctests can break there at all since I did only add
 some new methods. Or did I also overwrite some -- and if so, how do I
 prevent the system doing so?

Presumably there is some super category missing and this will be
resolved with the above.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: map_coefficients factor

2015-04-22 Thread Nicolas M. Thiery

On Tue, Apr 21, 2015 at 11:44:02AM -0700, 'Martin R' via sage-combinat-devel 
wrote:
I just pushed an initial try.  If you care, could you have a look
whether it's in principle OK?

Thanks for taking action!

I just commented on it on the ticket [1]. Please anyone interested by
`.map_coefficients(f, check=True)` have a look at the ticket and let's
continue the discussion there.

Nicolas

[1] http://trac.sagemath.org/ticket/18264

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: map_coefficients factor

2015-04-20 Thread Nicolas M. Thiery

On Sat, Apr 18, 2015 at 12:10:47PM -0700, 'Martin R' via sage-combinat-devel 
wrote:
Sorry, I should have made myself clearer: I do not understand the
design decision behind the way map_coefficients works.
Shouldn't it rather check whether the function actually produces
something in the coefficient ring?

That's the usual speed vs safety vs flexibility. We definitely want to
have a fast map_coefficients that does no check, for those cases where
we know that f is an endofunction as specified by the
documentation. In some cases the user can find it handy to abuse the
system a bit (like Mike is doing), just for output. In all other cases
it would be preferable to have systematic checks.

Supporting both speed vs safety boils down to adding an option
`check=True`, and if possible going trough the Sage code and setting
`check=False` wherever we know we are on the safe side. It's an easy
change. Volunteers welcome!

For supporting cleanly Mike's needs for flexibility, we really would
need to change the base ring. It would be nice to have some idiom
like:

sage: f.map_coefficients(factor, codomain=SR)

or

sage: f.change_base_ring(SR).map_coefficients(factor)

This one is a bit trickier.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: the base_ring method of subcategories of modules

2015-03-26 Thread Nicolas M. Thiery

Hi Mark!

On Mon, Mar 23, 2015 at 12:17:34PM -0700, Mark Shimozono wrote:
I am trying to think of a decent way to have an arbitrary
subcategory of Modules() to inherit the base_ring method.
Would it be possible to have special kinds of methods/attributes
that are inherited by Category_over_base
from the base category? (Of course I have :method:`base_ring`
in mind).  Ditto for any category constructor through which one might
want to inherit methods.
Does a JoinCategory inherit from its supercategories
automatically (or could the above idea be implemented for
JoinCategories
as well)?

Sorry for the slow answer: it's pretty intense here at AIMS while
simultaneously finishing up projects from the Sage Days! I'll reserve
an hour or so soon to think seriously about the issue.

In the mean time ...

If a method is put in SubcategoryMethods, then every subcategory of
Blahs inherits from it::

class Blahs(Category):
def super_categories(self): return [Objects()]
class SubcategoryMethods:
def x(self):
print x, self

class Foos(Category):
def super_categories(self):
return [Blahs()]

sage: Foos().x()
x Category of foos

So this sounds like a good candidate for the desired base_ring
method. There is one caveat though, which is that base_ring needs to
find the appropriate information! SubcategoryMethods gives inheritance
of methods but not of attributes.

Worst case, one could implement base_ring by walking up the category
hierarchy until an actual base_ring method is found, and call it.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: Order of Partitions()

2015-03-18 Thread Nicolas M. Thiery

Hi!

Thanks everyone for your input. We are banging hard on IntegerListLex
at Sage Days 64, and hopefully will get a correct and as fast as
previously implementation in the coming days. Don't hold your breath,
but the point is that it's likely that the non lex is faster is only
a temporary effect.

Btw: I'd like to thank Jeroen for his hard work on an alternative
polytope based implementation (#17920). Even with the hopefully
upcoming IntegerListLex, every bit of his work will be useful:

- Iteration over polytopes which is a generally useful feature
- Lots of documentation and tests that we will recycle
- An alternative implementation to run comparative tests
- The connection with polytopes, which will be useful for other
  operations (counting, and maybe others)

Cheers,
 Nicolas


On Wed, Mar 18, 2015 at 02:28:36PM +0100, Viviane Pons wrote:
2015-03-18 12:40 GMT+01:00 Mike Zabrocki [1]mike.zabro...@gmail.com:
 
That would make sense.  My preference is that (at least for values less
than 15) the default is that the output is sorted and this can be
controlled by the optional parameter.
I think about how many times that I test symmetric function identities
on partitions and realize that patterns that indicate a relation to
dominance order will be a lot less clear if the order is not something
natural.  I wouldn't want the interface to be too complicated, but the
more I think about it the more I realize that my personal use of
partitions is very dependent on this order.
 
I would tend to agree with you. The order wasn't documented but I'm
pretty sure many people writing some personal code using partitions
still rely on the order somehow. I feel a good choice would be to give
the nice order by default and some parameter to obtain the optimized
one.
 
On Wednesday, 18 March 2015 04:20:15 UTC-4, Samuel Lelievre wrote:
 
Nathann Cohen wrote:
 
  Hello,
   I think that Partitions should be output in either lex (or
  possibly reverse
   lex) since this order is compatible with dominance order.
  I only want to bring to your attention that deciding in which order
  the partitions should be returned is not free in terms of
  computational time.
  The current implementation returns them in lex order, but returns
  *many* wrong answers too (see #17548).
  In order to fix that, Jeroen is re-implementing this feature through
  a
  routine that enumerates the integer points of a polytope (see
  #17920),
  probably without any control over the order in which they are
  returned.
  Thus, in order for Partition/Composition to return them in a
  specific
  order we must list them *all* before returning the first of them.
  This
  can really mean hours (or no results at all) instead of seconds on
  big
  instances.
 
So would it make sense to have an optional parameter sorted=None,
which one could set to 'lex' or 'revlex' to get them in a desired
order.
The documentation could warn about the issues you just raised.
 
--
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 [2]sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to
[3]sage-combinat-devel@googlegroups.com.
Visit this group at
[4]http://groups.google.com/group/sage-combinat-devel.
For more options, visit [5]https://groups.google.com/d/optout.
 
--
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 [6]sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to
[7]sage-combinat-devel@googlegroups.com.
Visit this group at
[8]http://groups.google.com/group/sage-combinat-devel.
For more options, visit [9]https://groups.google.com/d/optout.
 
 Références
 
1. mailto:mike.zabro...@gmail.com
2. mailto:sage-combinat-devel+unsubscr...@googlegroups.com
3. mailto:sage-combinat-devel@googlegroups.com
4. http://groups.google.com/group/sage-combinat-devel
5. https://groups.google.com/d/optout
6. mailto:sage-combinat-devel+unsubscr...@googlegroups.com
7. mailto:sage-combinat-devel@googlegroups.com
8. http://groups.google.com/group/sage-combinat-devel
9. https://groups.google.com/d/optout
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

Re: [sage-combinat-devel] Re: obtaning meet semi-lattices with n elements

2015-03-12 Thread Nicolas M. Thiery

On Thu, Mar 12, 2015 at 02:00:37AM -0700, Nathann Cohen wrote:
As Sage is open-source you can usually answer such questions by reading
the code, or the function's documentation.
In this specific case, however, I do not know if we actually have this
feature in Sage: do you *know* how to enumerate meet-semilattices in
Sage? If so please share the commands, and we will probably find in the
doc a description of the algorithm it implements.

As far as I know, it is not implemented. There is a tiny note about
this at the end of:

sage.combinat.tutorial?

In theory it should be possible to use the tool ``graphs`` to generate
graphs up to an isomorphism, using an orderly generation along the
vertices. However, when we tried this with Tom Denton a couple years
ago, we stumbled on an issue. I can try to recover the details; it was
something about making sure that the new vertices were added to the
top of the meet semi lattice, which required a minimum of control on
the canonical labeling.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Import error using recusive trees

2015-02-10 Thread Nicolas M. Thiery

Dear Henrik,

On Tue, Feb 10, 2015 at 03:50:01AM -0800, Henrik Sperre Sundklakk wrote:
I am implementing unordered rooted trees in Sage (to use them in
B-series). When trying to iinherit from
sage.combinat.abstract_tree.AbstractClonableTree I get an ImportError.
I have successfully called OrderedTrees() from the notebook, so my Sage
installation is sound. The problem occurs when I use Eclipse.
I launch Eclipse from the Sage shell, and use the Python interpreter
provided by Sage (/usr/lib/sagemath/local/bin/python2.7). I keep my .py
files in a directory in my SAGE_PATH. I have successfully imported and
inherited from classes in Sage (ClonableElement). This code runs, both
in Eclipse and the nootebook.
However, the following line, even when it is the only line in a file,
elicit the following error (as does all attempts to import anything
depending on abstrac_tree):
import sage.combinat.abstract_tree
Traceback (most recent call last):
  File
/home/henrik/Documents/studier/masteroppgave/code/pybs/pybs/scratch2.p
y, line 5, in module
import sage.combinat.abstract_tree# import AbstractClonableTree
  File
/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/combinat/abst
ract_tree.py, line 67, in module
from sage.rings.integer import Integer
  File sage/rings/rational.pxd, line 10, in init sage.rings.integer
(build/cythonized/sage/rings/integer.c:41630)
  File sage/rings/rational.pyx, line 56, in init sage.rings.rational
(build/cythonized/sage/rings/rational.c:30843)
  File
/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/rings/rationa
l_field.py, line 55, in module
import infinity
  File
/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/rings/infinit
y.py, line 213, in module
from sage.rings.integer_ring import ZZ
  File sage/rings/integer_ring.pyx, line 67, in init
sage.rings.integer_ring
(build/cythonized/sage/rings/integer_ring.c:11566)
  File
/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/structure/fac
torization.py, line 188, in module
from sage.misc.all import prod
  File
/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/misc/all.py,
line 89, in module
from functional import (additive_order,
  File
/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/misc/function
al.py, line 36, in module
from sage.rings.complex_double import CDF
  File sage/rings/real_double.pxd, line 8, in init
sage.rings.complex_double
(build/cythonized/sage/rings/complex_double.c:20095)
  File sage/rings/real_double.pyx, line 56, in init
sage.rings.real_double
(build/cythonized/sage/rings/real_double.c:22825)
ImportError: cannot import name ZZ
Since recursive trees work from the notebook, I guess the problem is me
doing something wrong trying to import it, but I can't think of what it
is...

You may want to try something like

import sage.all
import sage.combinat.abstract_tree

The core Sage library currently is brittle if it's not loaded in the
right order, and in particular if it's partially loaded from a
specific entry point. Importing sage.all is a way to load the core
first, and then access specific stuff.

Thanks for working on unordered trees!

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] combinat.math.washington.edu

2015-01-04 Thread Nicolas M. Thiery

Dear William,

On Sat, Jan 03, 2015 at 08:23:15PM -0800, William Stein wrote:
 The computer combinat.math.washington.edu is down... again.  Sort of.
 It responds to ping requests, but I can't ssh in.
 
 I suspect that not a lot of people are actively using it lately, since
 this is the second time it has gone down for over a week in the last 3
 months, and nobody (except my student Hao Chen), seems to have
 noticed.

I actually had noticed that the web server was down a couple weeks ago
and recently, but had not gotten the time to report.

 I'm considering doing the following.  I'll shutdown combinat
 completely, reformat the disk, and set it up as a node of the
 cloud.sagemath.com (SMC).   It'll still have the amazing 64 cores and
 huge (192GB) RAM.  However, instead of login in directly to it, people
 can email me to request that I move a particular SMC project to
 combinat.  It will then have access to expanded compute resources.
 The advantage of this, is that it is much easier for me to maintain.
 In particular, SMC has automated scripts to take care of using cgroups
 to explicitly limit usage of compute resources by a given project, I
 have extensive monitoring code in place so I know when things go down,
 and I everything runs in virtual machines, so when there are problems
 I can easily fix them in a few minutes remotely.  Also, it's much
 easier to grant fair usage to projects.As it is now with default
 linux on combinat, basically any user can just bring down the computer
 by using too much memory/disk/whatever, which is probably what
 happened in this case (I don't know).
 
 Thoughts?
 
 Obviously, this may be a bit slower and the max memory will be less
 (as things are in a VM) for specific research-level computations.
 However, a working computer is way better than a regularly-crashing
 computer, in my opinion.Also, given the weeks of downtime that
 nobody (except Hao) notices, maybe people aren't using combinat at all
 anyways, due to it being only a remote linux box.   Personally, I
 think SMC makes using remote Linux boxes much easier.

I believe people are actually using combinat relatively intensively,
but on a peak basis. Or for very long term calculations. So there can
indeed be long periods where they don't connect.

We had already discussed running the calculations on combinat within
virtual machines, for safeguards, ease of access and
checkpoints. Going through SMC seems a reasonable way to achieve
this. So +1 on my side, especially now that it's open source!

Besides, it will give me an occasion to use SMC seriously, which I
should for our VRE grant :-)

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.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: sage-trac-account, I wish to devolop a library for multiple zeta values

2014-12-18 Thread Nicolas M. Thiery

Dear Akhilesh,

Thanks for getting in touch. I am forwarding your e-mail to
sage-combinat-devel, as others there might be interested in some or
all of the topics you mention.

For the trac account, see the instructions on http://trac.sagemath.org/

On Thu, Dec 18, 2014 at 11:51:45AM +0530, akhilesh p wrote:
  I am Akhilesh, Student in Harish-Chandra
Research Institute (HRI) Allahabad. We met in Sage Days 60 workshop at
IMSc chennai. That time I missed to take Sage trac account. I wish to
develop one multiple zeta library Sage that contains
1. Computing Multiple zeta function with very high accuracy (1000 or
1 digit precision or any)
2. Shuffle product and Stuflle product in fast and efficient way
3. Computing the values of logarithm with very high accuracy for a
complete set of numbers from {2,3,...N} in a very efficient way
4. Computing the values of Bernoulli numbers for a complete set of
numbers from {2,3,...N} in a very efficient way.
5. Computing Derivatives  Multiple zeta function with very high
accuracy (1000 or 1 digit precision or any)
6. Currently the PSLQ algorithm in sage can handle up 100 numbers. I
like write another program which can handle up to 1000 numbers
I kindly requesting you help me to get trac account in Sage
sincerely
Akhilesh P.
Research Scholar
HRI
Allahabad

Kind regards,
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] A small hint in Symmetric Functions

2014-11-21 Thread Nicolas M. Thiery

Salut Nicolas!

On Thu, Nov 20, 2014 at 12:19:15PM +0100, Nicolas Borie wrote:
 As I was constructing some Free Modules over the symmetric
 functions, I fall on this (sage 6.4.beta2 for my version (yes,
 that's probably old)):
 
 sage: SymmetricFunctions(QQ) in CommutativeRings()
 False
 sage: SymmetricFunctions(QQ).a_realization() in CommutativeRings()
 True
 
 I would have loved that the two lines return True. If I say no
 mistakes, the symmetric functions should be an abstract parent with
 severals realizations. The category is *probably* initialized in
 sf.py with the line:
 
 Parent.__init__(self, category = GradedHopfAlgebras(R).WithRealizations())
 
 Is this enought to change this category for the following one (with
 QQ replaced by R in the source code naturally) ?
 
 sage: GradedHopfAlgebras(QQ).Commutative().WithRealizations()

+1

While you are at it, you might as well want to go for:

  HopfAlgebras(R).Graded().Connected().Commutative().WithRealizations()

 Perhaps this question is relatively empty but I didn't contribute to
 Sage for something like a year. I just reviewed 2 tickets the last 6
 month and I am still scared of using git (don't laugh please!). So I
 asked before since a such one line patch cost 10 minutes for git
 lovers but probably 2 hours with the cheat-sheet of Volker for me.
 Ok, I just heard someone saying that it will need one than one line
 since it could be nice to add the proper test in the
 documentation... Rhoo

This sounds like a perfect ticket for a come back. The extra time
you'll spend there is a long term investment anyway.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

2014-11-21 Thread Nicolas M. Thiery

Hi Andrew,

On Fri, Nov 21, 2014 at 05:55:51AM -0800, Andrew wrote:
I'm currently going around in circles with some CombinatorialFreeModule
woes. The previous code for these alternating seminormal forms works,
but in order to cope with the many variations of seminormal
representations that I decided to implement working I've have had to
jazz things up quite a lot. Now my basic class structure looks
something like this:
from sage.combinat.free_module import CombinatorialFreeModule
from sage.rings.polynomial.polynomial_ring_constructor import
PolynomialRing
class A(CombinatorialFreeModule):
def __init__(self, base_ring, basis_keys, prefix='a', **kwargs):
super(A,self).__init__(base_ring, basis_keys, prefix=prefix,
**kwargs)
class Element(CombinatorialFreeModule.Element):
pass
class B(A):
def __init__(self, base_ring, basis_keys, prefix='b', **kwargs):
super(B,self).__init__(base_ring, basis_keys, prefix=prefix,
**kwargs)
class C(B):
def __init__(self, shape, prefix='c', **kwargs):
base_ring=PolynomialRing(Integers(), 'q')
super(B,self).__init__(base_ring, shape.standard_tableaux(),
prefix=prefix, **kwargs)
This simplified code works fine. For example,
sage: C(Partition([3,2])).an_element()
2*c[[[1, 2, 5], [3, 4]]] + 3*c[[[1, 3, 4], [2, 5]]] + 2*c[[[1, 3, 5],
[2, 4]]]
Unfortunately my real code does not work, having issues like:
sage: rep=SeminormalRepresentation([2,1]); rep
SeminormalRepresentation([2,1])# seems to work
OK
sage: rep.an_element() # try to construct an element
repr(sage.algebras.iwahori_hecke_algebras.iwahori_hecke_algebra_repre
sentations.SeminormalRepresentation_with_category.element_class at
0x119a88c80) failed: AttributeError:
'SeminormalRepresentation_with_category' object has no attribute
'_prefix'
sage: rep(StandardTableau([[1,2],[3]]))
AttributeErrorTraceback (most recent call
last)
...
AttributeError: 'SeminormalRepresentation_with_category' object has no
attribute '_basis_keys'
Does anyone have an idea of what is going wrong. Part of the issue
might be all of the super calls, but I tried taking though ut and
explcitly calling the previous class (they are linearly ordered), but
this doesn't help.

Hmm, I haven't taken the time to think with a pen and paper, but I
don't guarantee that the what the super call do is as straightforward
as it ought to, given that the instance of A being initialized will
end up being in a subclass A_with_category, and similarly for the
others.  Does it work if instead you call explicitly A.__init__ in
B.__init__, and so on?

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

2014-11-15 Thread Nicolas M. Thiery

Dear Andrew,

On Fri, Nov 14, 2014 at 09:02:13PM -0800, Andrew wrote:
I don't believe this: gap3 is less strongly typed than python and it is
possible to do this there! :) The natural way to distinguish between
different bases is using their prefix -- indeed this is effectively
what chevie does and Eric's manifold's code does.

I mean: without knowing something about the semantic of those methods,
how do we know that:

sage: x.antipode()

will return an element of the algebra, and therefore the result shall
be retracted back, whereas:

sage: x.counit()

will return an element of the ground field which needs no transformation?

You are right, we could run those methods on some element and look at
the parent of the result. So, at the price of a dynamic lookup (which
in my past experience is a source of trouble, but that's another
discussion), we could indeed retrieve about the same information as in
a statically typed language.

So let me rephrase my argument: what we really need to know is which
methods are, or not, preserved by the lift and retract changes of
basis. For a stupid example,

sage: x.coeff(lambda)

is not preserved; so no lifting shall be applied in the first place.

The Isomorphic infrastructure is about making the semantic explicit:

- what structure is preserved, or not, by the changes of basis
- which methods are therefore preserved, and how to handle them
  through coercion

As a cherry on the cake this makes it possible to say F is isomorphic
to G as an algebra, but not as a coalgebra.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

2014-11-12 Thread Nicolas M. Thiery

Hi Andrew!

On Tue, Nov 11, 2014 at 03:07:26PM -0800, Andrew wrote:
This is a good start but it is not enough: essentially the difference
between what I want and what this does is the same as the difference
between a vector space isomorphism and an A-module isomorphism. As you
pointed out, there are limitations if these objects are algebras. The
same limitations apply to modules because any interesting
CombinatorialFreeModule will come equipped with endomorphisms, actions
and other methods. I would like a mechanism for automatically
transferring these methods to the new module by implicitly invoking the
coercions above. These methods will be both module methods and module
element methods and, more generally, algebra and algebra element
methods.
I don't think this this should be hard to do within the existing
framework, and the mechanism should be roughly what you have above.
After all, this is easy enough to do by hand because if F has a nice
method then
 
sage: G(F(G.an_element()).nice_method())
 
transfers the method to G. The trick is to find an efficient, and
seamless, way of doing this. If F is the original
CombinatorialFreeModule (with distinguished basis), then the simplest
hack would be to make __getattr__ in the class for G call the methods
of F whenever they are not defined. So something like:
 
def __getattr__(self, attr):
 try:
 return self(getattr(F(self), atttr))
 except AttributeError:
 pass
 raise AttributeError('{} has no attribute {}\n'.format(self,attr))
 
The disadvantage of this approach is that it does not respect
tab-completion and documentation, so it's probably going to be better
to play some inheritance tricks.
In terms of interface, I'd like to set up something like this:
sage: G=F.new_basis([4,5,6],basis_to_new_basis=phi,
new_basis_to_basis=psi,...)
This should accept a subset of the CombinatorialFreeModule arguments
(for example, basis_keys, prefix, ...), as well as coercions to other
bases for the module. As I said I'll try and think more about this.
This would certainly be useful for me. Let me know if it is unlikely to
be useful for others.

Another disadvantage is that, given that methods in Python are not
typed, it's impossible to make a difference between methods that
return an element of G or of elsewhere, and add coercions as
appropriate.  Hence a brute-force approach as above is likely to give
out wrong results. I believe we really need to write the wrapper
methods by hand.

The good news is that there already is infrastructure for this :-) It
works well in situations like this where there is a single parent one
wants to pull operations from through isomorphisms. Here I am
constructing a free module which is endowed with a Hopf algebra
structure by declaring it as isomorphic to the group algebra of the
symmetric group::

sage: G = SymmetricGroup(3)
sage: F = G.algebra(QQ)
sage: G = CombinatorialFreeModule(QQ, range(6), 
category=HopfAlgebras(QQ).FiniteDimensional().WithBasis().IsomorphicObjects())
sage: G.retract = F.module_morphism(lambda g: G.monomial(G.rank  (g)), 
codomain=G)
sage: G.lift= C.module_morphism(lambda g: F.monomial(G.unrank(g)), 
codomain=F)
sage: G.ambient = lambda : F
sage: G.an_element()^2
17*B[0] + 8*B[1] + 12*B[2] + 6*B[3] + 6*B[4]

This works because, once in the Sage code, it has been explained that
if G is a quotient (more generally a subquotient) of F, then a product
in G can be calculating by lifting to F and retracting back.

The following does not work yet, but it would be easy to add
appropriate methods for coalgebras in Coalgebras.Subquotients:

sage: C.an_element().coproduct()
*boom*

In general every category should eventually specify how its operation
pass to subobjects, quotients, etc.

The thematic tutorial I mentioned previously has a section with an
example like this.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

2014-11-11 Thread Nicolas M. Thiery

Dear Andrew, dear Éric,

On Tue, Nov 11, 2014 at 12:33:35AM -0800, Andrew wrote:
My comment wasn't intended as a criticism of the code or of anyone:

No worry, there was no ambiguity :-)

Down the track, what I would like to see is a way of dynamically
adding bases to a CombinatorialFreeModule without these new bases
having to be part of the sage source code. For example, it is
possible to do this in chevie.

Is this close enough from what you would want?

sage: F = CombinatorialFreeModule(QQ, [1,2,3])
sage: G = CombinatorialFreeModule(QQ, [4,5,6])
sage: phi = F.module_morphism(lambda i: G.monomial(i+3), codomain=G)
sage: psi = G.module_morphism(lambda i: F.monomial(i-3), codomain=F)
sage: phi.register_as_coercion()
sage: psi.register_as_coercion()

sage: F(G.an_element())
2*B[1] + 2*B[2] + 3*B[3]
sage: G(F.an_element())
2*B[4] + 2*B[5] + 3*B[6]
sage: F.an_element() + G.an_element()
4*B[1] + 4*B[2] + 6*B[3]

There are more details in the Sage-Combinat tutorial «Implementing
Algebraic Structures»:


http://combinat.sagemath.org/doc/thematic_tutorials/tutorial-implementing-algebraic-structures.html#tutorial-implementing-algebraic-structures

There is one main limitation: if F and G are algebras, you need to
define explicitly the product on both sides (possibly trivially by
doing the back and forth with the other side). In MuPAD, the coercion
system did automatically the right thing ...

From my quick look at the manifold code, it seems that it allows
something in this direction.

I added Eric Gourgoulhon in CC to point him to this thread.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

2014-11-11 Thread Nicolas M. Thiery

On Mon, Nov 10, 2014 at 02:47:21PM -0800, Andrew wrote:
This is probably the most sensible thing to do, and certainly seems to
be the consensus. Just for fun there are also degenerate and
non-degenerate forms of these representations.

I love 0-Hecke :-)

I'm slightly bemused, however, because I'm fairly sure that, for the
quadratic relation (T_r-u)(T_r-v), these representations do not exist
in the literature.

In similar situations, we indeed had to work out a bit the details to
get the code right with completely generic parameters :-)

Consequently, I suspect that this level of
generality will never be used. There may also be a speed penalty
because rational function fields in one variable are probably more
efficient than function fields in two variables (for type B and higher
this comment isn't relevant.). On the other hand, allowing a general
quadratic relation is probably the easiest way to support the two most
common forms of the quadratic relations: (T_r-q)(T_r+1)=0 and
(T_r-q)(T_r+q^{-1})=0.

It's only a (potential) problem if the user actually specifies generic
parameters. But in most cases, people will specify their parameters in
their own preferred form, and the calculation will happen within the
field containing those parameters. In short, the code is generic, not
necessarily the calculation.

(Btw, the same remarks apply to the implementation of the
KL-bases in sage: what we have is more general than you will find
in the literature and it automatically works for different
quadratic relations and for arbitrary coefficient rings provided
that the KL-bases are well-defined.)

Yup.

I didn't know about the HeckeAlgebraRepresentation class that is
defined in this module. I have defined a class,
IwahoriHeckeAlgebraRepresentation, that is meant to be a generic class
for defining representations of an Iwahori-Hecke algebra as
CombinatorialFreeModules. The class in root_system is mainly for affine
Hecke algebras and it is quite different to what I am doing, but even
so I am slightly uneasy about introducing a new class that has a
similar name and functionality to an existing class. It seems to me
that a better name for the root_system class is
AffineHeckeAlgebraRepresentation, at least this would help distinguish
between the two. Perhaps this code would also sit more naturally in the
new directory sage.algebras.iwahori_hecke_algebras? Is there a better
name for my class? Does anyone have any thoughts on this? (Particularly
Anne and Nicolas as this is their code...)

People have started using NSym Macdonald polynomials. But I don't
think many -- if any -- are using directly the
HeckeAlgebraRepresentation class. So feel free to move it around
and/or refactor it. It would definitely be sensible to have two
classes in the sage.algebras.hecke_algebras:

class IwahoriHeckeAlgebraRepresentation:
class 
AffineIwahoriHeckeAlgebraRepresentation(IwahoriHeckeAlgebraRepresentation):

This of course assumes (and fosters!) some common ground between the
two classes. And also assumes that your class is for any Cartan
type. If it's only for finite type, then maybe this should be instead
something like:


class IwahoriHeckeAlgebraRepresentation:
class 
FiniteIwahoriHeckeAlgebraRepresentation(IwahoriHeckeAlgebraRepresentation):
class 
AffineIwahoriHeckeAlgebraRepresentation(IwahoriHeckeAlgebraRepresentation):

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: Left and right cells of Coxeter groups

2014-11-10 Thread Nicolas M. Thiery

On Mon, Nov 10, 2014 at 02:28:15AM -0800, Andrew wrote:
OK, I have figured out how to make left cells but now the question is
where to put this?

Thanks for investigating! I guess this would be a cell method of
Coxeter groups, possibly only provided by certain
implementations. Would you have an example of input and output to
settle on the specifics?

I just made a quick grep in the sources of Coxeter 3, and there is a
file wgraph.cpp, with functions like OrientedGraph::cells. Cells are
also mentioned quite some in INTRO.tex. So for our Coxeter groups
using Coxeter 3 as backend implementation, it's probably just a matter
of wrapping those functions to make them accessible as well from
Sage. And they are likely to be very efficient given Coxeter 3's
emphasis on computing KL polynomials.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

2014-11-10 Thread Nicolas M. Thiery

On Thu, Nov 06, 2014 at 04:51:40PM -0800, Anne Schilling wrote:
 Wouldn't it make most sense to use the quadratic relation
 
 $(T_r-q)(T_r-v)=0$
 
 since the other ones can be obtained by appropriate specialization?

I definitely vote for this as well. That's what Alain always
recommended to me, and the practicality of the approach was confirmed
by our experience when implementing Non Symmetric Mac Donald
polynomials. See for example:

sage/combinat/root_system/hecke_algebra_representation.py

  In thinking about this it seems to me that currently there is no
  framework in sage for dealing with module that has more than one
  natural basis. Is this right? Of course, it is possible to
  define several different CombinatoriaFreeModules and coercions
  between them.

 Examples of how to handle this might be in
 
 combinat/ncsf_qsym

Another approach is to have a single parent, with elements having
potentially several internal representations, and coercions being
handled internally as well. That's what Éric is using in
Sage-Manifolds:

http://sagemanifolds.obspm.fr/

 put all of this code in a new directory sage.algebras.iwahoriheckeagebras/

Sounds good to me.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

2014-11-06 Thread Nicolas M. Thiery

On Thu, Nov 06, 2014 at 01:04:30AM -0800, Andrew wrote:
Yes, you're right, this is almost certainly on the roadmap. In any
case, as Nicolas and Travis are both in favour I'll try and make time
to properly wrap and prettify the code, create a ticket and push it to
git and trac or comments and review. I'll first have to think a little
harder about the best interface.I will probably end up implementing the
seminormal representations simultaneously for the symmetric groups and,
more generally, he Hecke algebras of type A, B, ..., G(r,1,n) as in the
end thee are all the same.

Nice! This might be the occasion to add a ``cartan type'' for G(r,1,n).

Yes this is a good idea, but now there are some questions.
 1. Left modules or right modules, or both? (My current methods you can
interpret as either.)

I would say both if there is no complexity overhead:

G.representation(..., side=left/right)

 2. What is the best syntax for the action?
The first question is not a big deal. For the second the following is
probably the most natural answer::
sage: A=SymmetricGroupAlgebra(QQ,3)
sage: rep=SeminormalRepresentation([2,1])
sage: a=A.an_element(); a
2*[1, 2, 3] + 2*[1, 3, 2] + 3*[2, 1, 3]
sage: r=rep.an_element(); r
2*f(1,2/3) + 2*f(1,3/2)
sage: a*r  # left action
???
 
Using a*r for the left action, and r*a for the right action, seems to
be the natural syntax. Is there already a mechanism in place for doing
this? I assume that there is, but I don't know it. Can some one point
me in the right direction?

I would do like in math: define first a notation which makes the
representation explicit, and then, if there is an ambiguity from the
context define a shorthand.


So, if you think of rep as a module, this could be:

rep.action(a, r)

Alternatively, if you think of rep as a representation, this could be:

rep(a)(r)

Then we can optionally setup the following as syntactic sugar:

a*r or r*a

However multiplication is already overloaded quite some, so it's not
even clear we want this as a default.

In all my semigroup representation code, I have used rep.action(a,r)
systematically. One further advantage is that the notation is
side-agnostic; so we can write code on top of it that does not depend
on whether we have a left or right action.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

2014-11-05 Thread Nicolas M. Thiery

Dear Andrew,

On Mon, Nov 03, 2014 at 07:23:32PM -0800, Andrew wrote:
Sorry, this is a longish post...

Just a short answer for now: it's been in the TODO list for a while to
have representation matrices for the Hecke algebra (there might be a
ticket about this, and almost certainly a note in the road map). So
progress in this direction is surely welcome, especially if this can
be done uniformly for symmetric groups versus hecke algebras and type
A versus generic type.

By the way, this could be an occasion to make those methods of the
symmetric group / hecke algebra. Something like:

sage: SymmetricGroup(5).representation([3,2], seminormal)

As for speed: do you think the limitation comes from the cost of the
arithmetic in the base field, or from the linear algebra?

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: Sage grant

2014-10-30 Thread Nicolas M. Thiery

On Wed, Oct 29, 2014 at 07:09:53PM -0700, Andrew wrote:
I agree with Dima in that it would be great to have some of the basic
ring theory available in improved. There are some basic deficiencies
with (Laurent) polynomial rings, especially in more than one variable
and it would great if all of the problems with quite basic rings could
be ironed out. In addition, my life would be much easier if sage were
able to efficiently compute in the location of a ring at a ideal --
what I would really like is to be able to calculate in modular systems
with parameters, which is my way of saying that I would like to be
able to explicit calculations in modular systems for Iwahori-Hecke
algebras. Implementing all of these gadgets is, perhaps, not so
exciting from the point of view of a grant application, but not having
these basic ring constructions available limits what you can currently
do with sage.

+1. The big question here is whether we have someone with both the
expertise and time to implement those features, and whether the grant
could help provide us such a person ...

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.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] #16256: Refactorisation of the indexes of the combinatorics documentation

2014-09-03 Thread Nicolas M. Thiery

Hi,

This is just to advertise #16256 which reorganize the various index
pages of the sage.combinat documentation to be closer to the
sources. For example, the thematic index:

src/doc/en/reference/combinat/crystals.rst

is now in:

src/sage/combinat/crystals/__init__.py

and is accessible through:

sage: sage.combinat.crystals?

Among other advantages (see the ticket for details), this makes the
indexes more flexible. For example, when natural, one can reference a
given piece of doc from several spots, or reference docs from
elsewhere in the reference manual. The end result is browsable from:

http://sage.math.washington.edu/home/nthiery/sage/src/doc/output/html/en/reference/combinat/index.html

I would appreciate feedback on:

- Whether this sounds reasonable from a user point of view

- Whether this sounds reasonable from a dev point of view

- Possible improvements to the indexes themselves (e.g. more cross
links, better classification, ...)

For those that maintain some of those indexes (e.g. Travis for rigged
configurations), I would appreciate if you could double check that
they look good and that nothing was lost in the process, and notify
this on the ticket.

Thanks in advance!

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] #16256: Refactorisation of the indexes of the combinatorics documentation

2014-09-03 Thread Nicolas M. Thiery

On Wed, Sep 03, 2014 at 08:27:26AM -0700, Anne Schilling wrote:
 It does not seem to be there

Thanks for the report. It's back there. It was in the middle of a slow
running make doc-clean; make doc ...

Hmm, I should maybe just come back to a good old rsync for updating
the doc out-there. It's more network intensive but more reliable and
atomic.

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.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: [sage-devel] Re: quiver algebra

2014-07-12 Thread Nicolas M. Thiery

On Fri, Jul 11, 2014 at 09:42:15PM +, Simon King wrote:
 +1
 
 There is a method .homogeneous_component(d). Maybe there should be a
 method .homogeneous_component_iter(), iterating over them. But the
 default iterator should iterate over elements.

Ok!

 Shouldn't it be the job of CombinatorialFreeModule to provide a generic
 iterator, relying on the iterators over the base ring and the indexing
 set for the basis? This is currently missing.

Yes. Or probably Modules.WithBasis.FiniteDimensional.Finite. Well, we
also need the base ring to be enumerated, but the category for modules
over an enumerated set. Hmm, we could even just have
Modules.FiniteDimensional inherit from CartesianProduct(...); but
until we have CartesianPower, that probably would be memory
inefficient (since we would need to store the list [R,...,R] of the
cartesian factors).

I'll think about this if this can fit in #1.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: Extednding tableaux

2014-07-11 Thread Nicolas M. Thiery

On Thu, Jul 10, 2014 at 09:25:05AM -0700, Travis Scrimshaw wrote:
On Thursday, July 10, 2014 7:11:52 AM UTC-7, Andrew wrote:
 
I have this vague memory that some one was thinking of
extending/rationalising/reorganising the tableaux code so that it
fitted together better (whatever this might mean:). Does this ring any
bells with anyone?
I ask because I think that I need to implement row standard tableaux
(possibly of composition shape).

Attached are some notes we had taken together when we discussed last
year in Tour.

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.
For more options, visit https://groups.google.com/d/optout.
# Abstract classes
class WordLikeObject:
@abstract_method
def evaluation(self):
pass

class AbstractSkewTableau(WordLikeObject):
@abstract_method
def skew_shape(self):
pass
@abstract_method
def rows(self):
pass
@abstract_method
def columns(self):
pass
# access to cells by coordinates
# ...
# Generic methods based on the above accessors
class SemiStandardAbstractSkewTableau(AbstractSkewTableau):
# Crystal operators, ...
class StandardAbstractSkewTableau(SemiStandardAbstractSkewTableau):
# ...

# Concrete classes
class SkewTableau(AbstractSkewTableau):

Defines the data structure for skew tableaux, and low-level
methods on this data structure

def shape():
# ...
skew_shape = shape
def rows():
# ...
class SemiStandardSkewTableau(SkewTableau, SemiStandardAbstractSkewTableau):
# Probably unneeded
class StandardSkewTableau(SemiStandardSkewTableau, StandardAbstractSkewTableau):
pass

class Tableau(ClonableArray?, AbstractSkewTableau):

Defines the data structure for tableaux, and low-level methods on
this data structure

def shape(self):
pass
def skew_shape(self):
return [[], self.shape()]

class SemiStandardTableau(Tableau, SemiStandardAbstractSkewTableau):

Might want to use a different data structure, based on ClonableIntArray

In this case might not want to inherit from Tableau, or introduce
an AbstractTableau class.

class StandardTableau(SemiStandardTableau, StandardAbstractSkewTableau):
pass

[sage-combinat-devel] quiver algebra

2014-07-11 Thread Nicolas M. Thiery

Hi path algebra fans!

I am having doctests failures in #8678 because of the following
feature of quiver path algebras:

sage: P = DiGraph({1:{2:['a']}, 2:{3:['b']}}).path_semigroup()
sage: A = P.algebra(GF(7))
sage: A.list()
[Free module spanned by [e_1, e_2, e_3] over Finite Field of size 7,
 Free module spanned by [a, b] over Finite Field of size 7,
 Free module spanned by [a*b] over Finite Field of size 7]

And indeed ``A.__iter__`` states that it iterates over the homogeneous
components of A. This sounds bad, since the general convention for
parents is to have __iter__, list, ... iterate over its elements.  And
indeed some code that makes this assumption explodes.

Can we just rename this feature? Is it actually useful?

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.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: quiver algebra

2014-07-11 Thread Nicolas M. Thiery

On Fri, Jul 11, 2014 at 09:42:11AM -0700, Travis Scrimshaw wrote:
   I would say this is like matrices: do you want the iterator for
matrices to iterate by default over all elements or rows? Currently the
iterator goes over all rows and you can call M.list() to get a flat
list of entries.
   Actually, this is a question for graded objects in general: should
the default iterator go over each graded component or all elements? I
would say there should be methods for both. My thought is the default
iterator being over graded components since each component might be
infinite, but I don't have a good/strong opinion/reason for this.

Right, though the difference is that containment for a matrix does not
have a strong mathematical meaning. On the other hand, when we speak
of a parent - that models some mathematical set like an algebra, the
notion of containment is unambiguous; it's about the set w.r.t its
elements. Furthermore, whenever we model a set in Python by some
collection, it's expected that containment and iteration are about the
same notion. In particular:

sage: all( x in S for x in S )
True

So I would find quite unnatural to have:

sage: Partitions(4) in Partitions()
True

On the other hand,

sage: Partitions(4) in Partitions().graded_components()

or

sage: for Pk in Partitions().graded_components()

would look natural.

So, what shall we do with this feature of quiver algebras?

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] About nested functions not showing up in the doc

2014-06-11 Thread Nicolas M. Thiery

On Wed, Jun 11, 2014 at 11:16:17AM +0200, Nathann Cohen wrote:
Hello everybody !
Vincent implements in #16464 a method for Rings, which is located
inA Rings.Finite.ParentMethods.cyclotomic_cosets [1].
Trouble is, this function does not appear in the html documentation and I
remember Nicolas having said something about that, like Sphinx does not
print too deeply nested functions.
Given that you are the absolute kings of over-nesting stuff, it means that
a lot of Sage's functions do not appear in the doc. What have you tried on
this front ? Have you, for instance, written something to the Sphinx guys
? Do you have any plans to make those functions appear ?
You can of course get the documentation from inside of Sage, but not
through google, and that's a pity.

That's #9107, it just takes pushing through some technical latex
issue according to plan stated on sage-devel ... I hope to have the
time for this at some point, unless someone beats me to it!

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-combinat-devel] Re: redesign combinatorial statistics

2014-05-30 Thread Nicolas M. Thiery

On Thu, May 29, 2014 at 11:28:58PM +0200, Paul-Olivier Dehaye wrote:

E.g. when a
  borderline feature is meaningful in the context of Sage, is useful
  for a sister project, but does not yet have a direct use case
  within Sage ...

Correct me if I am wrong, off the top of my head:
Assuming the findstat people start adding information about which maps
are bijective, can't one automatically create new tests, testing two
methods at once?
Assuming the findstat people start adding information about the ranges
of maps, can't one automatically create new tests, testing that the output
of a method is what it should be? (e.g. no [5,4,2] that is supposed to be
a Partition but is in fact a list).

I guess we could. I am not sure to see your point though. Is it that a
potential direct use case within Sage would be to exploit this
semantic information to do more automatic testing which in turn would
contribute to make Sage more robust?

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

2014-05-29 Thread Nicolas M. Thiery

On Thu, May 29, 2014 at 11:42:40AM +0200, Nicolas M. Thiery wrote:
 Here is the description of http://trac.sagemath.org/ticket/16410,
 which potentially needs review:
 
 --
 From the discussions of (TODO: add refs to the threads in sage-devel), there 
 is a consensus that, at this point, the combinatorial_map decorator should by 
 default return the decorated method as is, in order to have no impact on 
 speed. On the other hand, projects built on top of Sage, like findstat are 
 welcome to customize locally this hook to instrument the Sage code and 
 exploit the semantic information provided by this decorator.
 
 This ticket therefore:
 
 Defines combinatorial_map as a no-op
 Discuss the purpose of this decorator
 Uses the previous implementation as an example of how to customize 
 combinatorial_map 
 
 Note: this change is slightly backward incompatible since 
 combinatorial_maps_in_class is not functional any more by default.
 --

Vincent on #16410:
 ...this ticket can be reviewed quickly compared to #16408 (which
 needs some design discussions). We can let this one go and then
 start discussing #16408 but I think we need more opinions on this.

Nathann, Christian, Viviane, ... do you mind briefly stating on the
ticket whether this sounds like a reasonable step forward?

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

2014-05-29 Thread Nicolas M. Thiery

 On Thu, May 29, 2014 at 10:02 PM, Nathann Cohen nathann.co...@gmail.com
I can hear your frustration ... In similar situations, it helped me to
keep in mind that loud people are not always representative. Of course
the difficulty is to fetch the opinion from the others.
 
 Ahahahahahahah. Well, only including in Sage code that is useful to a
 Sage user or other developpers does not seem that far-fetched. I
 still do not see what the problem is with that.
 Err Well, assuming the obvious : that I am the loud people you
 mention.

Sorry, I should have clearly separated the two topics. My point was
about (1) below.

(1) When a Sage developer believes in his heart that something is the
right thing to do for Sage, (s)he should not get discouraged by
loud opposition without first reaching for the opinions of a
larger pool of developers.

Btw: there are more than one loud people :-) Actually I also put
myself in there, as the graded algebra with basis discussion from
the other month shows ...

(2) About ``only including in Sage code that is useful to a Sage
user or other developpers''. In principle, yes, sure, I
agree. Still there can be legitimate complementary point of views
and discussions about where to put the limit. E.g. when a
borderline feature is meaningful in the context of Sage, is useful
for a sister project, but does not yet have a direct use case
within Sage ...

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] combinatorial statistics

2014-05-26 Thread Nicolas M. Thiery

Hi Christian,

On Mon, May 26, 2014 at 09:08:14AM +0200, Christian Stump wrote:
 Let me add that I was thinking of opening a ticket to remove
 combinatorial maps from Sage again (in the medium time future) simply
 because the negative comments about it were louder (and I am currently
 not in the position to be able to spend much time on stuff I don't
 need for my research).

I also won't spend time on arguing about this. Let me just recall my
personal position, for whatever it's worth.

I like having such semantic information in the code, and I am fine
with having it even if we don't yet have a strong use case within
Sage. The only prerequisites are:

- Not having an impact on performance (IIRC that's the case with
  combinatorial maps)

- Not adding functions in the code unless they are actually useful in
  Sage and have a clear mathematical meaning.

 So if you have some use cases for combinatorial maps, please write
 about it so such cases are also visible.

+1

By the way: I second being able to programmatically search for
combinatorial statistics, be it through a remote call to findstat.org,
or by running locally a findstat search engine.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: sum(Composition([1,2,3])) # broken

On Tue, May 20, 2014 at 11:50:30AM +0200, Vincent Delecroix wrote:
 I agree with Nathan that .sum must be changed. IMHO I would
 - remove sum from the element Composition

+1

 - move the sum from the category CommutativeAdditiveMonoids to AdditiveMagmas

With #10963 (which is merged!), sum has already been moved in
AdditiveMonoids. A version not using the zero (and supporting only non
empty lists) could possibly be added to AdditiveSemigroups. I am not
sure I want to define sum if the addition is not associative (for
multiplicative magmas, prod is only defined in the associative case).

 - Turn the parent Compositions into an additive monoid
 
 That way, the old behavior of sum can still be used through
 {{{
 sage: Compositions().sum([Composition([3,2,1]), Composition([1,2])])
 [3, 2, 1, 1, 2]
 }}}

+1. Or maybe instead into a multiplicative monoid? I don't have a
strong opinion either way, but we should take a consistent decision
here with words and other word-like objects supporting concatenation.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: sum(Composition([1,2,3])) # broken

On Tue, May 20, 2014 at 09:54:28AM +, Simon King wrote:
 On 2014-05-20, Nathann Cohen nathann.co...@gmail.com wrote:
  What the hell is add ? I did not even know this thing existed !
 
 It is a Python builtin, in contrast to sum, which is defined somewhere
 in sage.misc.

To be fair, `add` does not seem to exist in plain Python. If I read it
right, for whatever it's worth, Sage adds it as an alias for Python's
__builtin__.sum:

sage: add is __builtin__.sum
True

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: sum(Composition([1,2,3])) # broken

On Tue, May 20, 2014 at 03:25:34AM -0700, Simon King wrote:
It would have been a much better longterm solution to keep
__builtin__.sum(). Sage may have its own summation method, but please not
overriding a Python builtin. Give Sage's sum() a different name!

I definitely can see your point. Yet that's how things have been for a
long time, and `sum` is probably being used intensively for symbolic
summation by a wide array of people (teaching, ...). Such a backward
compatible change would require a discussion on sage-devel.

In the mean time, we can implement the other approach since it makes
sense anyway.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: sum(Composition([1,2,3])) # broken

On Tue, May 20, 2014 at 01:31:27PM +0200, Nathann Cohen wrote:
Sorry but I lost you again. How can we fix this sum problem ? It seems
to have triggered discussions on the additive law among Composition
instances.

Which will be rather trivial to fix once we have settled the decision
on additive or multiplicative notation.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] sum(Composition([1,2,3])) # broken

2014-05-19 Thread Nicolas M. Thiery

On Mon, May 19, 2014 at 04:29:44PM +0200, Vincent Delecroix wrote:
 Not because of Composition but because of sum
 
 sage: import __builtin__
 sage: __builtin__.sum(Composition([1,2,3]))
 6

That being said, since Composition seems to be the single
combinatorial object having a sum method, we could think of renaming
it to something more appropriate that would not conflict with Sage's
sum syntax and semantic. What's the syntax for n-ary concatenation of
words?

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: sum(Composition([1,2,3])) # broken

2014-05-19 Thread Nicolas M. Thiery

On Mon, May 19, 2014 at 04:01:52PM +, Simon King wrote:
 Multiplication? I always think of words as elements of a free group, of
 course multiplicatively written. Hence, concatenation of words w1,...,wn
 would be prod([w1,w2,...,wn]).

Indeed.

`+` works too for concatenation of words, which is consistent with
Python strings. But sum does not. Oh well.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: CombinatorialFreeModule

2014-05-17 Thread Nicolas M. Thiery

Hi Bruce,

On Sat, May 17, 2014 at 12:29:54PM -0700, Bruce wrote:
I changed this to
 
class Foo(Element):
def __init__(self, a):
self.data = a
Element.__init__(self, Foos)
 
which seems a bit simpler as we still have Foo(1) without an extra
argument.

Notes:

- this should be `Foos()`, rather than Foos

- elements are more often than not constructed from their parent as:

  sage: F = Foos()
  sage: F(data)

  In this situation, both the parent and the data is passed to the
  constructor of the element class.

- In case your data structure consists of a single value, you can use
  ElementWrapper which does exactly the above __init__ for you
  together with some other goodies. For an example, see

sage: S = Semigroups().example()
sage: S??

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] CombinatorialFreeModule

2014-05-16 Thread Nicolas M. Thiery

On Fri, May 16, 2014 at 08:04:11AM -0700, Bruce wrote:
On Friday, 16 May 2014 14:54:32 UTC+1, Viviane Pons wrote:
 
  I think the Foo class must also inherit from the Element class.
 
If I change the first line to
 
class Foo(Element, UniqueRepresentation):
 
then when I create an instance and look at it I get
 
Generic element of a structure

That's fine: that's what the default _repr_ method returns for
Element's. You can implement your own.

By the way: usually an element class need not inherit from
UniqueRepresentation (but there are use cases).

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] CombinatorialFreeModule

2014-05-16 Thread Nicolas M. Thiery

Hi Bruce,

On Fri, May 16, 2014 at 06:50:35AM -0700, Bruce wrote:
While I am here: I am constructing an infinite dimensional representation
of an algebra.
This means the next step for me is to construct operators on this vector
space (one for each integer)
and these operators will satisfy the Temperley-Lieb relations.
 
I want to define each operator on the basis and then extend by linearity.
 
Is there an existing category I could/should be using?

At this point (and except for the standard case of a vector space
endowed with the action of the scalars) we only have experimental
category code for spaces endowed with an action of an
algebra/group/... I'd say you can just use the category
ModulesWithBasis for your vector space, and define your operators as
a bunch of morphisms constructed using module_morphism.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] gfun in sage?

2014-05-13 Thread Nicolas M. Thiery

Hi Franco!

On Tue, May 13, 2014 at 02:57:59PM -0400, Franco Saliola wrote:
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/

I haven't played seriously with it, but Manuel Kauers (in CC),
Maximilian Jaroschek, Fredrik Johansson, have developed a package that
includes guessing facilities:

http://www.risc.jku.at/research/combinat/risc/software/ore_algebra/doc/guessing.html

The more people play with it, the better! I guess the author would
appreciate any feedback and help toward getting this package
progressively into Sage.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct

On Wed, Apr 30, 2014 at 08:12:33AM +0200, Nathann Cohen wrote:
Well, if you find the question justified, of course the answer should be
in the doc.

My point was not about the existence of the answer, but the way I
wrote it :-) Was it helpful?

There is also the problem of these __add__ and _add_. From just
looking at the names you have no idea what the difference is,
except if you wrote the code yourself.

This is about the coercion system, which has been in Sage since 2008
or so. When I joined Sage and started implementing elements, I found
the information by reading the documention of
sage.structure.element. Now we have Simon's very nice thematic
tutorial How to implement new algebraic structures in Sage, which
explains this in details.

If you believe the names should be changed, open a thread on the
subject on sage-devel.

HMmm... Yeah, but it contains a class CartesianProductsCategory Why
shouldn't it be taken as the definition of the CartesianProductCategory
from which all other will inherit ? Thus, why shouldn't it be taken as THE
place to implement things like .an_element() or .cardinality() ?

If we put everything about cartesian products in a single spot, we
will end up, for example, with a bunch of irrelevant methods (like
one, product, ...) when we construct a plain cartesian product of
sets. The whole point of the current infrastructure is that when you
make a cartesian product of blahs, you get exactly the cartesian
product methods relevant to blahs. Once this infrastructure is in
place, there is no reason to make a special case for an_element or
cardinality, even though they indeed be around whatever blahs is.

It's by going in this kind of direction that we will finally get rid
of all those irritating irrelevant methods that we find in so many
Sage objects (e.g. Set([1,2,3]).base_ring()).

 - Vector spaces are already endowed with their addition. Sounds like
 A  you accidently overrode it.
HMmmm... I don't get it. CommutativeAdditiveGroup is more general than
vector spaces, so if something is a vector space it should inherit all
addition functions from vector spaces, shouldn't they ?

That's the general principle indeed; I would need to see the code to
find out what went wrong precisely.

 - Using .value directly breaks encapsulation and is thus
 A  implementation dependent.
Yeah but I needed to iterate over all the coordinates of an element of a
cartesian product. Does it mean that I should instead implement an
__iter__ in the ParentMethods of the category they belong to ?.. I'll try
that 

I would iterate through x.cartesian_factors():

sage: C = cartesian_product([GF(3), GF(5)])
sage: x = C.an_element()
sage: x.cartesian_factors()
(0, 0)
sage: for i in x.cartesian_factors(): ...

or its equivalent pre #10963; I don't remember the name, but see:

sage: c.tab

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Should the element of a Parent be Elements ?

On Wed, Apr 30, 2014 at 09:23:41AM +0200, Vincent Delecroix wrote:
 FiniteEnumeratedSet is aimed to not modify the input it gets. So if
 you feed it with Python objects which are not elements it will not
 complain and you have to go with that.

Yup. We would want to properly support facade FiniteEnumeratedSets
over plain Python objects and in particular have:

sage: F = FiniteEnumeratedSet([a,b,c])
sage: F(a)
a

However the coercion system currently does not support facades over
plain Python objects. That's essentially just because

sage.structure.coerce_maps.DefaultConvertMap._call_

(which is what Parent.__call__ defaults to if there is no coercion)
specifies that its return value should be an Element.

That has been irritating me for a while, but I am not sure what's the
right fix.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Should the element of a Parent be Elements ?

On Wed, Apr 30, 2014 at 12:22:41PM +0200, Nathann Cohen wrote:
 Okay... Then would it make sense to make things like
 FiniteEnumeratedSet behave as if they were real parents, for
 instance by implementing the __call__ function manually (or let it be
 inherited from Facade or whatever it is) so that F(a) works ? It is
 not like you need to change coercion code to  make this work ?...
 
  That has been irritating me for a while, but I am not sure what's the
  right fix.
 
 So what about this way out ?

That's indeed one way out I considered. But this means that this
parent won't honor coercions. Possibly we don't care.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct

On Wed, Apr 30, 2014 at 12:19:41PM +0200, Nathann Cohen wrote:
Not my job.

Nor mine in the case of coercion and the _..._ methods :-) Because I
already spent a lot of time on some pieces of the Sage infrastructure
does not mean I (or anybody on sage-combinat-devel) am responsible for
all of it. Which is why I suggested to report and make your case on
sage-devel.

No, the one thing does not belong to CartesianProduct because it does
not apply to everything. I was just wondering about
category/cartesian_product and sets/cartesian_product. Those two A files
seem to address all cartesian products of everything (and this everything
is always a set, isn't it ?)

Indeed. Still, see my comment about the value of not making a special
case for those methods.

The current Sage *IS* pre-10963. And I hope that you have
summand_projection in mind for it is what I used in #16269.

Certainly.

Thanks for your answers.

Your welcome.
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.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct

Hi Nathann,

On Tue, Apr 29, 2014 at 01:50:42PM +0200, Nathann Cohen wrote:
I need your help for something that I spent all of today (around six 6
hours) trying to do, and I can't. And I tried. So please, help me.

Sorry, I was offline this morning. I just got your message saying you
had fixed most of the issues in the mean time, but since this might be
of general interest here is what I had already typed down.

I am trying to use cartesian products of groups in Sage, and I cannot
implement what I want because of the following problem :
 
sage: GG = GF(2).cartesian_product(GF(2)); GG([2,2])
[2, 2]
 
in Z/2z x Z/2Z, you naturally expect the answer to be (0,0).
 
But it isn't, because the entries of [2,2] are not converted into elements
of the cartesian product I defined.

Yeah, we had discussed this issue a couple months ago; see #15425. The
fix is indeed to change _element_constructor_. Since this is about the
construction of elements, this belongs to the concrete class, not the
category. In this case:

sage.sets.cartesian_product.CartesianProduct._element_constructor.

Which you can get with:

sage: C = cartesian_product([GF(2), GF(2)])

Throwing your _element_constructor_ code there should do the job.

Ah, I see what must have been confusing: the default implementation of
_element_constructor_ is provided by the Sets category:

sage: C._element_constructor_.__module__
'sage.categories.sets_cat'

Hmm, by the above reasoning it should probably be in Parent
instead. Hmm. Opinions anyone?

 Autre question : quand j'ai voulu expliquer au code que le
 cartesianproduct d'un AdditiveCommutativeGroup était un
 AdditiveCommutativeGroup, au debut quand je faisais des tests il
 faisait comme s'il n'avait rien entendu, et il ne faisait rien, même
 quand j'appelais explicitement la fonction
 AdditiveCommutativeGroup().CartesianProduct().extra_super_categories().

Do you have the code on some branch? I guess the issue is some typo,
like a missing s to CartesianProducts. Similarly,
CommutativeAdditiveGroups.

 Autre question : quand j'ai un objet CartesianProduct, comment je
 recupere la liste de ses composantes, qui sont normalement des
 parents ?

Introspection is the tool of choice to recover this kind of
information. From looking at:

sage: C = cartesian_product([GF(2), GF(2)])
sage: C??

or from the code of

sage: C.one??

one can find that there is an internal attribute `_sets` for this, and
a shorthand `cartesian_factors` to recover them. Pre #10963, this was
called `summands` but I was asked to change it. Wait, wait, wait, I
thought we had put a backward compatibility alias, but I can't find
it. I'll fix that now.

In your case it's fine to use the attribute.

Thanks for your work on this!

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct

On Tue, Apr 29, 2014 at 03:48:37PM +0200, Nathann Cohen wrote:
Yeah, I found it. I don't remember how, but I did. There is a branch at
u/ncohen/tmp which implements the _element_constructor_ I needed, plus
order/cardinality.

I checked it out; at first glance, the issue is that
element_constructor returns a tuple not an instance of the cartesian
product. I can commit a fix in an hour or so.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct

On Tue, Apr 29, 2014 at 04:57:37PM +0200, Nicolas M. Thiery wrote:
 I checked it out; at first glance, the issue is that
 element_constructor returns a tuple not an instance of the cartesian
 product. I can commit a fix in an hour or so.

Well, that was a long hour. But it's now on u/nthiery/cartesian_product.

I have added the tests for list and cardinality, but not yet for
element_constructor, so I don't yet guarantee correctness.

I am hesitant on whether _element_constructor should always directly
coerce the elements, or first check if they are already in the right
parent and if not call coercion.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct

On Tue, Apr 29, 2014 at 05:19:32PM +0200, Nathann Cohen wrote:
 At some point I created a function called a in a Parent which just
 printed a line, called it, and the result was :
 1) The line was printed
 2) An attribute error because some other category I had never heard
 about did not implement such a method

Strange. If you can reproduce the example I'd be happy investigating
it.


 I asked Nicolas if there was some caching of the categories hierarchy
 that was not automatically rewritten when I run sage -b.

No. Everything is lazily rebuilt from the code in each Sage session.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct

On Tue, Apr 29, 2014 at 08:17:44PM +0200, Nathann Cohen wrote:
 Why did you have to move the code around, though ?
 What is the difference between sets.cartesian_product and
 categories.cartesian_product ?

disclaimer
My answer is most likely going to be a bit broad and include stuff you
already know; I am just taking the occasion to write a blurb that
could possibly end up somewhere in the documentation (typically as a
complement of cartesian_product?), if someone finds it useful.
/disclaimer

There can be several ways to represent an element of a cartesian
product. The natural implementation is using a tuple (well, a wrapped
tuple). That's what the concrete class in
sets.cartesian_product.CartesianProduct does::

sage: C = cartesian_product([GF(3), GF(5)])
sage: type(C)
class 'sage.sets.cartesian_product.CartesianProduct_with_category'
sage: C.an_element()
(0, 0)

But if you start from vector spaces it's natural to think of the
cartesian product as a direct sum, and therefore represent the
cartesian product by a vector space:

sage: X = CombinatorialFreeModule(QQ, ['a','b']); X.rename(X)
sage: Y = CombinatorialFreeModule(QQ, ['c','d']); Y.rename(Y)
sage: C = cartesian_product([X,Y])
sage: C
X (+) Y
sage: type(C)
class ...CombinatorialFreeModule...

This vector space has a basis indexed by the disjoint unions of that
of X and of Y::

sage: C.basis().keys()
Disjoint union of Family ({'a', 'b'}, {'c', 'd'})
sage: C.an_element()
2*B[(0, 'a')] + 2*B[(0, 'b')] + 3*B[(1, 'c')]

So that's a second concrete implementation of a cartesian
product. There could be others (e.g. one could represent the cartesian
product of two permutation groups as a permutation group).

That's for the concrete classes. Then, you have generic code that
works in all cases (say an_element, one). This code goes in the
relevant abstract classes in the category. For example the code for
`an_element` is something about parents that are cartesian products of
sets; so it goes in the abstract class
Sets.CartesianProducts.ParentMethods. On the other hand `one` is about
monoids (in fact unital magmas), so it goes in
Monoids.CartesianProducts.ParentMethods (in
Magmas.Unital.CartesianProducts.ParentMethods after #10963).

The last player in the game is the `cartesian_product` object, as in
`cartesian_product([A,B,...])`. Its role is to look at the properties
of A,B,..., and decide on an appropriate concrete implementation and a
category. Technically, this object is a covariant functorial
construction and it's implemented in
sage.categories.cartesian_product. In practice, unless one wants to
use it as an example to create a new construction, there is no reason
to fiddle with it.

 Cool. I am trying to clean the CartesianProduct stuff of additive
 groups and it does not look good. The methods are not inherited from
 where they should -_-
 
 Right now, my problem is that the __add__ method from a
 CombinatorialFreeModule is taken from my CommutativeAdditiveGroup.
 And I thought I could expect all those objects to have a .value
 argument, but apparently I can t _

The three points you probably are hitting here are:

- It's best to implement _add_ rather than __add__ (__add__ builds on
  _add_ and takes care of coercion for you). Equivalently you can
  implement the method 'summation' in the parent (that's what done for
  the product).

- Vector spaces are already endowed with their addition. Sounds like
  you accidently overrode it.

- Using .value directly breaks encapsulation and is thus
  implementation dependent. Instead, have a look at some generic
  method that manipulates an element of a cartesian product and see
  how its pieces are recovered there. E.g.:

sage: C = cartesian_product([GF(3), GF(5)])
sage: C.product??

Let me know if you would want me to have a look at the code.

 Okay, so I will try to see if I can guarantee correctness when you can't.

I just meant the usual caveat not tested=likely to be broken.

  I am hesitant on whether _element_constructor should always directly
  coerce the elements, or first check if they are already in the right
  parent and if not call coercion.
 
 Well, your pick. I barely understand what the dilemma is about :-P

Just about the if line I commented out in your code. Maybe it should
really be there. Or we should do a separate `if` for each set.

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.
For more options, visit

Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct

On Tue, Apr 29, 2014 at 03:48:37PM +0200, Nathann Cohen wrote:
 Do you have the code on some branch? I guess the issue is some typo,
 like a missing s to CartesianProducts. Similarly,
 CommutativeAdditiveGroups.
 
A typo ? But I would get some meaningful error in this case, not this,
would I ?

Not necessarily. As a lousy analogy, imagine I want to implement a
special class of graphs, and want to override, say,
is_vertex_transitive with my super great algorithm; but I
inadvertently spell it as is_vertices_transitive. I won't get a
specific error about it.  If the user calls is_vertex_transitive, my
great implementation is going to be silently ignored.

Of course, in some cases there can be tricks to catch such typos and
report them. For example the code could possibly complain if you
implement, and then call, a construction in a category where it has
not been defined (that's done for axioms, but maybe not yet for
constructions like CartesianProducts).

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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct