Sorry for the delay. On Thu, Jul 26, 2012 at 10:04 PM, Ronan Lamy <ronan.l...@gmail.com> wrote: > Le mardi 24 juillet 2012 à 18:44 +0300, Sergiu Ivanov a écrit : >> On Mon, Jul 23, 2012 at 9:51 PM, Tom Bachmann <e_mc...@web.de> 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. > > That could be useful for many kinds of objects, not just FiniteSet. > Ultimately, I think it should be part of the interface of Basic.
A very good point; I've made it be so here: https://github.com/sympy/sympy/pull/1446 >> > 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. > > Caching a list costs a lot of memory. I don't think it's worth it, > considering that it'll only be used for printing. In the pull request I mentioned, I annotate the new sort_key methods in FiniteSet and Dict with @cacheit. Note that the original Basic.sort_key is annotated with @cacheit as well. >> > 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. > > Well, doing exactly that (myset.func(*myset.args)) is inefficient by > design, since it creates an identical copy of myset, instead of just > reusing myset. So we shouldn't worry about performance in that case. Great; that was my impression as well. On Thu, Jul 26, 2012 at 10:06 PM, Ronan Lamy <ronan.l...@gmail.com> wrote: > Le mardi 24 juillet 2012 à 18:37 +0300, Sergiu Ivanov a écrit : >> On Mon, Jul 23, 2012 at 9:52 PM, Aaron Meurer <asmeu...@gmail.com> wrote: >> > On Jul 23, 2012, at 12:33 PM, Sergiu Ivanov <unlimitedscol...@gmail.com> >> > wrote >> >> I was referring to the fact that, for example, FiniteSet(3, 1, >> >> 2).complement should return the same result. >> >> >> >> In other words, to get the complement relative to RR, one has to sort >> >> the numbers in the FiniteSet first, because otherwise one may get >> >> stuff like (-oo, 3) U (1, 2) U (2, oo). >> > >> > Well this answer is simply wrong. >> >> Obviously; that's why one needs to sort the elements of the FiniteSet >> when computing the complement with respect to real numbers. > > The elements need to be sorted by value, not by sort_key, so this case > is unrelated to the current discussion. Oh, sure, that's perfectly right! The aforementioned pull request fixes that as well. Thank you for pointing out! Sergiu -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
