On Mon, Jul 23, 2012 at 9:51 PM, Tom Bachmann <[email protected]> wrote: > > I'm sorry, I know I'm somewhat late to the party, and replying at this > position in the thread is rather arbitrary, but how about the following: > > 1) don't sort .args at creation time (ronan has made good arguments for > this, imho) > 2) add a property .sorted_args to FiniteSet > This could just return sorted(self.args, key=whatever) for now. > 3) Anywhere you need sorted arguments (for example in the sort key, and > for printing), use .sorted_args. Else use .args. > 4) If we experience major slowdown in some use of .sorted_args, > investigate if manual caching yields improvement. > 5) PROFIT
This sounds like it may cause slowdown, but I totally think that this approach is a good one, since it allows transparent caching, if needed. What do people think? :-) > As an expansion of step 4, most of which has already been said elsewhere: > Since sympy objects are inherently immutable, the cache can be as dumb as > using a self._sorted_args member which is initially set to None. Yes, that's how I envision the caching as well. I think even that it may make sense to have such caching from the very beginning, since it is going to be so dumbly simple. > The only problem I see with this is that myset.class(*myset.args) > will clear the cache. Not sure how much of an issue that is. Apparently, we just have to wait and see. A lot depends on how often such statements will be written for FiniteSet, which I find hard to determine right now. I do have the strong opinion that FiniteSet absolutely must be corrected and that now it is subtly broken. Sergiu -- You received this message because you are subscribed to the Google Groups "sympy" 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/sympy?hl=en.
