• Simplifying exponential expressions

    From Peter Luschny@21:1/5 to All on Sat Aug 29 13:13:39 2015
    Consider

    f := t -> exp(-n*I*t)*(1+exp(exp(I*t)))/cosh(exp(I*t))/(exp(I*t*(1-n)) *(1+(exp(exp(I*t))-1)/(exp(2*exp(I*t))+1)));
    simplify(f(t));

    h := t ->(exp(-I*t)*(exp(exp(I*t))+exp(-exp(I*t))-2*cosh(exp(I*t))) /cosh(exp(I*t)));
    simplify(h(t));

    g := t -> (1/2)*(exp(exp(I*t))+exp(-exp(I*t)))/cosh(exp(I*t));
    simplify(g(t));

    I think every freshman equipped with a formulary can simplify this,
    unlike the "world's most powerful math engine".

    Or did I miss something?

    P.S.: If you want to know the solution try Wolfram/Alpha.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From none) (Rouben Rostamian@21:1/5 to peter.luschny@gmail.com on Sun Aug 30 04:37:43 2015
    In article <d1c99e89-d1f5-4d1d-ae68-c5259e531600@googlegroups.com>,
    Peter Luschny <peter.luschny@gmail.com> wrote:
    Consider

    f := t -> exp(-n*I*t)*(1+exp(exp(I*t)))/cosh(exp(I*t))/(exp(I*t*(1-n)) >*(1+(exp(exp(I*t))-1)/(exp(2*exp(I*t))+1)));
    simplify(f(t));

    h := t ->(exp(-I*t)*(exp(exp(I*t))+exp(-exp(I*t))-2*cosh(exp(I*t))) >/cosh(exp(I*t)));
    simplify(h(t));

    g := t -> (1/2)*(exp(exp(I*t))+exp(-exp(I*t)))/cosh(exp(I*t)); >simplify(g(t));

    I think every freshman equipped with a formulary can simplify this,
    unlike the "world's most powerful math engine".

    Or did I miss something?

    After simplify(), apply convert(%, exp).

    --
    Rouben Rostamian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Axel Vogt@21:1/5 to Peter Luschny on Sun Aug 30 15:24:07 2015
    XPost: sci.math.symbolic

    On 30.08.2015 14:30, Peter Luschny wrote:
    After simplify(), apply convert(%, exp).

    Thanks Rouben!

    The situation as I see it is: I want to go from San Francisco
    to Los Angles by car and buy a automotive navigation system.
    I start, follow the instructions and after a while I find
    myself in Las Vegas. So I call the manufacturer and complain.
    The manufacturer answers: Hey, there is another button on the
    device, the blue one, press it and it will lead you to Los
    Angeles. And indeed it does.

    So is this OK or absurd? I do know that an algorithmic solution
    of simplification problems require some regularizations and
    mapping to some standard internal representation before they
    can be solved. However it is the promise of a CAS to do this
    internally.

    In the examples I wanted expressions simplified to 1 or to 0
    not to an exponential expression. Other CASs understand this
    -- but not Maple.


    I do not think that there is a generally agreed way. And you
    example is not a good example, as many examples.

    Maple thinks that cosh is more simple than exp, it does not
    go that route without being directed. And it certainly does
    not try all routes.

    What I could 'accept' is: why exp(x)+exp(-x) does not show
    cosh when 'simplify' is called? But even that may have some
    good reason: having more terms it may be that one does *not*
    want that. For example consider some discounting function
    and after 'simplify' one would end up in trigonometric terms.
    Here it tries to simplify in terms of exp.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Luschny@21:1/5 to All on Sun Aug 30 05:30:43 2015
    After simplify(), apply convert(%, exp).

    Thanks Rouben!

    The situation as I see it is: I want to go from San Francisco
    to Los Angles by car and buy a automotive navigation system.
    I start, follow the instructions and after a while I find
    myself in Las Vegas. So I call the manufacturer and complain.
    The manufacturer answers: Hey, there is another button on the
    device, the blue one, press it and it will lead you to Los
    Angeles. And indeed it does.

    So is this OK or absurd? I do know that an algorithmic solution
    of simplification problems require some regularizations and
    mapping to some standard internal representation before they
    can be solved. However it is the promise of a CAS to do this
    internally.

    In the examples I wanted expressions simplified to 1 or to 0
    not to an exponential expression. Other CASs understand this
    -- but not Maple.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Luschny@21:1/5 to All on Sun Aug 30 14:40:03 2015
    And you example is not a good example, as many examples.

    What you want to say so? I did not invent this example
    to annoy you or Maplesoft. This obvious failure has happened
    to me while working on a problem. And in such a situation
    it is quite annoying when you have to leave your working
    context to look (and find immediately) the answer on the
    Internet at Wolfram/Alpha.

    Maple thinks that cosh is more simple than exp, it does not
    go that route without being directed.

    h := t ->(exp(-I*t)*(exp(exp(I*t))+exp(-exp(I*t))-2*cosh(exp(I*t)))/cosh(exp(I*t)));
    simplify(h(t));

    But 0 is even a bit more simple, isn't it? And I do not care
    whether "Maple thinks that cosh is more simple than exp" (how
    do you know that, by the way?), I want a quick affirmation that
    two formulas agree, and it is a standard procedure to subtract
    one from the other and look if it simplifies to zero.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Axel Vogt@21:1/5 to All on Mon Aug 31 22:10:46 2015
    On 30.08.2015 23:40, Peter Luschny wrote:
    ...

    I am not annoyed. And agree that here I would like to
    see the same as you expect to see, but also would like
    to understand what happens (ignoring Maple's adverts)

    May be you want to read the answer by Richard Fateman
    at sci.math.symbolic as well.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From RGVickson@shaw.ca@21:1/5 to Peter Luschny on Tue Sep 15 10:50:53 2015
    On Saturday, August 29, 2015 at 1:13:41 PM UTC-7, Peter Luschny wrote:
    Consider

    f := t -> exp(-n*I*t)*(1+exp(exp(I*t)))/cosh(exp(I*t))/(exp(I*t*(1-n)) *(1+(exp(exp(I*t))-1)/(exp(2*exp(I*t))+1)));
    simplify(f(t));

    h := t ->(exp(-I*t)*(exp(exp(I*t))+exp(-exp(I*t))-2*cosh(exp(I*t))) /cosh(exp(I*t)));
    simplify(h(t));

    g := t -> (1/2)*(exp(exp(I*t))+exp(-exp(I*t)))/cosh(exp(I*t)); simplify(g(t));

    I think every freshman equipped with a formulary can simplify this,
    unlike the "world's most powerful math engine".

    Or did I miss something?

    P.S.: If you want to know the solution try Wolfram/Alpha.


    I doubt there is universal agreement on the meaning of "simplify". I have personally encountered many situations where one form of "simplify" is bad in one problem/application and good in another one. I do agree that it can be frustrating to force any
    program to conform to the requirements of a particular application, and that sometimes having to over-ride a package's default can be annoying.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)