Try adding the file as "maple.ini" to the location that is returned after issuing the Maple command,

  kernelopts(homedir);

Make sure that you're not inadvertantly saving the file as "maple.ini.txt".

Also, it's probably a better idea to just issue the command and not always load the `plots` package. Ie,

  plots:-setcolors("Spring"):

acer

coeff(convert(ggg,polynom),t,-1);

The point is not so much to get something of type polynom as much as it is to remove the `O` term.

acer

The command,

Typesetting:-Settings(functionassign=false):

will cause subsequent occurences of that bit of 2D Math input syntax to be parsed as a remember table assignments. You could put that inside the Startup Code Region of your Document/Worksheet. This is better than leaving it as a popup query since you may wish to pass your document along to someone else unfamiliar with your intention.

Or switch to using 1D Maple Notation input mode in execution groups, where the syntax in question is unambiguous and always parsed as a remember table assignment. See Preben's response for a way to do that session-wide or even cross-session.

You could then still create operators using the superior, unambiguous syntax which works in both 1D Maple Notation and and 2D Math input modes,

BG := (i,j) -> stuff

acer

The runtime redistributables of some MKL v11.x exist in Maple 18.01 for 64 bit Linux and OSX. I have obtained some performance results for the cited Matrix float[8] Rank test using Maple 18.02 that are pretty much identical to those of Mathematica 9 and 10, on those two platforms. I tried up until about size 2500x2500. (See also this post and comment.)

The version of MKL used in Maple 18.x on 32 and 64bit Windows appears to be some v10.x, which series dates from about 2008-2009. And on the 64bit Windows platform (which is what Nasser used in the first link you've cited) there is still a discrepancy. A quoted timing of 0.35 sec for computing all the singular values of a 1000x1000 float[8] Matrix is pretty fast, but not as fast as the quoted timing for Mathematica as 0.16 sec.

The author of the pages in the first link you gave posted in the Wolfram Community forum a while back. He encountered new out-of-memory problems when running his test at larger sizes in Mathematica 10. He apparently resolved that by setting a preference to disable the new multi-undo feature.

acer

One way is to use a customized system. Eg, compare the before and after.

restart:

Unit(m^2*kg/(s^4*A));

simplify( Unit(m^2*kg) / Unit(s^4*A) );

simplify( 1/Unit(s) );

with(Units):
AddSystem( MySI, GetSystem(SI), volt/microsecond, hertz );
UseSystem( MySI );

Unit(m^2*kg/(s^4*A));

simplify( Unit(m^2*kg) / Unit(s^4*A) );

simplify( 1/Unit(s) );

This should also work with Units[Standard] functionality, combine(..,units), etc.

Note that other poswers of these dimensions are not necessarily affected. To get 1/second^2 to come out as Hz^2 you'd need to also include hertz^2 in the additional arguments, when defining the new system. Etc.

Another way is to just compute with some stock system like SI, and then convert final results. Eg,

restart:
convert( 55*Unit(mm^2*g/(ms^4*A)), units, volt/microsecond );

acer

add(x, x in A);

or,

convert(A,`+`);

or, (essentialy like the last one),

`+`(A[]);

acer

If you are not using high precision (ie, Digits > evalhf(Digits) ) then you may as well just use method=LU. And that is the default method for such float data.

Below, I set the infolevel so that some additional details about the computation are shown.

restart;
with(LinearAlgebra):

infolevel[LinearAlgebra]:=2:

A:=Matrix([[1,3],[2,5]],datatype=float):
b:=Vector([1,1],datatype=float):
LinearSolve(A,b);

LinearSolve: using method LU
LinearSolve: calling external function
LinearSolve: NAG hw_f07adf
LinearSolve: NAG hw_f07aef
                                    [-2.]
                                    [   ]
                                    [ 1.]

acer

The display command is part of the plots package. So either load that package first, by issuing,

with(plots):

or call it by its long-form names plots:-display or plots[display].

I edited your code a bit. As a general rule, don't try and use a non-indexed name such as x alongside its indexed form such as x[i]. Check that I didn't mess it up.

restart:

h := .1;
x[0] := 0;
y[0] := 1;
xf := 3;
n := floor(xf/h);
f:= (x,y)->1/(3*y-x-2);

for i from 0 to n do
k1 := f(x[i], y[i]);
k2 := f(x[i]+(1/2)*h, y[i]+(1/2)*h*k1);
k3 := f(x[i]+(1/2)*h, y[i]+(1/2)*h*k2);
k4 := f(x[i]+h, h*k3+y[i]);
k := (k1+2*k2+2*k3+k4)*(1/6);
y[i+1] := h*k+y[i];
x[i+1] := x[i]+h
end do:

data := [seq([x[n], y[n]], n = 0 .. 30)]:

p[2] := plot(data, style = point, color = blue):
p[3] := plot(data, style = line, color = blue):

exact := dsolve( { diff(Y(X),X)=1/(3*Y(X)-X-2), D(Y)(0)=1 } ):

Pexact := plot( eval(Y(X), exact), X=0..3, style=point,
                symbol=cross, symbolsize=20,
                adaptive=false, numpoints=20 ):

plots:-display(seq(p[n], n = 2 .. 3), Pexact);

acer

What you see at the end of the AiryBiZeros procedure is an unevaluated return. Notice the single right-quotes in that function call, which will be a return value.

It just means that, when argument n is something for which the procedure cannot compute a result then the procedure returns an unevaluated function call to itself.

acer

In your example eq is of type `=` and lhs(eq) is of type `+`.

The op command allows you to pick off specific operands (addends of the sum), by position.

restart:

act := proc(eqn)
  if type(eqn,`=`) and type(lhs(eqn),`+`) then
    eqn - op(2, lhs(eqn));
  end if;
end proc:

act( a + b = 0 );

                             a = -b

act( a + b + c = 0 );

                           a + c = -b

acer

eq := (a*b+a)^n * a^(-n):

new := (b+1)^n:

eval( [eq, new], [a=-1, b=-2, n=1/2] );

                            [-I, I]

simplify(eq) assuming real, a>=0;

                                   n
                            (b + 1) 

simplify(eq) assuming n::integer;

                                   n
                            (b + 1) 

acer

Remove the inert=true option.

If you include that option then it returns an inert integral. If you don't then it tries to compute the integral.

acer

What all these do... is another question.

restart:
interface(warnlevel=0):
started := false:
T := 'T':
for i from 1 to 1000 do
  f := eval(parse(cat("proc() option builtin=",i,"; end proc")));
  p := (s->StringTools:-Take(s,StringTools:-Search(";",s)-1))(convert(eval(f),string)[26..]);
  if not type(parse(p),posint) then
    T[i] := p;
    started := true;
  else
    if started then i:=1000; next; end if;
  end if;
end do:
i;
[ entries(T,nolist) ];
nops(%);

acer

Try setting infolevel[`pdsolve/numeric`] before calling the solver.

For example,

infolevel[`pdsolve/numeric`]:=2:

At value 2 I am seeing a brief description, such as, "Deriving 3-point (space) theta scheme for input PDE". At value 3 I am seeing printout of what appear to be differencing procedure(s).

acer

One way to get that smoother is to use the `gridrefine` option of implicitplot. Eg,

plots:-implicitplot(-x^3+3*x+a = 0, a = -3 .. 3, x = -4.0 .. 4.0,
                         view = [-3 .. 3, -4 .. 4], gridrefine = 2);

acer