OK. So your interpretation doesn't really matter in the implementation, because you end up calculating the remainder anyway in either case. The only difference is a conditional, which takes negligible time. I would much rather play it on the safe side and ensure that if an algorithm expects exact division that it fails when it isn't instead of silently succeeding with a wrong result.
I'll make the change if we can decide on something better. Some ideas: - Use only one function, with a keyword argument to test if the remainder vanishes. I'm not sure what should the keyword argument be called, though. - I looked at what Maple does, and I'm not sure if I like it. quo() and rem() return the quotient and remainder, respectively, regardless if the remainder vanishes or not. divide() is the function for exact division. It works like this: divide(x, y, q) returns False if x/y is not exact and True if it is exact. In this case, it set's the name 'q' to the quotient. Maybe this behavior isn't a very good one for sympy, but the name "divide()" could work. - I don't own Mathematica, but I couldn't find any exact division functions in the online docs. - I am fine with just reversing the behavior so it is like Axiom. I think it should be fine if we make it clear in the various docstrings that the exquo is for when you are expecting exact division in your algorithm and it should be an error otherwise. I tried switching the four quo/exquo functions in densearith.py and only got 4 test failures, other than the ones for those functions specifically. - Remove quo(). How often is there non-exact division and you don't want the remainder? dup_quo() just returns dup_div()[0] anyway, so you could just replace quo() with that. Note that the answer to "How often…?" above could be "very often", because I haven't studied that many polynomial algorithms yet. In that case, just scratch this idea. When you coded the algorithms and came across a case where the polynomial division should always have been exact did you use quo or exquo? In other words, did you take the safe side philosophy I mentioned above, or did you take the philosophy you mentioned, where you trust the algorithm? The reason I ask is that I want to know if I will need to switch quo and exquo in the code to whatever we choose or if they will already be correct. By the way, in case you are wondering why I came across this, it's because I am in the process of writing doctests for most of the functions in the polys module. It seemed to be the best way for me to learn the in's and out's of the module, a prerequisite for my GSoC project, and it also is a very needed thing anyway IMHO. You can follow the progress here: http://github.com/asmeurer/sympy/tree/polydocs-polys9, though be aware that that branch will be very unstable until I finish some time in the next week. I've been working on top of polys9. Aaron Meurer On May 21, 2010, at 5:47 PM, Mateusz Paprocki wrote: > Hi, > > On Fri, May 21, 2010 at 05:02:40PM -0600, Aaron S. Meurer wrote: >> What is supposed to be the meaning of "quo" and "exquo" in the Polys? >> Looking in densearith.py, I see things like this: >> >> def dup_quo(f, g, K): >> """Returns polynomial quotient in `K[x]`. """ >> q, r = dup_div(f, g, K) >> >> if not r: >> return q >> else: >> raise ExactQuotientFailed('%s does not divide %s' % (g, f)) >> >> def dup_exquo(f, g, K): >> """Returns exact polynomial quotient in `K[x]`. """ >> return dup_div(f, g, K)[0] >> >> But I would have expected the exact opposite: for quo to give be the >> quotient without caring and for exquo to warn me when the quotient is not >> exact. So what is the reasoning behind the current behavior? >> > > it depends on the point of view. My interpretation is like this: exquo() means > that the we know in advance that the quotient will be exact (no remainder) and > we don't want to lose time for checking the remainder. In your interpretation, > exquo() asks if the quotient is exact and returns it, if remainder vanishes. > This is what Axiom does (actually I thought before it does the job my way). > > Anyway, I don't like the name exquo at all, as interpretations may vary. It > would be better to have quo() for what currently exquo() function does, and > e.g. quo_if_can(), for the other version. > > I think we should at least switch the meaning of quo() and exquo(), and think > if the name exquo is the right one. > >> Aaron Meurer >> >> -- >> 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.
