I've asked about factoring before but am just jotting down some
observations that I've made in the last few days. I was talking with
Aaron the other day about a routine and suggested he should use
factoring. He says, "that's gong to be expensive." I got to thinking.
The
smichr's gfactor branch at github has a (hopefully) more robust method
for factoring. It relies on the standard factor that is part of polys
but it does pre-processing of an expression with a gcdfactor routine.
The gcdfactor pulls out terms that can be removed multiplicatively
from all terms
On Aug 7, 2010, at 5:57 AM, smichr wrote:
> I've asked about factoring before but am just jotting down some
> observations that I've made in the last few days. I was talking with
> Aaron the other day about a routine and suggested he should use
> factoring. He says, "
Hi,
On 7 August 2010 13:57, smichr wrote:
> I've asked about factoring before but am just jotting down some
> observations that I've made in the last few days. I was talking with
> Aaron the other day about a routine and suggested he should use
> factoring. He says, "
> I'm not sure what you mean here. factor() uses variety of algorithms,
> heuristics, theorems and irreducibility criteria to improve speed of
> factoring polynomials, e.g.:
I'm only saying (and without understanding at all about how EEZ works)
that based on the behavior of fac
Hi,
On Sat, Aug 07, 2010 at 04:57:18AM -0700, smichr wrote:
> I've asked about factoring before but am just jotting down some
> observations that I've made in the last few days. I was talking with
> Aaron the other day about a routine and suggested he should use
> factoring.
On Aug 10, 1:23 am, Mateusz Paprocki wrote:
> Hi,
>
>
>
> On Sat, Aug 07, 2010 at 04:57:18AM -0700, smichr wrote:
> > I've asked about factoring before but am just jotting down some
> > observations that I've made in the last few days. I was talking with
&g
On Aug 11, 12:01 pm, smichr wrote:
> On Aug 10, 1:23 am, Mateusz Paprocki wrote:
This factoring business is so easy to get wrong. The routine at gist
handles pure symbolic factors well (at least the current version I
have here) but it fails for stragglers:
a + b + x*a + x*b
and does
Hi,
On Tue, Dec 01, 2009 at 11:01:25AM -0800, smichr wrote:
> smichr's gfactor branch at github has a (hopefully) more robust method
> for factoring. It relies on the standard factor that is part of polys
> but it does pre-processing of an expression with a gcdfactor routine.
&
On Tue, Dec 1, 2009 at 1:02 PM, Mateusz Paprocki wrote:
> Hi,
>
> On Tue, Dec 01, 2009 at 11:01:25AM -0800, smichr wrote:
>> smichr's gfactor branch at github has a (hopefully) more robust method
>> for factoring. It relies on the standard factor that is part o
2009/12/1 Ondrej Certik :
> We have to get the new polys in finally. I will have time to write
> some documentation for it --- Mateusz, could you please rebase it to
> the latest master? I'll then do my best. I think it fixes lots of
> problems.
>
> Ondrej
Chris did already rebase it on his polys2
Are there going to be separate 0.6.6 and 0.7 releases? I thought that we were
going to just jump right up to 0.7.
Aaron Meurer
On Dec 1, 2009, at 3:29 PM, Vinzent Steinberg wrote:
> 2009/12/1 Ondrej Certik :
>> We have to get the new polys in finally. I will have time to write
>> some documenta
Well, 0.7 would be a great opportunity to break the API compability
(removing old assumptions, new polys, simplified expand etc.), so I
thought we could make a 0.6 release before, because there are already
enough changes accumulated. What do you think?
2009/12/1 Aaron S. Meurer :
> Are there going
On Tue, Dec 1, 2009 at 2:29 PM, Vinzent Steinberg
wrote:
> 2009/12/1 Ondrej Certik :
>> We have to get the new polys in finally. I will have time to write
>> some documentation for it --- Mateusz, could you please rebase it to
>> the latest master? I'll then do my best. I think it fixes lots of
>>
Well, there is definitely enough in master now to warrant a release. Looking
through the log, I see (among other things):
- Tons of bug fixes
- My entire Google Summer of Code Project (the ode module, and also a bunch of
bug fixes)
- Work on piecewise functions and intervals
- Wicks/Second Quan
On Tue, Dec 1, 2009 at 3:11 PM, Aaron S. Meurer wrote:
> Well, there is definitely enough in master now to warrant a release. Looking
> through the log, I see (among other things):
>
> - Tons of bug fixes
> - My entire Google Summer of Code Project (the ode module, and also a bunch
> of bug fix
2009/12/2 Ondrej Certik :
> On Tue, Dec 1, 2009 at 3:11 PM, Aaron S. Meurer wrote:
>> Well, there is definitely enough in master now to warrant a release.
>> Looking through the log, I see (among other things):
>>
>> - Tons of bug fixes
>> - My entire Google Summer of Code Project (the ode modul
On Tue, Dec 1, 2009 at 5:30 PM, Vinzent Steinberg
wrote:
> 2009/12/2 Ondrej Certik :
>> On Tue, Dec 1, 2009 at 3:11 PM, Aaron S. Meurer wrote:
>>> Well, there is definitely enough in master now to warrant a release.
>>> Looking through the log, I see (among other things):
>>>
>>> - Tons of bug
> Chris's test runner has highest priority (tests not working on Windows
> is no option), assumptions and polys are postponed for 0.7.
>
I've learned (thanks to Vinzent, I think) how to work on Windows with
the test runner and don't have the same problems anymore...I would
have gone crazy by now i
Hi,
On Wed, Dec 02, 2009 at 12:00:20AM +0100, Vinzent Steinberg wrote:
> Well, 0.7 would be a great opportunity to break the API compability
> (removing old assumptions, new polys, simplified expand etc.), so I
> thought we could make a 0.6 release before, because there are already
> enough change
On Wed, Dec 2, 2009 at 3:27 PM, Mateusz Paprocki wrote:
> Hi,
>
> On Wed, Dec 02, 2009 at 12:00:20AM +0100, Vinzent Steinberg wrote:
>> Well, 0.7 would be a great opportunity to break the API compability
>> (removing old assumptions, new polys, simplified expand etc.), so I
>> thought we could mak
On Wed, Dec 2, 2009 at 4:12 PM, Ondrej Certik wrote:
> On Wed, Dec 2, 2009 at 3:27 PM, Mateusz Paprocki wrote:
>> Hi,
>>
>> On Wed, Dec 02, 2009 at 12:00:20AM +0100, Vinzent Steinberg wrote:
>>> Well, 0.7 would be a great opportunity to break the API compability
>>> (removing old assumptions, new
One last thing --- all tests+doctests pass, but some documentation
tests fail and I think at least some of them may indicate some bugs,
that should be fixed and regular tests written for:
**
File "doc/src/modules/polynomials.txt",
Hi,
On Wed, Dec 02, 2009 at 04:21:46PM -0800, Ondrej Certik wrote:
> One last thing --- all tests+doctests pass, but some documentation
> tests fail and I think at least some of them may indicate some bugs,
> that should be fixed and regular tests written for:
>
>
⎟ x
> x⋅⎜x + ──⎟⋅ℯ
> ⎝ y ⎠
>
In this case, no. But gcdfactor would do nothing to 1-x**2 whereas
factor would return (1+x)*(1-x). Removing a common factor from all
terms before beginning the formal factoring process makes the regular
factoring a lot easier. I think the place for this
> > y
> >
> > In [3]: factor(f)
> > Out[3]:
> > ⎛ y⎞
> > ⎜ ℯ ⎟ x
> > x⋅⎜x + ──⎟⋅ℯ
> > ⎝ y ⎠
> >
>
> In this case, no. But gcdfactor would do nothing to 1-x**2 whereas
> factor would return (
There are several doctests failing on your polys2 branch.
Vinzent
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this group, send email to sympy-patc...@googlegroups.com.
To unsubscribe from this group, send email to
sympy-patches
On Thu, Dec 3, 2009 at 4:38 PM, Vinzent Steinberg
wrote:
> There are several doctests failing on your polys2 branch.
Which ones? All doctests run for me.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this group, send emai
The failures are all in the Sphinx file polynomials.txt.
Aaron Meurer
On Dec 3, 2009, at 11:21 PM, Ondrej Certik wrote:
> On Thu, Dec 3, 2009 at 4:38 PM, Vinzent Steinberg
> wrote:
>> There are several doctests failing on your polys2 branch.
>
> Which ones? All doctests run for me.
>
> Ondrej
There are also failures that will not show up until Chris's runtest branch is
merged in if you do:
bin/doctest sympy/polys/galoistools.py
bin/doctest sympy/polys/factortools.py
bin/doctest sympy/polys/monomialtools.py
bin/doctest sympy/polys/polyroots.py
They are all based on the name of the fun
On Dec 4, 11:35 am, "Aaron S. Meurer" wrote:
> There are also failures that will not show up until Chris's runtest branch is
> merged in if you do:
>
> bin/doctest sympy/polys/galoistools.py
> bin/doctest sympy/polys/factortools.py
> bin/doctest sympy/polys/monomialtools.py
> bin/doctest sympy/
eed to try
factoring on terms which have more than one symbol in them after
removing any gcd terms.
- as_numer_denom() for an Add would benefit because the common factor
in number and denom could be removed. This also helps in rootinfinding
because the spurious roots would be thus avoided in a case like I
eed to try
factoring on terms which have more than one symbol in them after
removing any gcd terms.
- as_numer_denom() for an Add would benefit because the common factor
in number and denom could be removed. This also helps in rootinfinding
because the spurious roots would be thus avoided in a case like I
2009/12/4 Ondrej Certik :
> On Thu, Dec 3, 2009 at 4:38 PM, Vinzent Steinberg
> wrote:
>> There are several doctests failing on your polys2 branch.
>
> Which ones? All doctests run for me.
See attachement.
Vinzent
--
You received this message because you are subscribed to the Google Groups
"s
Polys2 needs to be rebased again (there are conflicts with the new runtests,
including doctest changes). Once you do this, I am sure the new runtests will
show you the doctest failures, both the ones Vinzent mentioned and the ones I
mentioned. They seem to be all Chris's changes, so maybe he c
, p)[1]:
+modular.append(gf_to_int_poly(ff, p))
+
+g = zzx_hensel_lift(p, f, modular, l)
+
+ T = set(range(len(g)))
+factors, s = [], 1
+
+while 2*s <= len(T):
+for S in subsets(T, s):
+G, H = [b], [b]
+
+S = set(S)
+
+
i over
> + Z[x] satisfying:
> +
> +f = lc(f) f_1 ... f_r (mod p)
> +
> + and a positive integer l, returns a list of monic polynomials
> + F_1, F_2, ..., F_r satisfying:
> +
> +f = lc(f) F_1 ... F_r (mod p**l)
>
On Sun, Nov 23, 2008 at 09:27:05PM +0100, Fabian Seoane wrote:
>
> Nice work!
>
Thanks.
> Couple of questions: what does zzx stand for?
>
zzx stands for univariate polynomial over integers --- Z[x]. The
double 'z' is used in many algebra systems, so I stay compatible
with those systems (also
On Mon, Nov 24, 2008 at 8:47 AM, Mateusz Paprocki <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 23, 2008 at 09:27:05PM +0100, Fabian Seoane wrote:
> The problem with factorization code is that it requires a lot of
> CPU resources, so spending time on anything else that computing,
> e.g. object creation
Fredrik Johansson wrote:
> On Mon, Nov 24, 2008 at 8:47 AM, Mateusz Paprocki <[EMAIL PROTECTED]> wrote:
>> On Sun, Nov 23, 2008 at 09:27:05PM +0100, Fabian Seoane wrote:
>> The problem with factorization code is that it requires a lot of
>> CPU resources, so spending time on anything else that com
Don't know if doing this just before a new beta release is good or bad,
but here it is. If it doesn't make it in, oh well.
Added functionality to simplify so that a minus 1 is factored out of
the numerator and denominator of fractions if possible. Several
changes also had to be made to the resul
I think the branch called
simplify_minus_and_1495
on my github repo
git://github.com/ryanGT/sympy.git
solves and closes issue 1493 (I think it includes the fix for 1495 as well).
Please let me know if I need to separate the solutions to 1493 and 1495.
I would appreciate review and comments.
Than
On Mon, Jun 29, 2009 at 1:37 PM, Ryan Krauss wrote:
> I think the branch called
> simplify_minus_and_1495
> on my github repo
> git://github.com/ryanGT/sympy.git
> solves and closes issue 1493 (I think it includes the fix for 1495 as well).
>
> Please let me know if I need to separate the solution
On Mon, Jun 29, 2009 at 3:41 PM, Ondrej Certik wrote:
> On Mon, Jun 29, 2009 at 1:37 PM, Ryan Krauss wrote:
>> I think the branch called
>> simplify_minus_and_1495
>> on my github repo
>> git://github.com/ryanGT/sympy.git
>> solves and closes issue 1493 (I think it includes the fix for 1495 as wel
Cool. Aaron said to add a pass, but now that I think about it, you are
right, if it doesn't find a true case, it will just end up returning
hash(self) < hash(negative_self). So, you are definitely right about the
uselessness of my last 3 lines.
So, help me learn from your tests:
assert ((-x-
On Mon, Jun 29, 2009 at 5:24 PM, Ryan Krauss wrote:
> Cool. Aaron said to add a pass, but now that I think about it, you are
> right, if it doesn't find a true case, it will just end up returning
> hash(self) < hash(negative_self). So, you are definitely right about the
> uselessness of my last
Updates:
Status: Fixed
Labels: -NeedsReview PassedReview
Comment #8 on issue 1568 by matt...@gmail.com: factoring is working too hard
http://code.google.com/p/sympy/issues/detail?id=1568
Now factor() doesn't use expand() if not necessary, e.g.:
In [1]: factor((x**
47 matches
Mail list logo
