@sarra 

Download H1.mw

@vv The conversion to exp broke for this in Maple 10.03.

restart;

kernelopts(version);

             Maple 10.02, X86 64 LINUX, Nov 8 2005 Build ID 208934

ee := 3^(-(1/2)*n)*2^((1/6)*n)-2^((2/3)*n)*6^(-(1/2)*n):

convert(ee,exp);

    exp(-1/2 ln(3) n) exp(1/6 ln(2) n) - exp(2/3 ln(2) n) exp(-1/2 ln(6) n)

simplify(combine(%));

                                       0

And,

restart;

kernelopts(version);

            Maple 10.03, X86 64 LINUX, Mar 24 2006 Build ID 222373

ee := 3^(-(1/2)*n)*2^((1/6)*n)-2^((2/3)*n)*6^(-(1/2)*n):

convert(ee,exp);

                        (n/6)  (n/2)     (n/3) 2  (n/2)
                       2      6      - (2     )  3
                       --------------------------------
                                 (n/2)  (n/2)

...with the ensuing difficulties we see in this thread.

@vv If n=s+t*I then with arbitrary real s and t we get coverage of arbitrary complex n which was the question at hand.

I doubt anyone's suggesting that Maple ought not be able to get all this easily -- I'm not.

@faisal You can send me a contact (via email) using the "Contact" button here. After I reply to that by email you can send me a longer message with an attachment, say.

@faisal If you are using Maple 2015 then it may be that you did not intend the extra (errant) space between brackets in D(F) (etainf) and that the GUI automatocally inserted it.

If you are using Maple 2015 then you could disable so-called Smart operators by unchecking the box in the preferences dialogues. See the main menubar and Tools->Options->Interface->"Smart operators". It is a bug in the Smart operator facility that it inserts an extra space between round brackets in so common a situation as the initial conditions on derivatives as expected by the dsolve command! You can disable this feature and save that preference globally, so as to cover future Maple sessions.

See also here and here.

@markweitzman That undefined result is coming out of the FTOC (Fundamental Theorm Of Calculus) method=ftoc that is one of the approaches int can take for definite integration.

By forcing the ftocms method the desired result can also attain. The difference in the methods consists (mostly) of whether the :-series and :-limit or the MultiaSeries:-series and MultiSeries:-limit commands are used.

Sorry, I do not have the time to dig down into the integration engine, to debug and figure out where it goes wrong with method=ftoc. It may be some kind of hint, that it works if the abs is turned into Heaviside up front. (It could also be related to the limits where tp=t but that is pure conjecture.)

Download MWP44_edited2.mw

@Markiyan Hirnyk  How is the answer given for that so-called precedent relevant here?

@Tzrpla 

p1:=plot(sin, -Pi..Pi,-1..1):
t1:=plots:-textplot([Pi/2,0.8,typeset("(",x[0],",",y[0],")")]):
t2:=plots:-textplot([-Pi/2,-0.8,typeset("(",x__0,",",y__0,")")]): # italic zero
plots:-display(p1,t1,t2);

@Christian Wolinski The penny finally drops for me. And now the functional programming fist is recognizable.

Welcome to the forum.

@Christian Wolinski I see distinct remember tables in my 64bit Maple 2015.2 and on my 64bit Linux machine in all versions back to and including Maple 11.02.

I see a shared (and thus clobbered) remember table between proc f and copied proc p in Maple 9.5 though.

What OS and Maple version are you using?

restart;
interface(prettyprint=1);
                                      1

p:=proc(x) option remember; x^2; end:
p(3.4);
                                    11.56

op(4,eval(p));
                            TABLE([3.4 = 11.56])

f:=copy(eval(p)):
op(4,eval(f));
                            TABLE([3.4 = 11.56])

[addressof(eval(p)), addressof(eval(f))];
                [18446884509604021454, 18446884509604021718]

[addressof(eval(op(4,eval(p)))), addressof(eval(op(4,eval(f))))];

                [18446884509603813726, 18446884509603814302]

p(5.7): # add a new entry to p's remember table
op(4,eval(p)); # changed as I'd expect
                      TABLE([5.7 = 32.49, 3.4 = 11.56])

op(4,eval(f)); # unchanged as I'd hope
                            TABLE([3.4 = 11.56])

interface(version);
  Standard Worksheet Interface, Maple 2015.2, Linux, November 13 2015 Build ID 1087698

@markweitzman I am submitting a bug report, and citing this example.

@vv Thanks. I was adding that example while you were typing your comment. I stand by the suggestion that the casual user may get more joy with seq than have to remember (or understand) such subtleties.

@markweitzman Did you see the bit where I said that I recommend evaluating the Matrix entries up front instead of forcing a valuie for Normalizer? I really meant it.

This is not a bug in LinearAlgebra. It is a bug in the Matrix palette (or typesetting, or some combination of that and the palettes). Working around the palette bug by introducing blind over-evaluation into Library routines would be irresponsibly bad. It should be fixed in the palette, and worked around by the user by evaluating (once) upfront.

I see no such problem in at least Maple 12.02, 17.02, 2015.0 and 2015.2 .

Download lae.mw

Could it be that you have some other package loaded, or something in your initialization file that interferes?

Right before you call Eigenvectors, what do each of the commands eval(Normalizer) and eval(Testzero) produce? One way to get that all-zero result for the eigenvectors Matrix is to have Normalizer set to something other than identically normal and weaker than radnormal or simplify. It's important for the nullspace computation that the radicals are dealt with, including adequate zero-recognition while choosing pivots.

acer

Step 5 involves obtaining roots of a polynomial of degree n, and I don't see how the restrictions on the unknown elements (from step 1) are enough to provide an explicit symbolic solution to that.

What would you eventually do with these n functions? If at some point (no matter how far down the road) you are going to want to evaluate these functions at numeric values of the unknowns then why would not a "black box" apporach work? For that I mean that your Matrix in step 1 has n^2-n unknowns. You could construct a procedure which accepted values for the unknowns and returned the final n eigenvalues. You could then call this procedure (on the fly) and so simulate the n functions at any numeric value set. Would that suffice? You could also try calling that procedure with symbolic values and -- if there were some strong pattern of commonality to the symbols used for the n^2-n parameters -- possibly arrive at special cases of somewhat nice explicit n formula. Do this sound like it might do?

acer