#15998: Restore some documentation and doctests and a function removed with
#15466
-------------------------------------+-------------------------------------
Reporter: darij | Owner:
Type: defect | Status: positive_review
Priority: major | Milestone: sage-6.2
Component: combinatorics | Resolution:
Keywords: | Merged in:
Authors: Darij Grinberg | Reviewers: Nathann Cohen, Travis
Report Upstream: N/A | Scrimshaw
Branch: | Work issues:
public/combinat/re-15466 | Commit:
Dependencies: | da4bf10359d8a23746de8647904ba2c389f61d59
| Stopgaps:
-------------------------------------+-------------------------------------
Comment (by ncohen):
Yoooooooooooooo !
> There are two things that slow it down:
>
> - checking to make sure it is a valid partition (something which I'd
think you'd advocate), and
> - striping trailing 0's (i.e. standardizing the data, which again I'd
think you'd advocate).
?
Well, I advocate a great many things. In this case I would advocate to
make those test optional, so that they can be disabled when needed, i.e.
here.
> As I recall, there's code out there that assumes that initialization of
a partition always does these (one of these) two operations (both of which
need to loop over each partition), so we can't refactor this away
completely. I also don't like passing these (IMO stupid) 'check'
arguments.
?
What do you have against those `check` parameters ? Their point is
precisely to avoid useless tests. How can they do any harm ? `O_o`
> The check of containment in `NN` is actually pretty good:
Hey, I have nothing against how you test stuff. Perhaps it is well written
and everything, I am just saying that consistency check and creation of
object requires more computations than actually compute what you want,
that's all. Soooooooooo in this case it is a bit ridiculous to do these
enumerations at Python level, that's all. Eventhough it's a bit less
ridiculous at Python level than Sage-level `:-PPP`
> Also your test is unfair because we have to do extra processing on the
result from iterator to get the actual partition we wanted.
....
You mean add a +1 ? and a few extra cells ?
I can do that in C if you prefer. Do you bet that the time does not change
? `:-P`
We could just replace the "yield x[:m+1]" with a yield `[x[i]+1 for i in
range(k)]` and we would be done `:-P`
> So in the end, we'll have to sit down on a separate ticket and optimize
partition creation someday, but not today.
hey man, once more I am not saying that it is badly written or anything.
You just want to make everything too general, too abstract, and well, you
pay it. Can't do without it. That's why I will always feel better playing
with a `int * partition` than with a Sage object.
It's just funny that we were wondering how to avoid a multiplication while
anything we can save is lost 99999 times by the code above it.
> However I'm not surprised you see the slowdown in using a list in python
as opposed to C. Python is slow compared to C because of it's interpreted
/weakly-typed/higher-level nature.
Ahahahah. Yeah, you are right.... But I did not expect it at this moment.
Must be why it's nice to actually profile code instead of think about it
and optimize multiplications.
> PS - Nathann, that's 4 things `:P`
The problem with lists is that I write them top-to-bottom and that the
numbers change from time to time while I write stuff `:-P`
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/15998#comment:41>
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.
