On Thu, Jun 2, 2011 at 1:28 AM, Mateusz Paprocki <[email protected]> wrote: > 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).
Then I don't understand what polys has to do with Matrices. Surely matrices can contain expressions other than polynomials. This is really what I am wondering about. Are we talking about a special Matrix subclass that *only* contains polynomials? >> >> >> 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. > -- 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.
