I don't know if it will require a full rewrite of Poly to do this. You should be able to change only the bottom level. Ideally, anything above that should be representation agnostic.
And anyhow, my understanding was that the ring() code already is a to a large extend a rewrite of Poly. Aaron Meurer On Sat, Mar 15, 2014 at 4:31 AM, Rishabh Kumar <kris.kr...@gmail.com> wrote: > I wish to discuss the idea of implementing the new system of representation > and its consequences.I came to know that previously there was an attempt to > merge ring() with poly to accommodate efficient operations on both the > types.But later I came to know that the work was to remove the dense > representation entirely. I believe that it will not be a feasible action as > in order to do so , we will have to rewrite the entire polynomial module > from scratch.After going through the architecture, I think that I can create > a hack on our traditional system of dense representation so that we can use > the existing code with comparatively less modification.Basically i intend to > deprecate the poly module. Here is a brief overview of my plan.All > operations are done on Univariate Polynomials > > > We use parsing to store the polynomials in the dense representation.I intend > to modify it in such a way that it can decide whether the given polynomial > is sparse or dense by returning True or False. I will create another member > for the __slots__ function in class Poly, 'dtype' which will account for > the nature of the polynomial(dense or sparse).By default the value of this > member will be 'True'. This will help us to modify our functions operating > on the polynomials accordingly. > > """ function to determine whether > the given function is sparse or dense''' > > def _is_dense_(self): > if(self.dtype==True) > return true > else reurn False > > """dummy class for conducting the process of addition of 2 polynomials > cases possible both > f.dtype==True and g.dtype==True > f.dtype==True and g.dtype==False > f.dtype==False and g.dtype==True > f.dtype==False and g.dtype==False > """ > def _add_poly_(f,g): > if(f._is_dense_ or g._is_dense==True): > .........#algorithm for addition for dense polynomial > else: > .........#algorithm for sparse polynomial > > > Pros and cons of dumping the code for dense polynomial (poly class) > pros: help us to conduct operations on sparse polynomials very > efficiently > cons:1.rewriting the entire poly module > 2.reduced flexiblity of poly to conduct operations > > Pros and cons of deprecating the code for poly class > pros:1.improved flexiblity > 2.small amendments at the part of the code. > cons:deprecation itself > > All I want to say is that both the methods of representation have their own > advantages for their respective types. Giving undue favour to one type of > polynomial will have a great impact on the applications.Moreover ,we can't > remove dense representation unless all the algorithms are implemented in the > sparse case. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/a178c3a0-3bc6-4106-a45e-5de21d5ce1ef%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JAbnsBz%2Bbya%2BUmozaw%3Ddu_kBQnp%2BYag%2Bodhh5hG3u5fA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
