Univariate polynomials over algebraic domains

[Rishabh Kumar]

hello

i was going through the ideas page when i came across the project of implementing univariate polynomials over algebraic domains. when i was going through the works of Monagan, Pearce, and van Hoeij , i found the project very tempting . can u please expand more on the ideas and expectation from the project .

[Ondřej Čertík]

Hi Rishabh,

The best guy to ask about this is probably Mateusz, I CCed him.

Ondrej

[Rishabh Kumar]

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.

[Aaron Meurer]

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

> --
> 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+un...@googlegroups.com.
> To post to this group, send email to sy...@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.