Hello all,
>> I would think S.index(x) would be more intuitive to a non-
>> combinatorist like me.
I agree. I am well aware that 'rank' and 'unrank' are very common in
some places, but I found them non-intuitive at first. I would prefer
something like index/[] which I find more natural. (This may be a place
where two names, one which the specialists don't want to give up and
another for the non-specialists, are appropriate.)
>> Do I understand correctly that these are sets enumerated by
>> an indexing set (e.g. of natural numbers)? I vote for EnumeratedSets,
>> or IndexedSets.
>
> Actually, the problem is that in many cases, we don't always know how to
> directly access to the n-th element, without enumerating the previous one. So
> that in this case, we don't want to stress the indexed access. Maybe in this
> case, we should not implement index at all...
As I understand you, the problem with the 'stupid' unrank function is we
don't want users doing something like:
P = Partitions(50)
for i in range(P.cardinality()):
p = P[i]
# do stuff
which might be exponentially slower than
for p in P:
# do stuff
One way to mitigate this a little bit could be to have index cache it's
most recent call. Then it can always check if the cached value is an
immediate predecessor of the current one, in which case it would just
call .next. Obviously, this doesn't solve all the problems (.next might
not exist, for example), but for small to medium-sized sets (where
efficiency is not an issue) I think having this functionality is
definitely better than not having it.
>> (Countable|Enumerable)Sets would be descriptive for a datastructure
>> without indexing function.
>
> Ok. This is by far the most common case. I'd rather use: EnumerableSets which
> is in my mind closer to the idea of iterating...
>
>> IterableSets does not capture the fact that there is a indexing
>> structure,
<SNIP>
>
> I would agree except that for most case, we don't know-how/take-the-time-to
> implement rank/unrank or index/[]. Moreover, as far as I know, most of the
> time the only application to unrank/[] is to draw at random an element with
> uniform probability...
>
Of course, as I said above, if we have an iterator, there is always the
naive implementation.
<SNIP>
>> I would be happy if an EnumeratedSets
>> class in Sage reclaimed the term "enumerated" to mean that
>> the sets are actually enumerated by an indexing function, and
>> which are enumerable but not necessarily finite.
>
> So if I understand your proposal, you want us to be very precise, depending
> on the fact that we implemented or not rank/unrank:
>
> IterableSets or EnumerableSets when we don't know/want to implement
> rank/unrank.
> EnumeratedSets when we do...
>
> Right now we avoided that because the most common case of EnumeratedSets, we
> implement unrank (n -> object) but not (object -> n). So that we want to avoid
> combinatorial explosion of names. They are a *lot* of different combinatorial
> structure. And we simply can't implement all functions for all these
> structures.
I agree strongly that there should not be two separate names; often the
initial implementation of a class would not contain the smart indexing
function, but a later enhancement could change that. So I'll give my
+1 to EnumeratedSets, with index/[] implemented in a naive way by default.
>
>> I would also like to see a class which is generally useful
>> throughout Sage, as the default return type for many different
>> finite or enumerable structures.
>
> I'm sorry but I don't understand what you mean by this sentence. Can you give
> an example, please ?
I could be wrong here, but I think David just was saying that whatever
we come up with for "EnumeratedSets" it should make sense in a general
(ie beyond combinatorial) setting. :)
Cheers,
Jason
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
