@Gillee You wrote, "The fix is to append datatype-float[8] to each of the Arrays" [within the followup example, which didn't use Statistics:-Sample].

Yes, that was the meaning of my previous three Replies.

Your Reply used the phrasing, "Lets determine the datatype of the first entry of dat". That phrasing and your ensuing methodology are technically invalid. Scalar objects (numeric values) do not have a "datatype". You can test them for various types but the word datatype in Maple is a technical term that applies to Vectors,Matrices, and Arrays but not to their entries if first extracted as scalar objects.

You should never use a word that is only a technical term as if it were a compound of non-technical terms. You should never refer to the "datatype" of a scalar as if you were referring to a particular type satisfied by a piece of data. Doing so unnecessarily confuses Maple technical terms with vernacular.

The Maple term datatype is different from the Maple term type. The term datatype refers to a restriction on rtables as to what they may contain.

Contrary to what your commentary suggested, it is not true that an Array would have a particular datatype just because an entry you extracted from it satisfies a particular type.

A := Array([17.0],datatype=float[8]);

                  A := [17.]

type(A[1], float[8]);

                    true

B := Array( [HFloat(17.)] );

                  B := [17.]

type(B[1], float[8]);

                    true

rtable_options(A, datatype);

                   float[8]

rtable_options(B, datatype);

                   anything

So you cannot "confirm" that the datatype of an Array is float[8] just because one of its extracted scalar entries satisfies a particular type. That simply does not follow, and the above is a counter-example.

I didn't write the original Question example, which used Array(1..100,SX(100)). In that example the result from SX(100) is a Vector[row] that has datatype=float[8].

The rtable constructors such as the Array command implement inheritance of hardware datatypes, unless dictated otherwise by the settings of UseHardwareFloats and Digits. So Array(1..100,SX(100) will inherit the same hardware datatype as SX(100).

restart;
X:=Statistics:-RandomVariable(Uniform(0,1)):
SX := Statistics:-Sample(X):
op(0,SX(100));

                 Vector[row]

rtable_options(SX(100), datatype);

                   float[8]

op(0, Array(1..100,SX(100)));

                    Array

rtable_options(Array(1..100,SX(100)), datatype);

                   float[8]

I do not know why the the Original Poster of the Question decide to cast each Vector[row] rtables from SX(100) into an Array. But he did. I simply wrote a compilable procedure that would accomodate that.

I would agree with the sentiment that it is confusing that the Help page for Statistics,Sample doesn't explain clearly what datatype the result will have (it only has an explanation of a special calling sequence, where one supplies the container for in-place computation).

@r66 But do you think that you had the equations correct, as you really did intend?

@ActiveUser In modern Maple the last line below could be,

   display(listplot~(LL,color=~([red,blue,green])));

But you have a much older version.

(Unfortunately you didn't provide the lists, so I have to make them up in order to show the example all done.)

Download listplots.mw

@radaar Give all three Arrays datatype=float[8].

Or don't Compile the procedure, and remove the datatype=float[8] from its three parameter specifications. (Of course that will be slower, but that was one of the earlier key ideas.)

The arguments passed to the procedure must be of the types in the procedure's parameter specification.

@radaar Yes, you get the error *because* you removed the float[8] datatype and the compiled procedure needs it.

Whatever else you might be trying to ask is unclear to me.

@radaar The procedure was written for Arrays with float[8] datatype. The original example has such Arrays. You followup example does not.

The key is in the error message (ignoring the part about what it received, which is unfortunate). It states that it expects a hardware float[8] rtable, and that's not what you are passing to it in your new example.

The addition and subtraction of the same multiple of x in the last equation (and other absence of automatic simplification) is indication of a cut&paste job.

It remains to be seen whether the OP might have made a transcription mistake, or might want a best fit (LeastSquares, say, easy enough after using GenerateMatrix).

@Gillee On my 64bit Linux the Threads:-Map is somewhat faster than the map instances, in Maple 2018.2 and 2020.1.

Keep in mind that n=100 is small, and Threads:-Map often needs a large number of items before the thread management overhead is small compared to the overall computation time. With n=100 there might not be any benefit, and the relative performance situation could even be switched on some platforms. That's not unreasonable.

You could also run with n=1000 or n=10000 and iterations=1. For n=10000 I see Threads:-Map being about twice as fast as map.

I should probably also have used a larger n to illustrate. The Original Poster had size equivalent to n=100 in his Question.

How accurately do you want to know evalf(R5)?

@radaar I wrote the FFG procedure so that I could Compile it. The Compiler will translate an `add` call to a loop anyway, so I doubt it'd improve much when compiled.

Moreover,  I've seen problems where the compiled translation messes up (casting floats to integers), so that's another reason I wrote out the loop myself.

What do you mean by, "I found out that my exact results are not correct"?

ps. I deleted one duplicate posting of this question. If you want to include a worksheet then attach it to a Comment here, instead of unhelpfully posting it in a new and separate Question thread.

You can check the exact result symbolically:

restart;
de:=diff(y(x), x) = 2*(1+x)-y(x):
Y:=dsolve({de, y(2) = 5});
                                                         
                          exp(-x)
        Y := y(x) = 2 x + -------
                          exp(-2)

eval(Y,x=2);

                y(2) = 5

evalb(eval(de, Y));

                  true

Are you trying to say that you had difficulty with your numeric computations?

@sepbergliaffa I didn't state that you ought to use just simplify(...,radical). I was trying to point out the difference between it as simplify(...,radical,symbolic), which is germane here.

The use of assumptions, and aspects of the symbolic option, is mentioned in the Help. That's why I referred to the Help.

@panke The code has to be such that the plots would be printed, or else it won't get sent to either the worksheet or any file.

I mentioned before (in two responses!) that you might want to wrap with a print call (if the plots wouldn't normally be printed due to further nesting, being inside a procedure, etc...).

If you terminate the loop with a full colon (or nest further, etc) then the plots wouldn't get printed inline either.That's why I suggested print(plot(...)) which you ignored when you used display(...).

@aoakindele What do you intend by  (D@@(F))(0)  in the boundary conditions?

@aoakindele 

You have a term
   F*(diff(theta(eta), eta))
in your DEs. Did you intend it to be, say,
   F(eta)*(diff(theta(eta), eta))

The error message states that "F(eta) and F cannot both appear in the given ODE". Doesn't that explain the problem?