@Kitonum 

Note that recent versions of Maple can handle examples with parameters (with some issues, though):

> solve(a*x = b, x,parametric,real);
                     {  [[x = x]]         And(a = 0, b = 0)
                     {
                     { [[x = b/a]]              0 < a
                     {
                     { [[x = b/a]]              a < 0
                     {
                     {     []                 otherwise


> solve((x-a) = x^2, x,parametric,real);
     {                      1/2                       1/2
     {             (1 - 4 a)                 (1 - 4 a)
     { [[x = 1/2 - ------------], [x = 1/2 + ------------]]        a < 1/4
     {                  2                         2
     {
     {                     [[x = 1/2]]                             a = 1/4
     {
     {                          []                                 1/4 < a

@dohashi 

Note that my observations were about running Carl's example which is somewhat different. Anyway, I find that itsme's hack is the most interesting thing to look at now (until his point 2 is addressed), in particular about the balance between parallelism gains and overhead losses. And I wonder how all this compares with gridMathematica / Mathematica's Parallelize, etc (a comparative review would be nice).

@itsme 

Actually, this is part of a longer story. Just a bit of it. During the Maplesoft Virtual Show, held on 27 February, there was a presentation on "Advanced Maple Programming Techniques" by Paul, Darin and Erik. At some point of the chat session I have asked: "is making the whole library thread-safe feasible? If so, how far is it?" (sounds familiar?). The more concrete answer that I have received was from Darin: "We have a plan for gettng there, but it will take some time.". Not much optimistic, as you may see. Then Paul tried moving the focus: "There are multiple ways to achieve parallelism in Maple.", "Third, there is a Grid package in Maple that gives you distributed programming.", and the rest of the discussion was largely about the Grid package, where I showed some of the problems faced by the ordinary user (no need to give details, isn't it?). So, I am here, trying to discover how much the Grid package is a valid option... 

@Carl Love 

Yes, my fear is that new code might be needed.

@Carl Love 

I have run your code in Maple 18 CLI independent sessions on Linux 32-bit in the machine described above and got somewhat different results. At some point, 9 (=N+1) mserver processes are shown, OK. But the %CPU are quite different, both along the session and from session to session. For example, in a session they show up all 0%, then all %96, then some %96 and the rest %24, then a pair %96 and %0 the rest, and so on until they disappear. Some other sessions show %88, %40, etc. It sounds not much reliable figures... About memory, this is much more stable and lower than for you: typically 30-40MB each.

@ecterrab 

OK. Let me go to the present and future of inert functions. For some (tens? of) functions there are now a double set of inert forms: the "historical" capital letter form and the newer %-prefix form (Int and %int, etc). May be that in some cases there are some differences in functionality or whatever (I have not surveyed them, but for sure we have the case of Intat vs %intat). Backwards compatibility might be a reason to keep the capital letter form forever. But it makes coding somewhat more clumsy (to take into account both cases), longer, harder to maintain, etc. And it also requires keeping in mind both things simultaneously. Some reasons to unify at some point, I think. Any comment?

@dohashi 

So, it seems that we are talking about different things. You say: "The distinction between case 1 and case 2 is if the kernel calling Map is the main kernel or a grid kernel." But my point is the creation of the grid. Let us see, you have said:

In case 2, a grid node, as part of a running grid computation, calls Grid:-Map. This is the advanced case that is shown in the last example of the help page. So in the given example the main kernel creates a grid computation by calling Launch and the grid nodes, as part of that computation, call Map.

Then, which are the differences for the creation of the grid when it is done by executing Grid:-Map or by executing Grid:-Launch? Overhead (about copying the state)? What else?

@Carl Love 

I wonder about this waiting state. Say, that a (case 1) Grid:-Map command is launched. While it runs, how many mserver processes will you observe in the system monitor?

@dohashi 

Yes, of course, the first point to consider is the start of the grid. And to start with, obviously we should consider the simplest situation: local grid, no other processes requiring significant cpu time. So, this is what I have been talking about all the time. Now, let us see whether we can agree on this basic characterization.

For case 1, you say: "Thus on an N cpu machine there will be one cpu for each grid kernel." And we have also the main/controler kernel, which launched the grid, but remains running outside the grid, and "does very little work". So, where will it run? I see no alternative that it runs in a cpu which is running one of the grid kernels. And if there are N grid kernels and a controler kernel, there are N+1 kernels in total. Do you agree?

For case 2, you have said: "the main kernel creates a grid computation by calling Launch and the grid nodes, as part of that computation, call Map" and "a call to Grid:-Map from the main kernel will cause N local grid kernels to be started". So, as I understand it, the main kernel, running in one of the N cpus launches the grid creating grid kernels in each of the remaining N-1 cpus, and forming together an N kernel grid. So, in total there are N kernels. Do you agree?

@ecterrab 

I am curious about such historical issues (medio chusma, digamos). Is there anything interesting to tell about the subject of that discussion?

@dohashi 

Besides saying how not [multitasking operating systems schedule processes to cpus] I would expect that you describe how the kernel processes (grid and controler) are scheduled, organized, etc, for cases 1 and 2. It would be a step forward.

@Stephen Forrest 

When you say "that Maple 18 introduces UTF-8 as its default encoding across all platforms" you mean Maple 18 Standard GUI or all the interfaces? Also, I do not see any information on this change in ?updates,Maple18,compatibility . Where was this change documented? And what was exactly the situation of encoding in Maple 17? (so that the nature of the change may be understood).

@Carl Love 

It all depends on the context. Within the context of interactive symbolic computations, that is symbol manipulations as you would do by hand, the Intat expression may be not programatically generated, but entered by hand. Next, whatever its origin, the only safe way to proceed with such symbolic computations is using inert functions all the way, as you do not want automatic operations (simplification, normalization, etc) to interfere, altering the computation path. Only at the end, or at specific points, of these symbolic computations, which may involve many steps, actual active computations may be desired. So, the count of value's and %'s depends on the details of the computation.

@acer 

No, I think that there are too many quirks at the syntactic level derived from specific details of the underlying data structures to be meaningfully documented for the typical user wishing "mathematical" pattern matching. This is obviously not a problem exclusive to Maple and, in a sense, it is more acute e.g. in Mathematica where pattern matching is at the core of the system. Precisely for this reason, Richard Fateman implemented a proof of concept for such a mathematical pattern matcher, as described in this paper. I just quote an excerpt from that paper to note that, mutatis mutandis, we are at the same problem:

The most obvious flaws in the Mathematica system arise because the transformations are based on patterns matching the underlying internal forms of expressions in Mathematica. These are familiar to computer scientists who are schooled in compiler and data representation technology: they will recognize this form as an "intermediate expression tree." Unfortunately, parts of this form may be unfamiliar to Mathematica users, since it does not necessarily conform to the more familiar surface syntax used by Mathematica for input and output of mathematical expressions, and there is no particular reason to expect a user to be aware of the nuances.

So my opinion, as I have stated several times, is that two levels of pattern matching are needed in Maple, superseeding what is available now (typematch, patmatch, etc): a syntactic (low-level) one, implemented in the kernel, for efficient programming and a semantic (high-level or mathematical) one, implemented on top, for the "normal" user. This mathematical pattern matcher should include/combine/extend current facilities like algsubs and `simplify/siderels`.

@dohashi 

No, again, I am not interested in considerations about multiple machine situations, which you call "distributed". So, in single machine situations, which you call "local", is "controler kernel" the same as "main kernel"? Yes or no?

You say: "With local grid the default is always to create N grid kernels." OK, but my question was about the (default) total number of kernels and their location in cases 1 and 2. Could you answer it?

It is unclear what you suggest that I believe. Frankly, I do not believe anything in particular. Rather, I am just trying to make sense what I read in the documentation of Grid package and in your posts, which I do not find clear enough.