Status: Accepted Owner: ---- CC: fab...@fseoane.net Labels: Type-Enhancement Priority-Medium
New issue 1908 by Vinzent.Steinberg: mutable core http://code.google.com/p/sympy/issues/detail?id=1908 This should result in a considerable speed improvement. I think it could be done using a dict (or set) for Add() and commutative Mul() or a list for noncummutative Mul() (maybe another type should be created for this). The main motivation is that we can reuse already created objects. This would annihilate the current overhead of recreating the whole symbolic tree after any operation. Example: Add(<1000 args>) + x currently recreates an Add() with 1001 args for immutability's sake. This could be done in-place, just adding x. Quoting Pearu from issue 362: """ 1) __hash__ needs to use include class name to hash computation, otherwise you'll get the same hash for expressions like 'x*y', 'x+y'. Also, I would sort Add.items() before computing hash, this ensures that one always gets the same hash value. Saving hash value is a nice trick. I wonder how this compares to the code in sandbox/core? 2) using dict as Add base makes Add mutable, there should be a big warning about not changing Add objects in place. 3) in the current core Add.flatten, Mul.flatten actually use dict-s to canonize expressions. 4) the order of dict keys may be variable for the same expression, not sure if it will be a problem in other places than __hash__... """ So Add() already uses dicts internally, just to make tuples after any operation instead of reusing them. What a waste. Fabian told me that ginac also uses dicts internally. And he also thinks that this is essential to become comparative to other CAS. Opposed to him, I think that this should not be to hard to implement. :) But a painful amount of test-fixing is probably inevitably. We need to think how to prevent people from doing nasty things with the internal mutable data structure without regenerating the hash. A thin wrapper could solve this. Or we just force args() to return a tuple (which would offer great backward compatibility), but I think we should expose more flexibility in the long run. Maybe only as a private attribute for those who know what they are doing? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups "sympy-issues" group. To post to this group, send email to sympy-iss...@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
