@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.

@Michael_Ormstrup I recommend making the parameters more like the plot command itself: The range being passed in the form a..b, and the functions in a list if there is more than one. So, the parameter declaration would be

integralplot2:= proc(
     F::{algebraic, [algebraic, algebraic]},
     R::range,
    {[color, colour]:= blue, transparency:= 0.5, numpoints:= 500}
),    

f1, f2, a, b would become local, and the first two lines of code would be

(a,b):= op(R);
(f1,f2):= `if`(F::list, F, [F,0])[];

@Michael_Ormstrup I recommend making the parameters more like the plot command itself: The range being passed in the form a..b, and the functions in a list if there is more than one. So, the parameter declaration would be

integralplot2:= proc(
     F::{algebraic, [algebraic, algebraic]},
     R::range,
    {[color, colour]:= blue, transparency:= 0.5, numpoints:= 500}
),    

f1, f2, a, b would become local, and the first two lines of code would be

(a,b):= op(R);
(f1,f2):= `if`(F::list, F, [F,0])[];

@spradlig If you click on your name, or anyone's name for that matter, you can see lists of their Questions, Posts, Answers, and Favorites. You do not need to be logged in to do this.

@spradlig If you click on your name, or anyone's name for that matter, you can see lists of their Questions, Posts, Answers, and Favorites. You do not need to be logged in to do this.

I think that the option should be added to the plotsetup command as a plotoptions for the default plot device. The reason is that all the commands that produce plots actually produce an algebraic structure that should be device independent; device specific parameters should not be stored in that structure.

@emma hassan Are you saying that you want the numbers themselves actually printed on the plot?

@emma hassan Are you saying that you want the numbers themselves actually printed on the plot?

@maxou Once you take the derivative with respect to a variable appearing in exponents (rho in this case), the expression becomes vastly complicated. I have no idea on how to approach it.

@maxou Once you take the derivative with respect to a variable appearing in exponents (rho in this case), the expression becomes vastly complicated. I have no idea on how to approach it.

@Michael_Ormstrup To expand on it, I need to know what a and b represent. I would've thought that they were the plot range, but you don't use them in the plot command in your procedure.