Hi, On Fri, May 21, 2010 at 07:30:26PM -0600, Aaron S. Meurer wrote: > 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. >
Well, I'm pretty sure I know why you are doing this and, by the way,
this is a good way to start. Hopefully, in near future (2~3 weeks)
I will be done with my masters thesis, so there will be a lot of
material to learn from.
As to quo/exquo, will analyze this issue when working on my thesis.
> 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.
>
--
Mateusz
signature.asc
Description: This is a digitally signed message part
