Dear Stefan,
Thanks for your feedback!
On Mon, Jun 20, 2011 at 02:08:18PM -0700, Stefan van Zwam wrote:
> Sorry to bug you again with this (I already did so a few months back), but
> I still have qualms with Sage's built-in Set type. For starters, it does
> not offer the same interface that Python's frozenset offers (example: the
> issubset() method).
sage: Set([1,2,3]).issubset(Set([1,2,3,4]))
True
:-)
I implemented this recently. See http://trac.sagemath.org/sage_trac/ticket/10938
which was merged in the upcoming 4.7.1.
Now, I am sure that there are other methods missing, and volunteers to
fix that are most welcome.
> But my more serious concern is speed. I would love to use the
> sage.combinat.subset.Subsets_s class to check matroid axioms. For quick
> reference:
> ...
>
> sage: %time M.is_valid()
> CPU times: user 17.25 s, sys: 0.01 s, total: 17.26 s
> Wall time: 17.26 s
> True
>
> sage: %time M.is_valid2()
> CPU times: user 0.43 s, sys: 0.00 s, total: 0.43 s
> Wall time: 0.43 s
> True
>
> This may sound harsh, but if this class is so slow to be unusable, what
> good is it to have it in Sage?
This follows a general strategy:
(1) Isolate a feature. In our case we need to model mathematical sets
as parents (that in particular are hashable, ...)
(2) Design an appropriate API
(3) Make at once a first implementation, even if it is incomplete or
largely suboptimized
(4) Make sure all code needing that feature uses this first
implementation, instead of various workarounds
(5) Wait for someone (typically yourself) to get itchy/frustrated
enough to take the time to complete/optimize the implementation
while keeping the same API.
(3)+(4) allows for early feedback on (1)+(2) (kind of release early,
release often). (3) allows for (4). Thanks to (2)+(4), (5) does not
require to to go through all the code to get rid of all the
workarounds.
Coming back to our problem at hand, Sage Set's could certainly be made
much faster, in particular by Cythonizing them. I would very much
appreciate if this happened, since I have been annoyed by this myself
quite a few times as well. However there remains a couple questions:
- Could Set's be optimized to be about as fast as Python sets, even
for small sets like those created by Subsets(...)? Being a Parent
might induce an incompressible overhead.
- Is there someone frustrated enough to take care of the
optimization, so that Sets become usable in your use case?
- Should Subsets(...) return Set's? Or set's? Or frozenset's? As in
many similar situations, I expect that there is no one-size-fit-all
choice here. Hence Subsets(...) should take an option specifying
which constructor to use. Since this is a general idiom, we need a
good standard name for this option. Florent?
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <[email protected]>
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
