You could assign the string (full and explicit name of the .mla file, with path) to a Maple name. Then you could pass that very same name to both commands, and in doing so avoid mismatch mistakes.

For example,

filenm := "C:\\Home\\Maple projects\\Test_package\\test.mla":
LibraryTools:-Create(filenm);
LibraryTools:-Save('testSavelib', filenm);

The above correction would also work in your original code, and avoid your mismatch between the your two lines related to the extra whitespace (that the second line had, while the first did not).

Regardless of the nature of your particular problem, I think that using LibraryTools:-Save is generally better (less error prone) than using savelib.

Why aren't you using fsolve for this?

CodeTools:-Usage(fsolve(1 + 0.15 = (1 + r__x)^1.28858));
memory used=1.33MiB, alloc change=0 bytes, cpu time=16.00ms, real time=16.00ms, gc time=0ns

              0.1145625357

Is there a numeric value for parameter a?

From your grainy image it looks like you may have accidentally only made the equation,

   a = 1

instead of doing the assignment,

   a := 1

It's more useful to upload and attach your actual worksheet (green up-arrow in the Mapleprimes editor) than it is to show only an image of your code.

Are you hoping to utilize all of those equations rC1,rC2,rf1,rA,rh to substitute for all of C1,C2,f1,A, and h?

Download limit1.mw

At lower (and default) working precision this example can encounter enough numeric round-off error that the symbolic solve command finds spurious roots if you perform non-inert symbolic solving and integration on the expression containing floating-point coefficients.

I suggest:
1) don't use RealDomain (it's not doing what you think, anyway, in your example).
2) use fsolve for numeric root-finding instead of solve here.
3) Don't introduce floating-point values instead of exact rationals if you can practically avoid doing so, especially if you intend on attempting symbolic integration or solving. (Symbolic integration/solving of an expression containing floats can sometimes do worse than trying to solve it numerically, or trying to solve an exact problem.)

If you left out RealDomain, and used exact rationals, then the spurious solutions from solve (due to floating-point round-off error) could be avoided by raising Digits. But it'd be better and faster to simply use a numeric root-finder for this problem which likely doesn't even have an explicit symbolic solution.

Download Working_ac.mw

If you really want to see more of the specifics of how it went wrong...

Download Not_working_ac.mw

You can call fsolve to compute a root between each of those.

But don't try and do it by appending (to a list, or Vector). That's a poor way to program, and habitually leads to unnecessary inefficiency in programs as they scale.

Instead, you could simply use seq (or map) to form the list. Or you could use Vector with a constructor operator.

Download Asymptotes_acc.mw

Isn't this a repeat of one of your previous Questions?

For larger (symmetric) examples you will get a result more quickly by computing the eigenvalues of the Matrix (cast suitably to float[8] datatype, symmetric indexing function, etc).

You wrote in a followup comment, "In general, the matrices I encounter are real symmetric", so below I'll focus on code for that case.

Here's code for doing it via Eigenvalues, and an example where the SingularValues computation takes about 3.2 times as much wall-clock time, on my Linux machine. (That slowdown ratio could typically grow, as the Matrix size increases, but it can depend on the nature of the Graph data.)

SR := proc(G::Graph)
  local M := GraphTheory:-AdjacencyMatrix(G);
  max(abs~(LinearAlgebra:-Eigenvalues(
    rtable(`if`([rtable_indfns(M)]=[':-symmetric'],
           ':-symmetric',NULL), M,
           'datatype'=':-hfloat','storage'=':-rectangular',
           'order'=':-Fortran_order'))));
end proc:

M22:= GraphTheory:-SpecialGraphs:-M22Graph();

   M22 := Graph 1: an undirected unweighted graph with
          77 vertices and 616 edge(s)

CodeTools:-Usage(SR(M22), iterations=100);

memory used=270.28KiB, alloc change=38.59MiB, cpu time=1.84ms,
real time=1.86ms, gc time=110.19us

            16.0000000000000

G := GraphTheory:-SpecialGraphs:-CirculantGraph(2345,[1,2]);

    G := Graph 2: an undirected unweighted graph with
         2345 vertices and 4690  edge(s)

CodeTools:-Usage(SR(G));

memory used=242.85MiB, alloc change=107.52MiB, cpu time=5.75s,
real time=2.73s, gc time=312.03ms

            4.00000000000000

SpectralRadius_ac.mw

If you know certain additional qualities of the Graph up front (eg. Bipartite) then you might be able to attain even better speed by computing just the "first" selected eigenvalue. I had an old post on computing only selected eigenvectors/values. But it's not helpful if you have to call it twice to compute first and last (largest-positive and smallest-negative). I'm not sure whether this is workable.

These are all using external calling to LAPACK for dense matrix operations. ie. not sparse stuff.

Are you asking about how to get the exploration to appear in a new document, in a separate GUI tab? If so, then it can be done by using the Explore command explicitly, instead using rigght-click context-menu.

For example,

restart;

Explore(plot(sin(a*x)*x^2 + cos(b*x),
             x = -2*Pi .. 2*Pi, view = -30 .. 30),
        a = 1.0 .. 10.0, b = 1.0 .. 10.0,
        animate, newsheet, showbanner = false);

If you mean something else then you really ought to explain it more clearly. What do you mean by "save", and "extension file"?

That particular accent you've chosen may be getting parsed (in 2D Input) as conjugate(a). So you might be seeing a 2D Input version of this:

Download conjugate_sigh.mw

The same kind of thing seems to happen in the 2D Input parsing if I utilize the Layout palette (for "Over") and the Punctuation palette for inserting the "macr" over-bar. That is, I get a call to conjugate as the parsed meaning.

You could get the expected behaviour using the "Over" item from the Layout palette and then some other kind of over-bar from the Punctuation palette, eg. the "mdash", "minus", or "ndash" items. As over-bars those don't seem to make the names get parsed as calls to conjugate, instead parsing as distinct (typeset) names that behave more as you'd expected.

Please check whether you have shown the differential equation, and the value of lambda, correctly. (For example, what do you expect for 4*f(8) = x*f(eta) when x=4 and eta=8?)

As I parse the DE that you've shown, the value of 4*f(8) is only about 3.2 when lambda=0.5. But that doesn't correspond to the red color for the values near 4.0 in your colorbar. So either I've misunderstood the DE, or something else is not right.

Below I use lambda=0.005.

Download de_col.mw

[edit] Looking at the OP's previous postings it seems as if he might be using the significantly older Maple 17, in which case some of the above functionality is not available. Here is a revision, for that older version.

My query about the correctness of the DE and value of lambda still applies.

Download de_col17.mw

You are substituting 4 for instances of 3.

subs(3=4,3);

             4

subs(3=4,9);

             9

x:=3;

             3

subs(x=4, 3);

             4

subs(x=4, 9);

             9

Check whether this (or any other Answer) provides as many roots as expected. (Eg, compare against the plot, or compare methods against each other, etc.)

Download rf_examp.mw

Take any odd number X greater than 1 (ie. X is 3 or higher).

Subtract 2 from it. So,

   X = 2 + (X-2)

The result, X-2, is also odd. And 2 is even.

So X = 2 + (X-2) which is the sum of an even number and an odd number.

In programming, a common easy way to generate odd numbers is to add 1 to a multiple of 2. (Similarly, a common way to generate even numbers is to take multiples of 2.) For example,

seq( 2*n, n=1..5 );

          2, 4, 6, 8, 10

seq( 2*n + 1, n=1..5 );

          3, 5, 7, 9, 11

We can use that trick to generate the following output, using the print command to show them on separate lines. (Recall, 2*n+1 is the odd number...)

Download odd_stuff.mw

Something I have done in the past is redefine userinfo.

I once redefined it so as to redirect its output to TextArea Embedded Components. But in your case perhaps it might suffice to alter it to always act as if called from the Command-Line Interface (CLI, tty), ie. plaintext output.

I may have overlooked some corner-case(s), in which case it might require a tweak or two.

Download userinfo_redef.mw

You wrote, "Is it possible to recover that _R is in fact A, that _R0 is in fact B and so on?".

But question includes the assertion that "_R is in fact A", which may not be true. If you had also executed,
   P := A;
at the top level then both P and A would be assigned with value _R. So why would _R "in fact" be A, as opposed to being P? The claim, as stated, would not be true.

Having said that, you can cobble together (dodgy) schemes to find out what assigned names might evaluated to _R.

Download ooph.mw

I am not a fan of this kind of thing, which seems quite backwards to me. I think it's far more sensible to utilize lists of equations and then evaluate formulas using such equations. (Ie, don't make assignments that get in your way.) For example,

Download form_forwards.mw