I agree. Like I said, unless you want to create very abstract objects that represent permutations with symbolic n, which would be implemented completely differently from the explicit permutations, then don't worry about symbolic support for this one. The main thing for the issue of making things symbolic is to make things that return Expr instances (like numbers) be classes instead of functions.
Aaron Meurer On May 18, 2011, at 2:08 PM, Alexey U. Gudchenko wrote: > 18.05.2011 17:15, Haz пишет: >> On Wed, May 18, 2011 at 8:47 AM, Vinzent Steinberg < >> vinzent.steinb...@googlemail.com> wrote: >> >>> >>> I'm a bit worried about performance if you use Expr instances. Maybe >>> have a low-level integer representation, so you can implement a high- >>> level interface later which works for arbitrary elements, but does the >>> computations using the fast representation? This could be an object >>> that stores the mapping between your arbitrary finite set and the >>> integers together with the integer representation, and maps back >>> automatically for printing etc. >>> >> >> This was precisely the plan from what I gather (Saptarshi can correct me >> if I'm wrong), but the question was primarily what the interface to the >> function should be (in the context of keeping things as symbolic as >> possible). >> >> Cheers, >> Christian >> > > If I understand the thread correctly, you want to *apply* the > permutation to the various lists of symbols. > > You wrote about: >> Specific algorithms that operate on permutations will be implemented > to work with arbitrary Expr objects as best possible. > > But (the others seems have said it similar) I should like to separate > the problems of the creation/usage of the permutations itself (the > notation of it, its internal representations and algorithms) on the one > hand and applying of some permutations to the lists or tuples on the > other hand. So, interface e.g. > > creation, notation: >>>> Permutation([1, 3, 2]) > # or >>>> Permutation(1, 3, 2) > Permutation(1, 3, 2) >>>> pprint Permutation(1, 3, 2) # representation > (1. 3, 2) > >>>> pprint Permutation([2, 1], [5, 4]) # (only cycles) > (2, 1, 3, 5, 4) >>>> print Permutation([2, 1], [5, 4]).short_notation() > (2, 1)(5, 4) > > > Apply to some lists: > >>>> p = Permutation([1, 3, 2]) >>>> p.reorder([x, y, z]) # or something else > [x, z, y] > > > In this case it is not needed to operate with specific algorithms (for > representation symbols) into the permutation realization. We use pure > permutations (1..n) with its own algorithms and only then apply > permutation to the objects which we like. > > Also, one can use the binding of the representation symbols with > permutation: > >>>> p = Permutation([1, 3, 2]) >>>> p.bind_symbols(x, y, z) >>>> p > (x, z, y) > > But interesting how the permutations with different bindings will be > work together in this case. So, I think, it is not needed indeed. > > Alexey U. > > -- > 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. > -- 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.
