#13982: rewrite sage.combinat.combinat.unordered_tuples using
itertools.combinations_with_replacement
-------------------------------------+-------------------------------------
Reporter: nbruin | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: minor | Milestone: sage-6.5
Component: combinatorics | Resolution:
Keywords: | Merged in:
Authors: Travis Scrimshaw | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/combinat/rewrite_unordered_tuples-13982|
3c0c50adb02c5046a9b26273498c1f56eee9385e
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by darij):
The "native" implementation of `tuple` is recursive, and with the current
implementation it passes the string `'native'` to itself a zillion times.
Am I seeing ghosts or could this be an inefficiency? (I would implement
the native algorithm, if anywhere, then in a separate method
`tuples_native`, which would recurse upon itself, and which I would then
reference *one time* from `tuples`.)
On `number_of_tuples`, is there really any chance for a gap call to beat
`return ZZ( len(set(S)) )**k` ? I imagine the `set` call could take a
while if `S` consists of complex things, but then again the doc of
`unordered_tuples` warns against passing complex things to gap, which I
assume should also apply to `number_of_tuples`. But I am too lazy to do
timings...
--
Ticket URL: <http://trac.sagemath.org/ticket/13982#comment:25>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
