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...
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.
