_Maxim_

734 Reputation

12 Badges

9 years, 90 days

MaplePrimes Activity


These are questions asked by _Maxim_

signum(0, abs(x), 0);
                       signum(0, |x|, 0)

signum(0, abs(tan(Pi/5)-sqrt(5-2*sqrt(5))), 0);
                               1

The second one should give 0 or return unevaluated.

 

aa := tan(Pi/11)^2;
bb := RootOf(_Z^5-55*_Z^4+330*_Z^3-462*_Z^2+165*_Z-11, index = 1); # bb = aa
ee := (exp(-Pi-I*Pi*aa/bb))^(1+I);

seq((proc() try timelimit(k, signum(Re(ee)-1/k)) catch: lprint(lastexception) end try end proc)(),
    k = 1..10);

`shake/shake`, "time expired"
`expand/sin`, "time expired"
`evalr/tan`, "time expired"
sdmp:-mul, "time expired"
                        1, 1, 1, 1, 1, 1

An explanation: aa/bb=1, so, as we know from here, ee=exp(-2*Pi), and ee is tricky to evaluate numerically. Normally signum(Re(ee)-1/5) just seems to hang indefinitely, which is not the worst thing it could do. But after one of the timelimit interrupts (or after clicking "Interrupt the current operation"), something breaks, and Maple starts returning wrong values.

This is in Maple 2017.2, system="X86 64 WINDOWS", wordsize=64.

Also, is there any way to clear the cached values so that this computation can be repeated without doing restart?

 

1. There is this weird bug:

evalc(Re((Re(z)+I*Im(z))^2)) assuming z::complex;
                                2
                               z 

which looks like the assumption got lost somewhere along the way.

2. simplify and evalc can't automatically handle these:

simplify(z-Re(z)-I*Im(z));
                      z - Re(z) - I Im(z)

evalc(z-Re(z)-I*Im(z)) assuming z::complex;
                      z - Re(z) - I Im(z)

simplify(Re(z)^2+Im(z)^2-abs(z)^2);
                          2        2      2
                     Re(z)  + Im(z)  - |z| 

evalc(Re(z)^2+Im(z)^2-abs(z)^2) assuming z::complex;
                          2        2      2
                     Re(z)  + Im(z)  - |z| 

One way to make it work is to do subs(z=Re(z)+I*Im(z),...) and then pass it to evalc. But see point 1. Another way that sometimes work is convert(...,abs).

Side note on convert: convert(...,Re) allows Im as well as Re. I think that's not very useful: typically the point of convert is that I want to get rid of other functions.

3. evalc tends to leave functions of complex argument unexpanded:

evalc(conjugate(sin(z))) assuming z::complex;
                                /_\
                             sin\z/

The real and imaginary parts aren't separated. Again, one way to make it work is this:

evalc(conjugate(sin(Re(z)+I*Im(z)))) assuming z::complex;
       sin(Re(z)) cosh(Im(z)) - I cos(Re(z)) sinh(Im(z))

But see point 1. Also, using just Re(z) and Im(z) won't always give the simplest form.

In fact, even for Re(sin(z)), which is technically already the real part, I'd say it's not very useful for evalc to just give back Re(sin(z)). sin(Re(z))*cosh(Im(z)) is a more useful output, with functions applied only to real quantities.

Using x+I*y instead of z won't help with the simplify examples, but evalc seems to work fine when all variables are assumed to be real.

 

It would be nice to have asymptotics for hypergeom that are valid around abs(z)=infinity for any value of argument(z):

limit(hypergeom([1, 1], [2, 2], I*z), z = infinity); # zero
      limit(hypergeom([1, 1], [2, 2], I z), z = infinity)

series and asympt can give the expansions for +infinity or -infinity, not necessarily valid for other directions. FunctionAdvisor gives only the expansion at +infinity (which in this case is valid for Re(z)>0). Changes of variables like z->-z or z->1/z seem to never work in FunctionAdvisor(asymptotic_expansion, ...).

Also the expansions around z=1:

limit(hypergeom([1, 1, 1], [1/2, 2], z)*(z-1), z = 1); # zero
          /         /           [1   ]   \               \
     limit|hypergeom|[1, 1, 1], [-, 2], z| (z - 1), z = 1|
          \         \           [2   ]   /               /

And on the branch cuts:

limit(hypergeom([1/3, 1/3], [1/2], 2+I*a), a = 0); # the directional limits are different
                            /[1  1]  [1]   \
                   hypergeom|[-, -], [-], 2|
                            \[3  3]  [2]   /

 

It seems that simplify uses some transformations that aren't generically valid, and evalf relies on those transformations too:

 

nint := (fz, zrng) -> evalf(add(
  int(fz, op(1, zrng) = op([2, i], zrng) .. op([2, i+1], zrng)),
  i = 1 .. nops(op(2, zrng))-1));
f1 := z -> MeijerG([[1/2], []], [[], []], z);

simplify(f1(z));
                       sqrt(1/z) exp(-1/z)

evalf(f1(-1));
                              -9                
               -1.672586379 10   + 2.718281828 I

f1(-1.);
                              -9                
               -1.672586379 10   - 2.718281828 I

nint(GAMMA(1/2+y)*(-1)^y, y = [-infinity-I, -I, I, -infinity+I])/(2*Pi*I);
                             -11                
               6.652676619 10    - 2.718281828 I

So it seems that evalf uses the simplified form, but that form doesn't agree with the definition of MeijerG for negative z. The form that does would be 1/sqrt(z)*exp(-1/z).

 

f2 := z -> MeijerG([[], [1]], [[0, 2], []], z);

simplify(f2(z));
                    exp(-z) z + exp(-z) - 1

evalf(f2(1));
                         -0.2642411177

f2(1.);
                          0.7357588823

nint(GAMMA(-y)*GAMMA(2-y)/GAMMA(1-y), y = [infinity-I, -1-I, -1+I, infinity+I])/(2*Pi*I);
                      0.7357588823 - 0. I

The result of simplify is off by -1. Just evaluating f2(1) doesn't use that transformation rule, but evalf apparently does.

 

First 10 11 12 13 14 Page 12 of 14