Yes, different forms of an expression can have different amounts of numeric error (eg, loss of precision).

It is quite common in numeric models of evaluation in scientific computing, and is not specific to Maple.

One way to deal with it is to raise working precision (either using the Digits environment variable, or more locally via the manner of calling the evalf command).

Download num_examp.mw

There are ways to gauge the amount of accrued numeric error. For example the precision of those supplied values for the parameters could be quantified (as tolerances, or intervals, etc), which could allow one to gauge accuracy of the resulting evaluation (as a function of the variable working precision).

Are you trying to multiply both numerator and denominator by the conjugate of the denominator?

Perhaps you also want to follow that up with simplification, and to illustrate doing it step by step?

Is the name x supposed to represent an unknown purely real quantity?

Download rtnz.mw

See the CodeTools:-Usage or the time commands.

With the time command, you may wish also to utilize assign, eg,

    time[real]( assign('ans', somecomputation) );

It depends on whether you want the timing to be merely printed, or accessible programmatically as a returned value.

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