On Mon, Jul 23, 2012 at 9:15 PM, Aaron Meurer <[email protected]> wrote: > > Maybe I'm missing something, but wouldn't the laziness only have to > apply to the sort_key, not .args (which probably could be left > unsorted)? Unlike .args, the sort_key doesn't have to be created at > instantiation time (and in fact won't be because it's a property, so > you'd just have to cache it).
That's not what I initially thought, but what you say may actually make much more sense. Since FiniteSet is immutable, I could indeed only compute the sort key once (by copying .args and sorting the copy), and then always return a cached version. Joachim, this doesn't address the possible slowdown issue, but does seem to be a more robust approach. Actually, as far as optimisation is concerned, I think Matthew has repeated it very many times that he hasn't found sorting .args at creation to be an issue. I guess, in this case, the scientific way to go would be to check the performance of FiniteSet.__init__ with sorting and without it, for containers of, say, 10^4 random floats. (Unless, of course, Matthew already has some statistics.) 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.
