On 28.04.2012 02:42, Aaron Meurer wrote:
On Fri, Apr 27, 2012 at 2:46 PM, Tom Bachmanne_mc...@web.de wrote:
A quick update:
I implemented a much better selection strategy for the groebner basis
algorithm (sugar cube), implemented the extended version (with
trasformation matrix) and improved
On Sat, Apr 28, 2012 at 12:42 AM, Tom Bachmann e_mc...@web.de wrote:
On 28.04.2012 02:42, Aaron Meurer wrote:
On Fri, Apr 27, 2012 at 2:46 PM, Tom Bachmanne_mc...@web.de wrote:
A quick update:
I implemented a much better selection strategy for the groebner basis
algorithm (sugar cube),
On Fri, Apr 27, 2012 at 2:46 PM, Tom Bachmann e_mc...@web.de wrote:
A quick update:
I implemented a much better selection strategy for the groebner basis
algorithm (sugar cube), implemented the extended version (with
trasformation matrix) and improved the algorithm to compute module quotients
The first algorithm in the paper where ratsimpmodprime was taken from should
probably do quite well - as far as I can tell it shoud be about as fast
as polynomial=True (maybe two or three times slower, or something of
that order - not 100 times), and work quite well (it minimizes the
maximum of
I implemented a new option polynomial=True. As explained in the
docstring, this essentially just applies reduced(). If given a
polynomial, and using a graded order (as by default), this is guaranteed
to return a *polynomial* equivalent to what we started with, of minimal
degree, but no other
On Sun, Apr 22, 2012 at 5:08 AM, Tom Bachmann e_mc...@web.de wrote:
I implemented a new option polynomial=True. As explained in the docstring,
this essentially just applies reduced(). If given a polynomial, and using a
graded order (as by default), this is guaranteed to return a *polynomial*
On 22.04.2012 20:23, Aaron Meurer wrote:
On Sun, Apr 22, 2012 at 5:08 AM, Tom Bachmanne_mc...@web.de wrote:
I implemented a new option polynomial=True. As explained in the docstring,
this essentially just applies reduced(). If given a polynomial, and using a
graded order (as by default), this
The first algorithm in the paper where trigsimp was taken from
(I mean ratsimpmodprime, not trigsimp.)
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send
Hi,
I implemented some optimizations (not yet pushed) which allowed me to run
trigsimp_groebner(smallExpr, quick=True, hints=[2])
in reasonable time (~5 minutes).
The result is this:
ddq1*(sin(q2)*sin(q4)*cos(2*q3) + cos(q2)*cos(q3)*cos(q4)) -
ddq2*sin(2*q3)*sin(q4) + ddq3*cos(q3)*cos(q4) +
Ok, so I pushed the changes to my trigsimp branch. There are two
commits, WIP and WIP2.
The basic idea is the following: suppose there are two sets of
variables, x1,..., xn, y1, .., yn, such that none of the xi appears in
the generators of the ideal -- they are free generators. Then really
Hi Tom,
On Saturday, April 21, 2012 10:42:42 AM UTC-4, Tom Bachmann wrote:
Instead of spamming further I will now really wrap this up and submit a
pull request.
Thanks for working on this. In the example below, there seems to be a
problem with integer constants in rational expressions. I
Thanks for reporting this, I'll fix it :-).
On 21.04.2012 19:06, Ben Goodrich wrote:
Hi Tom,
On Saturday, April 21, 2012 10:42:42 AM UTC-4, Tom Bachmann wrote:
Instead of spamming further I will now really wrap this up and submit a
pull request.
Thanks for working on this. In the
I didn't enable cython in the polys, but for me,
trigsimp_groebner(smallExpr, quick=True, hints=[2]) takes 194 seconds
in your latest branch. On the other hand,
smallExpr.rewrite(exp).expand().rewrite(cos).cancel() takes 12
seconds, and produces the same answer.
So there's still some work to be
On 21.04.2012 20:52, Aaron Meurer wrote:
I didn't enable cython in the polys, but for me,
trigsimp_groebner(smallExpr, quick=True, hints=[2]) takes 194 seconds
in your latest branch. On the other hand,
smallExpr.rewrite(exp).expand().rewrite(cos).cancel() takes 12
seconds, and produces the same
O well, I was too quick in replying. This involves all sorts of
non-polyonmial expressions and compositions of transcendental functions.
I'm afraid the groebner algorithm does not work with this (in the
current form, at least, and I don't see how to make it work either).
On 21.04.2012 20:48,
I tried the expressions from
https://groups.google.com/d/topic/sympy/3y6orHV2_4k/discussion (see
the tarball linked to in the first post). I just tried the small
expression with n=1, but it just hung on the reduction step. Any
thoughts on how to make this faster? Those expressions would make
I just remembered something important (I'm not sure why I forgot about
it before). It's going to be slow with multiple generators simply
because the polys are slow with multiple generators. This is because
the recursive dense representation used in the polys is highly
inefficient for polynomials
That could be true. The groebner algorithms actually use a minimal
sparse representation internally. But running trigsimp_groebner on
smallExpr for me hangs on a * d_hat - b * c_hat - (not even the
conversion to sparse or reduction, yet) just a multiplication of (huge)
polys.
As I said, I'll
i want to evaluate this function . can you tell me which branch i need to
checkout ?
On Fri, Apr 20, 2012 at 1:37 PM, Tom Bachmann e_mc...@web.de wrote:
That could be true. The groebner algorithms actually use a minimal sparse
representation internally. But running trigsimp_groebner on
one quick question ..
how to set SYMPY_DEBUG=True ?
On Fri, Apr 20, 2012 at 2:31 PM, Tom Bachmann e_mc...@web.de wrote:
Absolutely!
git pull
https://github.com/ness01/**sympyhttps://github.com/ness01/sympytrigsimp
The function is called trigsimp_groebner. But please note that I only
Just bin/isympy (or whatever you use) with this in the environment. E.g.:
SYMPY_DEBUG=True bin/isympy
On 20.04.2012 11:45, gsagrawal wrote:
one quick question ..
how to set SYMPY_DEBUG=True ?
On Fri, Apr 20, 2012 at 2:31 PM, Tom Bachmann e_mc...@web.de
mailto:e_mc...@web.de wrote:
i was evaluating this function.Few points which i noticed are below
1. in current TrigonometricFunction we dont have csc and sec which
are kind of must in trigonometry simplification ( for now may bwe can have
empty classes ..just to use theorems)
2. After 4 or 5 loops this is taking
missed the sample code for applying identity
def apply_basic_trig_identities(self,expr,get_mapping=True):
applied_theorems=[]
'''
will apply basic trigonometric identities
'''
need_mapping=True
a=Wild(a,dummy=True,exclude=[0])
1. in current TrigonometricFunction we dont have csc and sec
which are kind of must in trigonometry simplification ( for now may
bwe can have empty classes ..just to use theorems)
There are more or less finished classes in the Trigonometric branch
and pull request [1]. It's a bit old and
4. Also , identity like 1-sin(x)**2 = cos(x)**2 are not applied (try
trigsimp_groebner((1+sin(x))*(1-sin(x)) . this can be handled if
we apply all identity first as mentioned in 3rd point)
Yes. Anything beyond reducing the degree is somewhat fiddly. Basically
the algorithm excludes certain
Actually, I was being overzealous. This does't quite work.
On 20.04.2012 14:40, Tom Bachmann wrote:
4. Also , identity like 1-sin(x)**2 = cos(x)**2 are not applied (try
trigsimp_groebner((1+sin(x))*(1-sin(x)) . this can be handled if
we apply all identity first as mentioned in 3rd point)
Yes.
On Fri, Apr 20, 2012 at 2:07 AM, Tom Bachmann e_mc...@web.de wrote:
That could be true. The groebner algorithms actually use a minimal sparse
representation internally. But running trigsimp_groebner on smallExpr for me
hangs on a * d_hat - b * c_hat - (not even the conversion to sparse or
Hi,
so as promised I ran some timings.
Raw data first
--
I first tried
trigsimp_groebner((sin(n*x)/cos(n*x)).expand(trig=True), hints=[tan, n])
This essentially benchmarks groebner basis computation for ideals with
many generators.
In [23]: for n in range(1, 8):
:
On 20.04.2012 19:50, Aaron Meurer wrote:
On Fri, Apr 20, 2012 at 2:07 AM, Tom Bachmanne_mc...@web.de wrote:
That could be true. The groebner algorithms actually use a minimal sparse
representation internally. But running trigsimp_groebner on smallExpr for me
hangs on a * d_hat - b * c_hat -
It avoids some (hopefully many...) of the monomials by taking only those not
divisible by leading monomials of the groebner basis. (These monomials form
a basis of the quotient space, which is the most basic property of groebner
bases.)
From what I can see, the final result may be smaller,
On Fri, Apr 20, 2012 at 1:18 PM, Tom Bachmann e_mc...@web.de wrote:
It avoids some (hopefully many...) of the monomials by taking only those
not
divisible by leading monomials of the groebner basis. (These monomials
form
a basis of the quotient space, which is the most basic property of
Sure. But I think (possibly contrary to what I said earlier), staircase
really isn't the problem. If the result is huge then the next parts (calling
reduced(), solving the linear system) are going to take ages as well.
Maybe we should run kernprof on it to see what function calls are
really
On Fri, Apr 20, 2012 at 1:22 PM, Tom Bachmann e_mc...@web.de wrote:
Sure. But I think (possibly contrary to what I said earlier), staircase
really isn't the problem. If the result is huge then the next parts
(calling
reduced(), solving the linear system) are going to take ages as well.
On 20.04.2012 20:31, Aaron Meurer wrote:
On Fri, Apr 20, 2012 at 1:22 PM, Tom Bachmanne_mc...@web.de wrote:
Sure. But I think (possibly contrary to what I said earlier), staircase
really isn't the problem. If the result is huge then the next parts
(calling
reduced(), solving the linear
On Fri, Apr 20, 2012 at 2:17 PM, Tom Bachmann e_mc...@web.de wrote:
On 20.04.2012 20:31, Aaron Meurer wrote:
On Fri, Apr 20, 2012 at 1:22 PM, Tom Bachmanne_mc...@web.de wrote:
Sure. But I think (possibly contrary to what I said earlier), staircase
really isn't the problem. If the result is
On 20.04.2012 21:38, Aaron Meurer wrote:
I'm sorry ^^. It's cProfile. (I run it via python -m cProfile ... got the
letters mixed up in my head).
Oh, I know about that one :) But what graph did you get?
Well the output is in gprof format, and there is a gprof2dot script
floating around on
On 18.04.2012 23:25, Aaron Meurer wrote:
Opts is mostly passed through to polys. You probably shouldn't use the
gens=.. option. It is probably a good idea to pass order=grlex or
order=grevlex -- for reasons that are not clear to me the default order in
polys is lex. In any case, unless you pass
Hi,
thanks for the input. I'm thinking about it.
Tom
On 19.04.2012 06:55, Ronan Lamy wrote:
Le mercredi 18 avril 2012 à 22:48 +0100, Tom Bachmann a écrit :
[Sherjil, I'm CC-ing you because in my head you are the linear algebra
expert :-)]
One last update for today: I tried to implement code
I tried adding tan double angle identities to the generators list by
adding tan(k*x).rewrite(cos).expand(trig=True), but I couldn't get
just sin(x).rewrite(tan) to simplify (though I could get some other
stuff to work, like
mytrigsimp(tan(2*x).rewrite(cos).expand(trig=True), n=2)).
By the way
On Thu, Apr 19, 2012 at 1:24 AM, Tom Bachmann e_mc...@web.de wrote:
On 18.04.2012 23:25, Aaron Meurer wrote:
Opts is mostly passed through to polys. You probably shouldn't use the
gens=.. option. It is probably a good idea to pass order=grlex or
order=grevlex -- for reasons that are not clear
On 19.04.2012 17:46, Aaron Meurer wrote:
The ideal you generate has to be prime :). In particular, if we want to say
add tan(x), we would like to prove that the ideal
c**2 + s**2 - 1, c*t - s of CC[s, t, c] is a prime ideal. This sort of
problem can be non-trivial (In fact it's not at all
Hello,
On Thu, Apr 19, 2012 at 8:31 PM, Tom Bachmann e_mc...@web.de wrote:
Probably. I'll try to code up a more coherent routine in the next couple of
days which we can then base improvements on.
I beg my pardon for not participating in this discussion; I'd be very
glad to read the reference
On 19.04.2012 18:52, Sergiu Ivanov wrote:
Hello,
On Thu, Apr 19, 2012 at 8:31 PM, Tom Bachmanne_mc...@web.de wrote:
Probably. I'll try to code up a more coherent routine in the next couple of
days which we can then base improvements on.
I beg my pardon for not participating in this
On Thu, Apr 19, 2012 at 11:31 AM, Tom Bachmann e_mc...@web.de wrote:
On 19.04.2012 17:46, Aaron Meurer wrote:
The ideal you generate has to be prime :). In particular, if we want to
say
add tan(x), we would like to prove that the ideal
c**2 + s**2 - 1, c*t - s of CC[s, t, c] is a prime
Well if we are being non-rigorous, then being prime basically means that you
have *all* the equations. For example the ideal generated by (s**2 + c**2 -
1)**2 is obviously not prime, because we forgot to add the equation s**2 +
c**2 - 1.
I see. My intuition comes partly from the wikipedia
@ness01
Cool.This thread is grabbing my attention and myself to get my hands
dirty.Anyways 3 more exams and i am done.Will be participating actively. :)
On Fri, Apr 20, 2012 at 2:33 AM, Tom Bachmann e_mc...@web.de wrote:
I have pushed a more usable trigsimp_groebner to my new trigsimp branch.
Great. I think the best way to demonstrate new functionality like
this is to just create a special function that does it (like
trigsimp_groebner) in some branch, and add that to __init__.py. Then,
when it is ready to go in, remove it from __init__.py and integrate it
directly into the main
Hi all,
I managed to improve the situation quite a lot. The new code is this
time attached as a patch, or alternatively see my (ness01) branch trigsimp.
Executive summary: run mytrigsimp, test the function mytrigsimp. Ignore
the debugging output, pass order=grlex or grevlex for sensible
[Sherjil, I'm CC-ing you because in my head you are the linear algebra
expert :-)]
One last update for today: I tried to implement code which finds a
nice solution.
Problem statement: let Ax=0 be a homogeneous system with non-trivial
solutions. Find a non-trivial solution with maximal
On Wed, Apr 18, 2012 at 1:27 PM, Tom Bachmann e_mc...@web.de wrote:
Hi all,
I managed to improve the situation quite a lot. The new code is this time
attached as a patch, or alternatively see my (ness01) branch trigsimp.
Executive summary: run mytrigsimp, test the function mytrigsimp. Ignore
Here's exactly what I changed, by the way:
diff --git a/mytrigsimp.py b/mytrigsimp.py
index 0b6288d..12715ab 100644
--- a/mytrigsimp.py
+++ b/mytrigsimp.py
@@ -9,15 +9,18 @@ def build_ideal(x, n):
The main tradeoff here is performance: the more expressions we introduce,
the slower the
Le mercredi 18 avril 2012 à 22:48 +0100, Tom Bachmann a écrit :
[Sherjil, I'm CC-ing you because in my head you are the linear algebra
expert :-)]
One last update for today: I tried to implement code which finds a
nice solution.
Problem statement: let Ax=0 be a homogeneous system with
Hi all,
so recently we (I ...) pushed the function ratsimpmodprime, created by
Mateusz' last year's gsoc student. It can be used to simplify fractions
modulo prime ideals, and it was suggested we try to incorporate in into
trigsimp. I tried basically that [with little success, see below].
Actually, solving the systems is quite fast. Not sure what the prolem is
so far...
On 17.04.2012 20:39, Tom Bachmann wrote:
Hi all,
so recently we (I ...) pushed the function ratsimpmodprime, created by
Mateusz' last year's gsoc student. It can be used to simplify fractions
modulo prime
Ah, sorry for the spam. It's computing the reduced normal forms.
On 17.04.2012 20:47, Tom Bachmann wrote:
Actually, solving the systems is quite fast. Not sure what the prolem is
so far...
On 17.04.2012 20:39, Tom Bachmann wrote:
Hi all,
so recently we (I ...) pushed the function
55 matches
Mail list logo
