On Thu, Apr 19, 2012 at 11:31 AM, Tom Bachmann <[email protected]> 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 ideal. This sort of >>> problem can be non-trivial (In fact it's not at all obvious how to >>> proceed >>> here, at least to me. Algebraic geometry probably suggests some clever >>> methods for thinking about this. The half-angle formule involving tan >>> come >>> to mind...). If I interpret macaulay2 right, then this ideal is prime >>> over >>> QQ, which means it is almost certainly prime over CC (and a rigorous >>> argument can probably be made). >> >> >> My algebra is still to weak to be of much help here. My intuition >> tells me that as long as all the identities we add are true, then they >> should be prime, because the consistency of them will prevent any bad >> things from happening. But that's a long way from any kind of >> rigorous argument :) >> > > 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 page, which gives an example of <x**2 + y**2 - 1, x> as a non-prime ideal. If we let x = cos(t) and y = sin(t), then this amounts to saying sin(t)**2 + cos(t)**2 = 1 and cos(t) = 0, and of course the last equation is wrong. But your example shows that correctness is not sufficient. > > >>> >>> In any case it does not really matter (for correctness) if the ideal is >>> *not* prime. The worst thing that happens is that ratsimpmodprime proves >>> it >>> is not prime and raises an exception ^^. >>> >>> >>>> I tried adding tan(x)*cos(x) - sin(x) to the ideal and (after fixing >>>> the above bug), I got a lot of cool results, like >>>> >>> >>> Nice :-). Adding the following kinds of generators is definitely safe: >>> >>> (new generator) - (arbitry poly in old gens) >>> (new generator)*(arbitrary expression in old gens) - 1. >> >> >> Awesome. This kind of algorithm is extremely general, then. We can >> clearly add all the trig functions (including sec, csc, and cot), and >> it will automatically find the "best" representation among them >> (lowest degree). Furthermore, we can also generalize it to hyperbolic >> trig functions, and indeed, simplification of other kinds of >> transcendental functions as well. >> > > Yes it is very general. Certainly hyperbolic functions work. > > One thing to remember is that as we use more generators, the algorithm gets > slow fast. But it seems to work quite well, so I guess only experience will > show if it is feasible. Also, the more generators you add, the more "weird" > answers you can get (e.g. simplifying sin(x)**3 with n=2, 3 etc yields more > and more complicated answers of the same degree). Here we really start to see the importance of having fast Groebner basis algorithms. Have you tried playing with using the f5b algorithm implemented last summer? Aaron Meurer > > Also note that ratsimpmodprime can in principle do more than just minimizing > the degree, so some further tuning is probably possible. > > >> So one thing that we might want to work on is improving rewriting and >> pattern matching so that we can easily do this. rewrite() is >> currently limited in the kinds of rules it can accept. For example, >> there are several ways to rewrite tan(x) in terms of sin. Some will >> just use sin(x), some will also include cos(x). Depending on what you >> want to do, some of these may be more useful than others. >> Furthermore, it would be perfectly legitimate under the current system >> for tan(x).rewrite(sin) to return any of them. We need to think of a >> better way to framework this. >> >> I'm sure we'll also start to run into limitations of pattern matching >> if we do this seriously. >> > > Probably. I'll try to code up a more coherent routine in the next couple of > days which we can then base improvements on. > > Tom > > > -- > 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. > -- 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.
