@sursumCorda Your code is slow for two reasons:

1. It's checking every value of y starting from 1.
2. It's redoing the harder modular arithmetic for every one of those y.

First of all, we can prove that any possible y is a multiple of 91. So 90/91 of your iterations don't find any solution. Second, the vast majority of the modular arithmetic required for this can be done once and for all by a single call to chrem.

I see that the "Product: " in the header of this Question has been changed from "Maple Calculator" to just "Maple". In Maple, the above series can be obtained by

convert(GAMMA(a,z), Sum, z= 0);

and making a few minor (high-school-algebra-level) simplifications to enhance the presentation.

@Traruh Synred I meant to just run the memory-measuring procedure 100 times to check whether it itself was contributing to the leak.

To diagnose the potential leak further, we need to see your code. You have thought that you've uploaded code a few times before, but it never seems to have worked. Can you describe what you do, exactly which buttons you press?

If need be, you can email me your worksheet. Use the "More" -> "Contact author" pull-down at the bottom of this message to send me a preliminary email, and then I'll send you an email address to use to send the file.

@C_R The double-arrow from the palette is being treated as an &-operator, which means that it has higher precedence than any other operator in the expression. So its left operand doesn't include the initial not. Both the left and right operands of <=> need to be parenthesized. 

As a completely separate issue, you also need to stop the automatic simplification of the right operand by making it (``(not P) and ``(not Q)) (using your desired palette symbols).

Doing these two things, I get this output for the 1st Law:
 

@Traruh Synred Initializing a variable in the same line that it's declared makes no difference.

Try running it 100 times in a row. Can't draw conclusions from just 2 runs.

I wouldn't call this a "tutorial", but it'll be a useful starting point if you haven't seen it already

help("OpenMaple,Python,API");

@Traruh Synred You wrote:

• I add the 63-word array that 'kerneloptos(memoryuse)' creates. 'MemoryInUse' doesn't do that. 

What makes you say that? Although it doesn't use an array per se, it does essentially the same thing using a list of lists. See its code via

showstat(MmaTranslator:-Mma:-MemoryInUse);

Local variables do get deleted when they go out of scope. For example,

MemUse:= proc() 
local M:= Array(kernelopts('memusage'))[..,3], x;
    add(x, x= M) 
end proc:

After calling MemUse(), M is inaccessible and gets deleted by the garbage collector.

Your header says "Maple Calculator". Do you just want to see the series for reference? If so, you could just look it up in an online reference. Or do you want it to do some calculations? I don't think that Maple Calculator is very practical for something that elaborate; not sure. I don't mean that it's incapable, just that entering and manipulating the formulae is awkward.

@vv I think that a reasonable and feasible goal for future Maple would be to give the mimimal exact integer solution to Archimedes's Cattle Problem, which is a famous ancient problem of the type in this Question. The answer has 206,545 digits, which is well within the capability of Maple's GMP integers.

@vv Okay then. I hadn't previously noticed your corresponding change of the coefficients.

@adel-00 You spelled solve as "slove".

Assign the result of solve, for example

xyz:= solve(...);

Then in the plots, do

plot3d(eval(x, xyz[]), ...);

and likewise for the y and z plots.

@FDS Regarding efficiency, the time on my computer to compute the minimizing parameter values for the 192 data points was 120 milliseconds.

@vv You changed the 3rd modulus from 23^3 to 23^2. Apparently, this doesn't change the final x and y.

@FDS Okay, but note that my technique reduces the error (specifically sqrt(SSE), the square root of the sum of the squared residuals) by a factor of 26 compared with the MathCAD values.

Edit: I just saw that you increased the data points to 192. I'll make the comparison again with the new data.

Edit 2: Using the new data, my reduction factor in sqrt(SSE) is 1.4. The parameter values that I got are Q__0 = 7018.5, Q__s = 2813.2, k__f = 2.0578 * 10^(-5). These are in the same ballpark as the MathCAD values.

@Joe Riel kernelopts(bytesused) tells you how much memory has been used over the entire session (i.e., since restart) including memory that has been used multiple times. So, it's a non-decreasing value, and it isn't very relevant for someone who's running out of memory. What's needed is How much memory is currently being used? That's what the 3rd column of kernelopts(memusage) tells you.

MmaTranslator:-Mma:-MemoryInUse() returns the sum of that 3rd column, although it does it with the incredibly inefficient coding style that's typical of that package, making 64 separate calls to kernelopts(memusage) where 1 would suffice.