@Christopher2222 wrote:

One could instead create a proc that would circumvent the issue when StandardDeviation command is called, yes?

Yes, Statistics:-StandardDeviation could be overloaded so that when weights are passed in, it is diverted to separate user-supplied code; and when weights are not passed in, it uses the current code. Like this:

restart:
sav_std_dev:= eval(Statistics:-StandardDeviation):
unprotect(Statistics:-StandardDeviation):
Statistics:-StandardDeviation:= overload([
     proc(A::{rtable,list})
          option overload;
          local p, weights, sd;
          if not membertype(identical(':-weights')={Vector,list}, [args], p) then
               error "invalid input:"  # Kicks to next proc in overload
          end if;
          weights:= rhs([args][p]);
          print('weights' = weights);
          sd:= Statistics:-StandardDeviation(A);
          # Do whatever you want here to compute with the weights.
     end proc,

     sav_std_dev
]):
    
protect(Statistics:-StandardDeviation):

Please explicitly show in a worksheet the code that works and the code that doesn't work. Please state explicitly why you say that it hasn't worked.

@Carl Love To analyze where f(a,c,n) < 0, the 3d animation should be viewed in conjunction with an animation of the level curves f(a,c,n) = 0. This can be done with implicitplot.

plots:-animate(plots:-implicitplot, [f(a,c,n) = 0, c= 0..2, n= 0..4, gridrefine= 3], a= 0..2);

@Christopher2222 Yet it seems that the weights are used somehow in the computation. Changing the weights often changes the last digit or two of the standard deviation.

@Markiyan Hirnyk You're right; I missed that the OP's primary interest was the sign. The animation can be improved with the view option.

plots:-animate(plot3d, [f(a,c,n), c= 0..2, n= 0..4, view= [0..2, 0..4, -300..0]], a= 0..2);

@Carl Love Incorporating Joe Riel's %m hack into a convert procedure, we get

`convert/decimalfraction`:=
     (x::float)-> sscanf(sprintf("#%m%m", op(1,x), 10^(-op(2,x))), "%m")[]:

@Preben Alsholm Just to be absolutely clear, Preben's comment was merely meant to point out a flaw in the OP's final argument. It was not meant to deny the fact that there is a bug in product at play here.

@Joe Riel Obviously the "#" is the key to this hack. Can you describe other hacks using the %m technique?

@love maths Here's an example. I couldn't upload an executed example (some bug in MaplePrimes), so you'll have to execute this yourself.

Eigen:= proc(A::'Matrix'(2,2))
local
     a:= A[1,1], b:= A[2,1], c:= A[1,2], d:= A[2,2],
     s:= sqrt((a-d)^2+4*b*c)/2,
     e1:= (a+d)/2 + s, e2:= (a+d)/2 - s,
     ev1:= < c, (d-a)/2+s >, ev2:= < c, (d-a)/2-s >
;
     if s=0 then [] else [e1, e2, ev1, ev2] end if
end proc:

A:= LinearAlgebra:-RandomMatrix(2,2) + I*LinearAlgebra:-RandomMatrix(2,2);
Sol:= Eigen(A);
A.Sol[3] - Sol[1].Sol[3];
simplify(%);

@sarra There is no mistake. You can ignore the higher-order terms. The expression is still O(h^4) (as h-> 0). The purpose of big-O notation is to let you ignore higher-order terms.

@Preben Alsholm Thanks. I corrected the Answer.

@YasH See ?emptysymbol . Using `` as a function name has the same effect as using f or any other undefined symbol, except that `` does not print as anything.

I just answered that two days ago, here.

Is your primary objective to get the answers, or to do it by the Newton-Raphson method?

I can confirm all three of your observations on Windows 8.1/64 using Maple 17.02/64:

1. That there is a memory leak; indeed it is some of the fastest memory consumption that I've ever seen. The memory usage is not reported on the Maple status line.
2. That restart does not release the memory, even when followed by gc();
3. That the difference of the two integrals that should be zero is not even close.