exp(I*pi*n).simplify_exp() doesn't simplify

[dandrake]

At https://groups.google.com/d/topic/sage-support/Pkn1o1kAcyE/discussion I noted that currently (4.7.1 and 4.7.2.alpha2), we have this:

sage: n = var('n')
sage: assume(n, 'integer')
sage: exp(I*n*pi).simplify_exp()
e^(I*pi*n)

I was really hoping for cos(pi*n), or (-1)^n.

If you are serious about asking Maxima, it will simplify it, though:

sage: A = exp(I*pi*n)
sage: A.maxima_methods().rectform()
(-1)^n

We should somehow wrap rectform or make it easier to access. At a minimum, we should add something to the documentation to mention this possibility.

Depends on #13061

CC: @kcrisman @orlitzky

Component: symbolics

Keywords: maxima symbolics exponentials sd40.5

Author: Michael Orlitzky

Branch/Commit: 2fb52ed

Reviewer: Ralf Stephan

Issue created by migration from https://trac.sagemath.org/ticket/11785

[orlitzky]

comment:2

This is sort of a work-in-progress, but I'd appreciate comments on the approach.

[kcrisman]

comment:3

Hmm. Maybe for a first try we should just provide simplify_rectform or something more felicitously named regardless for now, and then discuss elsewhere whether it's useful to add this parameter. I'm not sure that string length is a good measure of complexity, though I'm not sure I have a better idea (other than total number of vertices of the expression tree, I suppose). In Maxima I don't think they do this, they just assume the user is smart enough to tell if it's simpler. As long as this isn't in the default simplification (not to reopen the simplify_full issue!), we might not want to open up a whole new file of complexity of a symbolic expression without input from experts in such things.

What do you think? I do like having this available, Dan isn't the first to ask. There are also some custom methods on some other ticket for pretty comprehensive dealing with the trig-complex issue, I can't remember where it is and don't have time to find it, though. You might want to do some snooping on sage-devel archives or on Trac for these.

[orlitzky]

comment:4

I tried it without the complexity measure first, but this function has a tendency to make expressions more complicated. If we're ever going to use it in e.g. full_simplify(), we need to be a little more selective about which results we accept.

It turns out, string length is actually a pretty good measure.

I implemented something close to the number of vertices in the expression tree:

from types import ListType

def flatten_list(l):
   result = []

   for item in l:
      if isinstance(item, ListType):
         result += flatten_list(item)
      else:
         result += [item]

   return result

def flatten_operands(operands):
   return operands + [flatten_operands(g.operands()) for g in operands]

def all_operands(expr):
    return flatten_list(flatten_operands(expr.operands()))

and then tried the len(all_operands(expr)) complexity measure. It also works, but is much much much slower and doesn't seem "better" than string length really. We could add that to the complexity_measures module as an option, but the dumb solution seems to work too.

(The way that I'm testing, by the way, is to replace simplify() with simplify_rect() and watch the failing doctests. Many of them are promising.)

Admittedly adding a new module just for this feels like overkill, but the alternatives weren't too appealing:

• Default to lambda x: len(str(x))
• Default to None, and use the string length in that case. Requires the user to pass lambda x: 1 to force the simplification (we'd also have to use less-than-or-equal-to in the function body).
• Remove the measure altogether; this usually wasn't a simplification.

Down the line, simplify_full() could potentially try simplify_foo() with every complexity measure, and return the expression that's simplest according to the measure you gave simplify_full().

[kcrisman]

comment:5

Interesting, and good longer-range ideas.

Apropos slowness, that might be worth testing anyway for this. full_simplify is probably really slow, but testing two different strings like this could make it really slow (not that that is done here). The "down the line" would probably be super-slow for that reason.

Also, along the lines of plotting and William's recent email complaining about how 2D plotting got away from not caring about the backend, it might be worth thinking about how to allow a number of backends for simplification as well... just a thought.

[loefflerd]

comment:6

Failing doctest (looks like a typo, should be complexity_measures):

File "/home/patchbot/sage-5.0.beta3/devel/sage-11785/sage/symbolic/complexity_measures.py", line 30:
    sage: from sage.symbolic.complexity_measure import string_length
Exception raised:
    Traceback (most recent call last):
      File "/home/patchbot/sage-5.0.beta3/local/bin/ncadoctest.py", line 1231, in run_one_test
        self.run_one_example(test, example, filename, compileflags)
      File "/home/patchbot/sage-5.0.beta3/local/bin/sagedoctest.py", line 38, in run_one_example
        OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
      File "/home/patchbot/sage-5.0.beta3/local/bin/ncadoctest.py", line 1172, in run_one_example
        compileflags, 1) in test.globs
      File "<doctest __main__.example_1[2]>", line 1, in <module>
        from sage.symbolic.complexity_measure import string_length###line 30:
    sage: from sage.symbolic.complexity_measure import string_length
    ImportError: No module named complexity_measure
**********************************************************************

[orlitzky]

comment:8

Whoops, that was a last-minute change to match the naming of groups,rings, etc. I fixed the 's' and renamed the method to simplify_rectform() per comment 3.