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.
