Please do not re-ask unanswered Questions in a separate thread; they'll simply be deleted and anger the Moderators. Please do not use the Posts section for Questions. If you want to increase the visibility of your Question, either editing the Question itself or posting a Reply to it will raise it to the top of the "Recent conversations" stack.

Note that there are only about 20 people here who regularly answer Questions, and they all do it voluntarily, even those who work for Maplesoft.

Your Question is somewhat obscure and requires a somewhat lengthy Answer. I will Answer it. Be patient.

Before I answer, I'd like to know what Maple version (such as "Maple 2020") you're using. For all future Questions, please put your Maple version in the header.

@nm Yes, the problem is the difference between local and global evaluation rules. So why is it a problem if you need to use eval? Or, you could compare to 'NULL' rather than to NULL as in

boo:= proc() 'NULL' end proc:
foo:= proc() local b:= boo(); evalb(b='NULL') end proc:
foo();
                              true

However, in the bigger picture, I do agree with both Acer and Joe: Returning FAIL or a Record or a table is a better choice. 

@emendes You asked:

• Would catch: #any other error be the answer for the errors I mentioned in my answer to @acer?

Yes, if you're willing to write a block of code under that catch: that'll do something reasonable (such as return FAIL) for all catchable errors.

• 1) If there is an error, catch will caught it, right?

Mostly yes. All catchable errors will be caught. Not all errors are catchable, but the vast majority are.

• 2) If there is an error in line 2 for instance, all commands in line3 to line 4 will not be evaluated, right? 

Yes, without exception.

@janhardo In general, the answer is no because there are fundamental theoretical limitations. Look up "Richardson's Theorem" (for example, in Wikipedia).

On the other hand, if you're willing to sacrifice some efficiency for user friendliness, and you're willing to accept an occasional FAIL as a non-answer, you could wrap all conditionals with is and not use evalb. Richardson's Theorem says that it's impossible to eliminate all FAILs.

@acer Yes, that's exactly how I envisioned it. It both resets the counter and avoids the need for the if t=x... statement. Admittedly, the ancient syntax (such as lack of keyword parameters) is awkward.

@acer Could the same thing be accomplished using the 2nd and 3rd arguments to `tools/genglobal`, the exceptions and the reset flag?

The help-page example that you're working on is flawed in a ridiculously ironic way because floor is not threadsafe. The expression

floor((j-i)/2) + i

should be replaced with

iquo(i+j, 2)

which is simpler, more efficient, and threadsafe.

@Ali Hassani You asked:

•  I was studying the commands of Grid package such as Map, Send, Receive, MyNode, and so on. As I previously said, the help pages of Maple are not appropriate for self-learning. I think it causes me to find many problems to implement what is in my mind.

In a sense, the help pages of most complicated software are necessarily "too complete" to facilitate self learning. They explain every command and option without suggesting an order in which to learn things.

I recommend that you learn Grid:-Map, Grid:-Seq, and Grid:-Set first and ignore the rest for now. If your tasks are independent of one another in the sense that the output of one task is not required as part of the input of another, then these commands will be enough. This covers a huge number of practical cases.

• I wrote the Map-versioned 'taylor' command as the following, however, it returns the error. what is the reason?
  Grid:-Map(taylor,[sin(x)],x,10);

As explained elsewhere, there is a bug when the input list has 1 element and the function takes more than 1 argument. Of course, having an input list with 1 element is not a practical use of Grid.

• Is it possible to tell me those commands being thread-safe but not listed in page index.threadsafe?

No, but let it suffice to say that the vast majority of Maple commands are not threadsafe.

To assuage any nitpickers: There is a mechanism called option lock whereby any command that is not threadsafe can---in a limited sense---be made threadsafe, but this option must be used with great care or you'll cripple the multi-threading mechanism, thus making things take longer than they would have had they been done sequentially.

@nm Even without a minimal example, it should be trivial to answer this, even if the code is 10,000 lines: Is the code that resets libname inside a procedure that is a local or export of the module? If it's not, then it's in the body, and it's not saved in the .mla.

Yes, I see that I prematurely jumped to the conclusion that it was in the body. As Acer explained, your example doesn't conclusively show whether that's true. To me, the other evidence that you presented seems to point that way.

Regardless of its applicabilty to this particuar case, my Answer above explains the one fundamental difference between a module read from an .mla and one read from a plaintext file. So, I see the Answer as useful either way.

@janhardo Those A's are what I was refering to, in another Reply, for changing the color (to blue, or any other color). The A on the left changes the text color; the A on the right changes the background color.

@Ali Hassani You asked:

• Does the following sentence is true?

  The Threads[Task] package, which is shared memory, is applicable only for the commands listed in “Thread-safe fucntions” in the help of Maple, and if ok, to execute another commands (not listed in “Thread-safe fucntions”) in parallel, we have to use Grid programming?

That is mostly true. I have discovered a few commands (such as index) which I've confirmed are threadsafe (by reading their code), yet they aren't listed on page ?index,threadsafe.

Another exception is code for the numeric evaluation of mathematical functions in hardware-float arithmetic under evalhf. So, while abs(...) is not generally threadsafe, evalhf(abs(...)) is.

• Another question is about Grid programming model. I know that Grid programming explain in the related help pages. However, its explanation by a person, can be usually more useful than the help pages. Please tell me some important keys of Grid prgramming as far as possible. 

Generally, most seq or map commands can be replaced with Grid:-Seq or Grid:-Map. These are the easiest ways to use Grid. But note that Grid can use much more memory.

• Does Grid programming is hard to write rather than Task programming model?

No, usually it's much easier.

• Does Grid:-Map(fsolve, Eqns) command is feasible to another commands such as taylor, solve and so on? If not, please guide me to learn about.

Yes, there are no specific restrictions on code that can be used with Grid. There is no concept "gridsafe" analogous to threadsafe. Code that competes for write access to an external resource such as a disk file can be problematic (but it's still doable); however, the vast majority of Maple code does not have such competition.

@janhardo To get the blue output, I copy-and-paste **1D** output (interface(prettyprint= 0 or 1)) from my worksheet and then use the pull-down menu labeled "A" to change the color.

@Ali Hassani Unfortunately, the commands solve, fsolve, taylor, and coeftayl cannot be used in the shared-memory environment of Threads. But there is a package called Grid that does multiprocessing without shared memory. It's a bit slower and of course uses more memory.

Example: Suppose that Eqns is a list of a thousand systems of equations that you want to solve with fsolve. Then just do

Grid:-Map(fsolve, Eqns);

@Kitonum zip was added in Maple 4.2.

Your method can be extended via seq to one or more lists (or other posint-indexable structures) by

MapThread:= f-> [seq](f(seq(a[i], a= args[2..])), i= 1..nops(args[2])):