Here's Kitonum's procedure in more-standard Maple, using recursion and avoiding unnecessary recomputation.

a:= proc(n::posint)
option remember;
     `if`(n::odd, thisproc(n-2)*thisproc(n-1), thisproc(n-3) + thisproc(n-2))
end proc:
(a(1),a(2)):= (1,2):

Here's Kitonum's procedure in more-standard Maple, using recursion and avoiding unnecessary recomputation.

a:= proc(n::posint)
option remember;
     `if`(n::odd, thisproc(n-2)*thisproc(n-1), thisproc(n-3) + thisproc(n-2))
end proc:
(a(1),a(2)):= (1,2):

@acer 

but I'll chip in with some anecdotal evidence if that's OK.

Sure, your input is most welcome. So, it seems that your technique is still roughly based on numcpus. Perhaps that optimal value was 1/16th? two tasks per core? I'd like to see how may threads Threads:-Seq, Threads:-Map, etc., use when there's no tasksize specified, but the code is hidden in the kernel procedure Threads:-MultiThreadInterface.

Darin:

Thank you for this post, from which I've attained more understanding of Threads:-Task in two readings than I've obtained in multiple readings of the help pages and prepackaged example worksheet.

Your examples of using Task in a scalable way, and most other examples I've seen, bifurcate the problem into subtasks until a "base case" is reached. The base cases seem somewhat arbitrarily chosen, and may end up being inefficiently small on future machines. Why not use kernelopts(numcpus) to determine how many subtasks to use? That would be scalable.

A few days ago, I also posted a question/Comment to another of your parallelization blog entries. I know that it's very easy for followups to old posts to be missed, so you probably didn't see it.

Do you mean long division of numbers or of polynomials?

@J4James

You should convert this to a separate question. There are some important issues here, probably some bugs. But nobody except you, me, and possibly Preben will see this if you don't make it a separate question.

It is not necessary to use plot3d; Preben was just giving an example.

pds2:-plot(T2(x,t), x=0, t= 0..5);

But I see several things very strange with the plots in this system. I think there's a bug, but I can't quite isolate it. The plot should be the same as pds2:-plot(diff(T(x,t),x), x= 0, t= 0..5). Furthermore, the plots

pds2:-plot3d(diff(T(x,t), x), x= 0..1, t= 0..5);
pds2:-plot3d(diff(T(x,t), t), x= 0..1, t= 0..5);

are identically 0, which contradicts the plot

pds2:-plot3d(T(x,t), x= 0..1, t= 0..5),

which seems normal.

@J4James

You should convert this to a separate question. There are some important issues here, probably some bugs. But nobody except you, me, and possibly Preben will see this if you don't make it a separate question.

It is not necessary to use plot3d; Preben was just giving an example.

pds2:-plot(T2(x,t), x=0, t= 0..5);

But I see several things very strange with the plots in this system. I think there's a bug, but I can't quite isolate it. The plot should be the same as pds2:-plot(diff(T(x,t),x), x= 0, t= 0..5). Furthermore, the plots

pds2:-plot3d(diff(T(x,t), x), x= 0..1, t= 0..5);
pds2:-plot3d(diff(T(x,t), t), x= 0..1, t= 0..5);

are identically 0, which contradicts the plot

pds2:-plot3d(T(x,t), x= 0..1, t= 0..5),

which seems normal.

Your file of Maple code did not upload properly. Would you please upload it again?

Babak wrote:

Here is a ... problem based on theoritical analytic approach....

Yes, you are right about that. The question can be answered---and was intended to be answered---without
any plotting or computation. The domain E is closed, bounded, and connected. The function f is continuous. Therefore f(E) is closed, bounded, and connected. (Note well that the properties closed and bounded are
not necessarily individually preserved by a continuous function; they are preserved when they occur
together.)

Looks like a GRE Math subject test question.

@wkehowski Do you mean that you want the program to stop after a certain number of blocks? In such a way that it can be resumed later from where it left off? That would be fairly easy to implement.

I think that the greatest efficiency is achieved when doing 3 or more blocks at the largest blocksize your memory can handle. I just did C(44,7), which has 38 million elements, using a blocksize of 2^24 (16 Meg), which used about 9 GB. It took 108 minutes and produced a file of 598 MB. If you extrapolate that to the 38 billion elements in your C(113, 7), it's just barely feasible with a few months of computation and a middling size disk drive.

What filter are you using?

Unfortunately, the big bottleneck is the nextcomb. I'm going take a closer look at that and see if I can rewrite it to be more efficient.

@wkehowski Do you mean that you want the program to stop after a certain number of blocks? In such a way that it can be resumed later from where it left off? That would be fairly easy to implement.

I think that the greatest efficiency is achieved when doing 3 or more blocks at the largest blocksize your memory can handle. I just did C(44,7), which has 38 million elements, using a blocksize of 2^24 (16 Meg), which used about 9 GB. It took 108 minutes and produced a file of 598 MB. If you extrapolate that to the 38 billion elements in your C(113, 7), it's just barely feasible with a few months of computation and a middling size disk drive.

What filter are you using?

Unfortunately, the big bottleneck is the nextcomb. I'm going take a closer look at that and see if I can rewrite it to be more efficient.

Maybe an automatic update via the web would be better. There's probably one centralized site with all the constants.

Darin wrote:

The most obvious way in which procedures can be thread unsafe is if they share data without
synchronizing access.

What are the other ways that procedures can be thread unsafe?

@emma hassan Then you need to use ?textplot . Also, I think you realize this, but just to make sure: g is a list, so its indexing starts at 1. So, g[1] gives a[-1], g[2] gives a[0], etc.

@emma hassan Then you need to use ?textplot . Also, I think you realize this, but just to make sure: g is a list, so its indexing starts at 1. So, g[1] gives a[-1], g[2] gives a[0], etc.