On Sun, Jun 21, 2015 at 10:18:27PM +0000, Simon King wrote:
> Exactly. This is what I thought it would do. And the point is: Undocumented
> assumptions are made on {b_i: i \in I} or I. It isn't enough that I
> is a container.
>
> For example, it is assumed that you can call I to create an element
> (hence, it seems that you want I to be a Parent).
I checked the documentation and code, and indeed it's ambiguous. The
index set is really meant to be a parent; for example there are tests
such like I in Sets().Finite() and the dimension method calls
`cardinality`. As a syntactic sugar, lists or tuples are converted to
a `FiniteEnumeratedSet`.
At this point, it would indeed be better to document that `I` shall be
in Sets() (i.e. basically be a parent), or be a finite iterable that
will be converted to a FiniteEnumeratedSet (and implement things
accordingly).
And then we could think whether there are compelling enough use cases
to to relax those constraints a bit.
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.
