That is a very difficult question, in general. For particular calculations (and implementations of algorithms to achieve them) the number of digits of working precision can be estimated. But in general it's difficult (read: unsolved).

Sometimes these sorts of issues in floating-point calculations can be handled by interval arithmetic. But then the degree of success depends on the strength and comprehensiveness of the interval arithmetic imlementation. (And Maple's is not perfect.)

These are just illustrative examples below, of merely some sorts of possible cause. The re-ordering of terms in a sum (multivariable polynomial) may be session dependent and so lead to differing answers.

> a,b,c:=-1.0*x*z,1.0*x*z,1.0e-20*x*z;
                                                      -19
                 a, b, c := -1.0 x z, 1.0 x z, 0.10 10    x z
 
> temp:=a+b: temp+c: %/c;
                                  1.000000000
 
> temp:=a+c: temp+b: %/c;
                                      0.

> add(t, t in [a,b,c]);
                                      0.
 
> add(t, t in {a,b,c});
                                       -19
                                0.10 10    x z

That is a very difficult question, in general. For particular calculations (and implementations of algorithms to achieve them) the number of digits of working precision can be estimated. But in general it's difficult (read: unsolved).

Sometimes these sorts of issues in floating-point calculations can be handled by interval arithmetic. But then the degree of success depends on the strength and comprehensiveness of the interval arithmetic imlementation. (And Maple's is not perfect.)

These are just illustrative examples below, of merely some sorts of possible cause. The re-ordering of terms in a sum (multivariable polynomial) may be session dependent and so lead to differing answers.

> a,b,c:=-1.0*x*z,1.0*x*z,1.0e-20*x*z;
                                                      -19
                 a, b, c := -1.0 x z, 1.0 x z, 0.10 10    x z
 
> temp:=a+b: temp+c: %/c;
                                  1.000000000
 
> temp:=a+c: temp+b: %/c;
                                      0.

> add(t, t in [a,b,c]);
                                      0.
 
> add(t, t in {a,b,c});
                                       -19
                                0.10 10    x z

> restart:
> a,b,c:=-1.0,1.0,1.0e-20:

> temp:=a+b: temp+c;
                                         -19
                                  0.10 10
 
> temp:=a+c: temp+b;
                                      0.

See also here (and in particular section on catastrophic cancelation).

> restart:
> a,b,c:=-1.0,1.0,1.0e-20:

> temp:=a+b: temp+c;
                                         -19
                                  0.10 10
 
> temp:=a+c: temp+b;
                                      0.

See also here (and in particular section on catastrophic cancelation).

I don't like that result from frontend. The form should be analogous to the result of diff(conjugate(z)+z^2,z), no? The contribution due to diff(z,conjugate(z)) isn't zero, is it?

Of course, all of it is in doubt if Maple's result for diff(conjugate(z),z) is not useful.

I don't like that result from frontend. The form should be analogous to the result of diff(conjugate(z)+z^2,z), no? The contribution due to diff(z,conjugate(z)) isn't zero, is it?

Of course, all of it is in doubt if Maple's result for diff(conjugate(z),z) is not useful.

This behaviour changed between Maple 10.06 and Maple 11.00.

This behaviour changed between Maple 10.06 and Maple 11.00.

Apart from Joe's (very good) advice, you might also consider applying evalf to the intermediate values of x, inside the loop. Otherwise, for an exact starting point the value of x at each iteration may be very large rationals (or worse, if your f generates radicals or trig calls, etc), with an unnecessary use of resources to compute subsequent steps. Also, try increasing Digits and then noticing how it affects the results. Lastly, don't just try the starting point 1, but also try 1/2 and 4/3, etc. You may discover something interesting.

Apart from Joe's (very good) advice, you might also consider applying evalf to the intermediate values of x, inside the loop. Otherwise, for an exact starting point the value of x at each iteration may be very large rationals (or worse, if your f generates radicals or trig calls, etc), with an unnecessary use of resources to compute subsequent steps. Also, try increasing Digits and then noticing how it affects the results. Lastly, don't just try the starting point 1, but also try 1/2 and 4/3, etc. You may discover something interesting.

That is correct.

If it poses a problem for you, note that you can always call module-based package's members by their "long form", regardless of what's been loaded. Eg,

restart:
with(LinearAlgebra):
with(ListTools):

A := Matrix([[1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12]]):
LinearAlgebra:-Transpose(A);

restart:
A := Matrix([[1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12]]):
LinearAlgebra:-Transpose(A);

Note also that the ?LinearAlgebra help page refers to this page on using packages.

Just a few points.

solve( detA, E, Explicit) can get the explicit solutions here, without a need for allvalues.

Eigenvalues( B, implicit ) can get RootOf form here.

In the commandline or Classic interfaces the representation of the result using common subexpressions is much shorter. (In some cases, such a form can lead to insight. See here for a bit more on this difference in interfaces.)

Just a few points.

solve( detA, E, Explicit) can get the explicit solutions here, without a need for allvalues.

Eigenvalues( B, implicit ) can get RootOf form here.

In the commandline or Classic interfaces the representation of the result using common subexpressions is much shorter. (In some cases, such a form can lead to insight. See here for a bit more on this difference in interfaces.)

For your first question, notice that solve may return zero (NULL), or one, or many results in a sequence. Your f does not allow for such, and passes whatever solve returns straight to plot, regardless of whether the result is a single numeric value or not. And so f can be passing invalid arguments to plot for certain x (eg. x=0.2). You might consider writing f as a procedure which examines the results from solve prior to returning.

This next is not very nice, however, as it runs amok,

#solve(-3.75+y^1.333333333,y);

For your second question, note that randomize() called with no arguments will set the seed according to your machine's system clock. But if not enough time has passed between them, the second call to randomize() will simply be setting the seed to the same value as it did the first time! So... don't do that. Just call randomize() once, at the start. You don't really need to change the seed within a single session, do you? You should get different Arrays anyway; that's how rand() works. Its method likely has a very long period, and it can generate many, many values before its pattern starts to repeat itself. Usually, one calls randomize() without arguments just once at the start of a session, to initialize it with a seed that is session dependent.

Find out whether any such add-on is officially supported by Maplesoft.

If not officially supported, discover whether you can see the full sources (including optionally rebuilding and installing completely by hand from source). Otherwise, how is the safety of using 3rd party add-on .mla/.lib/.m/.dll files for Maple significantly different from opening and executing attachments to email?