That's an interesting example, but it's easily explainable. Eigenvalues are unique, but eigenvectors are not: Any nonzero scalar multiple of an eigenvector is also an eigenvector. Different algorithms may present the eigenvectors in different forms. Maple chooses an algorithm based on the type of data in the Matrix. By including terms of the form 0*0.1, you make it choose a floating-point algorithm. Without including those, a purely algebraic algorithm is used: finding the roots of a cubic polynomial. If you normalize the two sets of eigenvectors, they'll be the same (upto a bit of round-off error).

Since your integral is with respect to eta, I don't think that anything can be said in general without knowing u. If the integral was with respect to u (as a name, rather than as a function of eta), then it's trivial as far as Maple is concerned: The antiderivative is expressed in terms of the roots of the denominator, regardless of the discriminant and regardless of whether the roots can computed exactly. If p(x) is any polynomial, then

int(1/p(x), x) = add(ln(x-r)/D(p)(r), r= [the roots of p(x)]);

If a first-degree linear model z = b0 + b1*x + b2*y doesn't fit well, the usual next thing to try is including first-degree products of the independent variables. In this case, that makes the model z = b0 + b1*x + b2*y + b3*x*y. Using this for the data that you present, all of the coefficients are highly significant (max p-value = 0.0024):

Statistics:-LinearFit([1, x, y, x*y], <X | Y | Z>, [x,y], summarize);
Summary:
----------------
Model: -2057.7133+988.24655*x+6195.9003*y-2973.2493*x*y
----------------
Coefficients:
              Estimate   Std. Error   t-value  P(>|t|)
Parameter 1   -2057.7133    495.8423      -4.1499   0.0011
Parameter 2    988.2466     203.4795       4.8567   0.0003
Parameter 3    6195.9003    1649.5165      3.7562   0.0024
Parameter 4   -2973.2493    673.0242      -4.4177   0.0007
----------------
R-squared: 0.7911, Adjusted R-squared: 0.7428

With (1-R^2) = 21%, there may still be, as you say, "great amount of standard errors". That may or may not be relevant. The residuals should be analyzed: Are they random and normally distributed? If yes, then it may not be possible to get a better model.

Also consider:

Statistics:-CorrelationMatrix(<X | Y | X*~Y | Z>);

These are only my newbie suggestions from an undergraduate-level knowledge of statistics. Mmcdara/Sand has deeper ideas.

Maple offers many subtle ways to delay evaluation so that the evaluation of specific subexpressions can be triggered at precise future times. Here are some examples:

restart:
a:= 3:
Template:= x-> a*e:
f:= subs(['a'= a, e= x^2], eval(Template));
                                            2
                               f := x -> 3 x 
restart:
Instantiate:= (Template::procedure, N::list(name))->
   subs(N=~ eval(N), eval(Template))
:
a:= 3: e:= x^2:
meta_f:= x-> a*e:
V:= '['a', 'e']': #2 layers of unevaluation quotes needed  
f1:= Instantiate(meta_f, V);
                                             2
                               f1 := x -> 3 x 
a:= 4: e:= x^3:
f2:= Instantiate(meta_f, V);
                                             3
                               f2 := x -> 4 x 

So, note that the exact same line of code, Instantiate(meta_f, V), has been invoked twice, with no direct change having been made to any of its names (Instantiate, meta_f, and V) in the meantime, and the result is two independent procedures, f1 and f2.

Like the other two respondents, I recommend that you use unapply for the particular situation that you present. However, there is a way to do it that is close to what you were trying, that is as efficient as possible, and that can be applied in some situations where unapply won't work:

e:= x^2: #Any expression that depends on x
f:= subs('F'= e, x-> F);

This must be done with subs rather than eval. The quotes around the F are optional. They'll make it work even if F is already defined. The e in the second line could be your %, but I think that it's best to avoid using % in finished code (i.e., something that's not scratch work).

In those cases where it's possible to get rid of the integral by taking a derivative, as VV has done, I recommend that you do that. However, those cases seem relatively uncommon (at least among the Questions that we get here). Usually the integrand also contains z, and then taking the derivative just makes it a more-complicated expression that still contains an integral. For those cases, do this:

INT:= proc(z)
local t;
   if not [args]::list(numeric) then return 'procname'(args) fi;
   evalf(Int(t^t, t= 0.1..z))
end proc:
   
Sys:= {diff(z(x),x) = x  + INT(z(x)), z(0.1)=0.1}:
Sol:= dsolve(Sys, numeric, known= [INT], range= 0.1..1);

The procedure must return unevaluated (rather than give an error) when passed nonnumeric arguments, so you need the line

if not [args]::list(numeric) then return 'procname'(args) fi;

(Those quotation marks are mandatory!)

If you want to add method selection and error control to the integral, that's fine.

I'm not sure why your solve didn't find all the solutions, but I suspect that it only looks for real solutions in equations that contain abs. What I usually do in cases like this is

• set z= x+I*y
• use evalc to extract the real and imaginary parts (Re and Im)
• solve these as a pair of simultaneous equations
• recompose z = x+I*y

Doing that in this case, I do get three solutions: -1, and two very long algebraic numbers of degree 3. I've verified that these give 0 in the original equation. I consider it necessary to verify the solutions in cases like these. I don't think that it's possible to make solve respect assuming real.

Here are my commands:

f:= z-> abs(z)*(z-4-I)+2*I - (5-I)*z:
Z:= x+I*y:
simplify~(eval~(Z, {solve(evalc~({Re,Im}(f(Z))), {x,y}, explicit)}));

That is a hard test problem! What is the level of the course?

Another four tries and I finally nailed it:

Explore(   
   plot3d(
      [[abs(sqrt(z^2+c)), theta, z], [abs(sqrt(z^2+c)), theta, -z]],
      z= `if`(c >= 0, -sqrt(8), sqrt(abs(c)))..sqrt(8), theta= -Pi..Pi,
      grid= [51, 36], 
      coords= cylindrical,
      #stabilize the axes' lengths for Explore 
      view= [-2..2, -2..2, -sqrt(8)..sqrt(8)],
      thickness= 0 #use thinness gridlines available
    ),
    #decimal points required for float Explore parameters,
    #lest they be treated like integers:
    c= -1.0..1.0 
);

Replace the entire for loop at the end with

(LI,LR):= selectremove(hastype, L2, nonreal(float));

Then LI will contain all the you solutions that have an imaginary component, and LR will contain the rest.

Note that real numbers are also considered to be complex, so searching for complex(...)  types is ineffective. Also, if you search with type, then the entire expression being compared will need to match the given type, which won't work because the items being checked are not numbers but sets of equations. That's why I use hastype instead. So, another way to search is

(LR,LI):= selectremove(type, L2, set(name = realcons));

To avoid the error, use add instead of sum. I'm assuming that RM is some coefficient matrix that's already defined? Then remove the unevaluation quotes.

If you continue to have trouble, please post a worksheet, including the values of RM.

I'm not sure what you mean by "associate". Do you mean that you want to make a new array composed of the two original arrays? Then, let's suppose that you have two one-dimensional arrays A and B of the same length, L. You can compose them into a 2xL array with

< A, B >

You can compose them into an Lx2 array with

< A^+ | B^+ >

The +-sign exponents mean "transpose".

There are many other ways that I can interpret "associate" that all have easy solutions in Maple. A type of association that's a bit esoteric but that I often use anyway is to define a function f which maps each element of A to its corresponding element of B:

f:= 'f': assign~(f~(A) =~ B):

You did HeffR:= convert(Heff, rational), but then you did Eigenvalues(Heff) rather than Eigenvalues(HeffR).

Assignments to sets and lists (whether by := or by subsop) are extremely inefficient. It is only begrudingly that Maple allows it for lists, and even that's only for small lists (upto size 100 I think). I think that that's allowed for the benefit of newbies doing homework problems (where efficiency doesn't matter much) who want to use lists as vectors or arrays. But nobody (in their right mind) wants to use a set as an array.

Assigning to set positions is even more inefficient than it is for lists because the new element needs to be put in the correct position (since sets are always stored sorted). So, even if S[k]:= x were allowed, after doing it, it wouldn't necessarily be true that S[k] = x or that nops(S) was the same as it was before. Those two facts alone make S[k]:= x too weird to consider using, regardless of efficiency concerns.

So, whenever you feel the urge to do S[k]:= x, you need to rethink that and come up with a better way to code it. There's always a better way. MaplePrimes can offer help in any situation like that.

If you change solve to eliminate, you'll get a less-trivial solution: a = (k^2-1)/3, b= 0, c= 0.

The Adams-Bashforth method is implemented in dsolve via

dsolve({...}, numeric, method= classical[adambash]);

See ?dsolve,numeric,classical