#11785: exp(I*pi*n).simplify_exp() doesn't simplify
--------------------------------------------------------+-------------------
Reporter: ddrake | Owner:
burcin
Type: enhancement | Status:
needs_work
Priority: major | Milestone:
sage-5.1
Component: symbolics | Resolution:
Keywords: maxima symbolics exponentials sd40.5 | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
--------------------------------------------------------+-------------------
Comment (by mjo):
Replying to [comment:9 ddrake]:
> I will ask some other people about the complexity measure stuff, but I
think your default is reversed: for anyone who knows a little Maxima, they
will expect something like `simplify_rectform()` to actually return what
Maxima's `rectform` returns -- but the default ''isn't'' to do that.
>
> Here's my proposal: by default, call Maxima's `rectform` and return
that. Don't import anything from `complexity_measures.py` by default, but
include documentation showing the user how to import that and use it in
the keyword argument.
[[BR]]
But why introduce a default that's not useful? Unless you're setting up a
toy example to show what `rectform` does, most expressions will be made
uglier. Maxima's `rectform()` isn't labeled a simplification; if we're
going to call it one, I think it should simplify.
If we call it a simplification and have it only do `rectform()` by
default, we're essentially requiring the user to both read the docs and
pass `make_it_work=True` on every invocation.
How many of our users are there that,
a. Know maxima '''and''' are familiar with its `rectform()` '''and'''
don't know about expr.maxima_methods().rectform() '''and''' would expect
`simplify_rectform()` to ''just'' call `rectform()`?
b. Use `simplify_foo()` and just want their expressions to get simpler.
I suspect (b) dwarfs (a).
I wouldn't mind if we just called it `Expression.rectform()` and
documented what it does, but I also don't think that it would be as
useful.
[[BR]]
> (Also, how hard is it to count the number of operands in an expression?
It's just `len`, right? If it isn't too hard, perhaps the documentation
could show how to use that as a complexity measure.)
[[BR]]
It depends on how thorough you want to be. A simple `len(expr)` will
return the number of top-level operands. If you want to count all operands
at any level, you either have to recurse (as I did), or know some
shortcut.
The former doesn't work well because you can have,
{{{
sage: f = huge_expression1 + huge_expression2
sage: len(f)
2
}}}
The latter works comparably to the string length, but was slow as dirt (my
implementation is lame). It could probably be improved, though. I would
definitely include this if some pynac magic can speed it up.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11785#comment:10>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" 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/sage-trac?hl=en.
