Hi, On 2 June 2011 04:09, Brian Granger <[email protected]> wrote:
> Is there a link somewhere to documentation about the groundtypes in > polys? I am interested why such things are needed? It sort of sounds > like there are two semi-independent code bases living here... > See my previous response. Unfortunately, currently there isn't much documentation on this topic. As to two code bases, there are actually two cores, one (should be) purely symbolic (sympy.core) and the other algebraic (sympy.polys and sympy.polys.domains, later should be extracted to a separate top-level module, to make it reusable in other parts of SymPy). > > > > On Wed, Jun 1, 2011 at 6:31 PM, Aaron Meurer <[email protected]> wrote: > > I think the key point that should be made here is that the matrices > > should try to use the *exact* same ground types/domains as the polys, > > so that there is no code duplication. This will probably involve > > improving and even changing a little bit the design of the polys > > classes (but this is good, because it will make them more modular, > > which is the goal anyway). > > > > On Sun, May 29, 2011 at 3:44 PM, Mateusz Paprocki <[email protected]> > wrote: > >> Hi, > >> > >> On 29 May 2011 23:10, Tom Bachmann <[email protected]> wrote: > >>>> > >>>> On May 30, 12:13 am, Tom Bachmann<[email protected]> wrote: > >>>>> > >>>>> How is this at all different from what Polys does? I'm not saying > it's > >>>>> bad, I'm just not seeing your point. Basically what you call ground > >>>>> types are called domains in polys, and they are in polys/domains ... > >>>> > >>>> I need usable types. For example, you mentioned that one usable type > >>>> is DMF, and it is in poly/polyclasses. > >>>> How many other such types exist and where ? > >>>> > >>> > >>> DMF is already higher level. The things you should probably be looking > at > >>> are in polys/domains. > >> > >> Well, DMF is low-level. In domains you will find FractionField domain > that > >> uses DMF a ground type. > >> > >>> > >>> There's a lot there, and it's a bit of a shame that there's not much > >>> documentation. > >> > >> There isn't that much, but main ideas are described in my thesis (ch. > 2). If > >> more information is needed, I can always provide it (as long as a > question > >> is specific). > > > > There would be more, as I wrote doctests for all those things back in > > https://github.com/asmeurer/sympy/tree/polydocs. But the domains code > > was all moved to polys/domains and the API changed so much that I > > never bothered to transfer the doctests. > > > > If you need to know how a module works and there is no documentation, > > writing doctests for all the functions/methods is a great way to fix > > both problems. This is how I learned how the polys in general worked > > at the beginning of last summer (see the above linked branch). In > > this case, you could just work on transferring my doctests that were > > never transferred. > > > > Aaron Meurer > > > >> > >>> > >>> I think construct_domain should somehow construct a domain that can > hold > >>> your data. If you need to divide, or take square roots, etc, you > presumably > >>> have to figure out what larger domain you need. There are probably > functions > >>> for this, but I don't know about them. Ask Mateusz about anything > specific. > >>> > >>> As for ground types, they work roughly like this: > >>> > >>> >>> from sympy.polys.domains import FF > >>> > >>> This imports a constructor for finite fields. As I understand it, this > >>> will automatically use gmpy or python types depending on what is > available. > >>> > >>> > >>> Construct a domain for arithmetic mod 5: > >>> >>> F5 = FF(5) > >>> > >>> Do some arithmetic: > >>> >>> F5(3) + F5(8) > >>> 1 mod 5 > >>> >>> F5(3)/F5(2) > >>> 4 mod 5 > >>> > >>> Funny things can happen if you do division where you should not: > >>> >>> from sympy.polys.domains import ZZ > >>> >>> ZZ(2)/ZZ(3) > >>> 0.666666666667 > >>> > >>> But this works: > >>> >>> Q = ZZ.get_field() > >>> >>> Q(2)/Q(3) > >>> 2/3 > >> > >> Division in Python is tricky because there are / and //. The meaning of > / > >> can differ (2/3 can give either 0 or a float). If you want to make your > code > >> independent of this use quo(), rem(), div() methods of an appropriate > >> domain, e.g.: > >> In [1]: ZZ.quo(ZZ(2), ZZ(3)) > >> Out[1]: 0 > >> In [2]: ZZ.rem(ZZ(2), ZZ(3)) > >> Out[2]: 2 > >> In [3]: ZZ.div(ZZ(2), ZZ(3)) > >> Out[3]: (0, 2) > >> Domains and ground types in polys work as follows: +, - (unary/binary) > and * > >> must be implemented in ground types and must solve zero equivalence > problem. > >> Division, gcd, lcm and other can be implemented in ground types but code > >> using those ground types can't take advantage of them and must use > >> domain.div(), domain.gcd(), domain.lcm() and so on. > >> Using +, -, * in code directly makes the code fast. Division isn't very > >> common so we can use a thin layer above / and //, and as division is > >> generally a mess (e.g. extra qdiv() in gmpy), the extra layer in > necessary > >> to use single code for multiple ground types (here I'm not only speaking > >> about handling numbers and polynomials in one code, but also different > >> implementations of numbers (Integer, int, mpz, ...), because they have > very > >> different APIs). > >>> > >>> I suppose to see how to do this sort of stuff automatically, you have > to > >>> read polytools.py. > >>> > >>> -- > >>> 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. > >>> > >> > >> Mateusz > >> > >> -- > >> 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. > >> > > > > -- > > 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. > > > > > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > [email protected] and [email protected] > > -- > 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. > > Mateusz -- 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.
