Also, more changes in the spirit of
8640bcd67d77287ecfb03c03688ea6f6f527c2db (from polys9) would
definitely help with this.
Aaron Meurer
On May 29, 7:08 pm, "Aaron S. Meurer" <asmeu...@gmail.com> wrote:
> This should help with the ability to know what options are even available.
> The way it is right now, you have to read the source code to find out what
> kind of options can be passed to functions like factor() or Poly() (of
> course, we will still need docstrings with doctests to show what they
> actually do).
>
> I've fixed it a little at least for factor in my polydocs-polys9 branch (see
> the latest commit in about 30 min.), but my purpose in the branch has been to
> write doctests, not documentation.
>
> Aaron Meurer
> On May 29, 2010, at 6:58 PM, Mateusz Paprocki wrote:
>
>
>
> > Hi,
>
> > On Thu, May 27, 2010 at 03:55:25PM -0600, Aaron S. Meurer wrote:
> >> expand() only expands the denominator when it gets the deep=True flag
> >> (because it is inside a Pow, namely, -1). So I guess factor needs to know
> >> to use that flag when it gets frac=True.
>
> > Good that this went out, because I'm reworking code responsible for
> > processing flags|options in polys. In the new approach, there will
> > be a separate module for managing options which will allow for unified
> > configuration of different aspects of polys. I'm also working on context
> > managers which will save a lot of typing, e.g.:
>
> > In [1]: c = ctx.gaussian(True)
>
> > In [2]: factor(x**2 + 4)
> > Out[2]:
> > 2
> > 4 + x
>
> > In [3]: c.factor(x**2 + 4)
> > Out[3]: (x + 2⋅ⅈ)⋅(x - 2⋅ⅈ)
>
> > In [4]: with ctx.gaussian(True):
> > ...: factor(x**2 + 4)
> > ...:
> > Out[4]: (x + 2⋅ⅈ)⋅(x - 2⋅ⅈ)
>
> > The same will apply to other options (in particular to frac and expand).
>
> > So, if there are more thoughts about this issue, lets share them, so that
> > I have more input for the new developments.
>
> >> The last item is a printing issue, and has nothing to do with factor or
> >> expand.
>
> >> Aaron Meurer
> >> On May 27, 2010, at 3:49 PM, smichr wrote:
>
> >>> Is the following behavior correct for factor?
>
> >>>>>> from sympy import *
> >>>>>> var('x y')
> >>> (x, y)
> >>>>>> eq = x*(1+2*y+y**2)+1+2*y+y**2
>
> >>> Here we show what happens with and without expand being set:
> >>>>>> factor(eq,expand=0)
> >>> 1 + 2*y + x*(1 + 2*y + y**2) + y**2
> >>>>>> factor(eq,expand=1)
> >>> (1 + y)**2*(1 + x)
>
> >>> Now try the same when eq is in the denominator:
> >>>>>> factor(1/eq,expand=0,frac=1)
> >>> 1/((1 + x)*(1 + y)**2)
> >>>>>> factor(1/eq,expand=1,frac=1)
> >>> 1/((1 + x)*(1 + y)**2)
>
> >>> I would have expected that expand=0 with frac=1 would have given
> >>> 1/(1 + 2*y + x*(1 + 2*y + y**2) + y**2)
>
> >>> Also why are the terms reversed in the numerator and denominator?
>
> >>>>>> factor(eq,expand=1)
> >>> (1 + y)**2*(1 + x)
> >>>>>> factor(1/eq,expand=1,frac=1)
> >>> 1/((1 + x)*(1 + y)**2)
>
> >>> (Notice that 1+x is changing positions.)
>
> >>> This behavior was also tested in polys9.
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "sympy" group.
> >>> To post to this group, send email to sy...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> sympy+unsubscr...@googlegroups.com.
> >>> For more options, visit this group
> >>> athttp://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 sy...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> sympy+unsubscr...@googlegroups.com.
> >> For more options, visit this group
> >> athttp://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 sy...@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
