@dharr Using null indices also works for copying:

prev[]:= curr[];

This works for any rtables, regardless of the number of dimensions (as long as it's the same on both sides) and regardless of the starting indices.

@SitecoreQedge This AI-generated Answer is much too superficial (although mostly correct), but it does have an outright error towards the end.

@Traruh Synred For me to do anything to help you with this, you need to post a complete and executed worksheet showing the occurrence of the error, and containing all the code needed to execute the worksheet.

Was it truly your goal to combine your original three 3-vectors into a single 9-vector, as shown? Or did you intend to combine them into a 3x3 matrix? Although there's nothing incorrect about the single-vector goal, the matrix goal seems a more-normal option, and it would also simplify the syntax needed to retrieve the original vectors.

@KIRAN SAJJAN 

The appliable module (essentially the same thing as a procedure) Solve is the heart of the code that you're using---the thing that accomplishes my titular goal of "Numerically solving BVPs with many parameters", with an ease-of-use similar to dsolve's parameters option for IVPs, albeit not with the same efficiency. Also, Solve passively accumulates a table matching the numeric values of the input parameters with the numeric values of the user's desired output parameters. Output parameters could be anything computed using values from the solution curves, such as the Nusselt number or the skin-friction coefficient.

There is a small "compile-time" syntax error in the version of Solve that you have, which means that Solve isn't being used at all! I don't know when it became an error. In Solve, look for the line
    ModuleLoad:= eval(Init)
and change it to
    ModuleLoad:= ()-> Init()

Now, start with smaller goals: Try to make some plots of solution curves for specific parameter values rather than full-blown parameter vs. parameter plots. These problems are extremely complicated from the perspective of numeric computation, and there are almost always parameter combinations that have convergence problems. Sometimes those convergence problems are relatively easy to fix, and sometimes not.

@vv I vote up.

Would you please explain some of the theory behind your algorithm? In particular, I note that using your default R = 1000, there are about 4 million loop iterations (a reasonably small number), but it seems to reach the correct minimum even when the search space is far larger than 4 million.

I don't need elaborate details about LLL, just why it works well in this case.

Would it be possible to heuristically automatically adjust R within your algorithm based on the magnitude of LCM(m)?

@Traruh Synred There's still no attached file for this Question.

I'm even more interested (and likely more able to contribute) to your memory leaking problem, but there's also no code or attached file there either, despite my requesting it a few times. You've posted a lot of output there, but it's not very meaningful without seeing the code.

@sursumCorda That's an interesting timing comparison that you've made between Python and Maple, each making essentially the same calls to SMTLIB. Please post plaintext of your code so that I don't need to retype it.

*** Pure speculation below. Definitely needs to be verified! Future readers: Don't believe or repeat the next paragraph unless it has been verified!  ***

My first guess as to the slowness of your Maple version is that it's essentially reparsing\recompiling a string version of the problem on each loop iteration. One would hope that one purpose of the object returned by Session would be to avoid such reparsing. Indeed, reading the code showstat(SMTLIB:-Session), I see reentrant mentioned several times, which suggests to me that some sort of "hot active link" to the external code is being maintained. On the other hand, the help page ?SMTLIB,Session says that it's "for working interactively with an SMT solver", which suggests to me that every in-loop call to object methods Assert and/or Satisfiable does some reparsing.

*** End of pure speculation ***

I'm curious about the timing if you use Maple's built-in Python interpreter. See ?Python. 

There is no file attached to your Question.

@zenterix You wrote:

•  I noticed that if we try to solve for R instead of T, ie solve(expr, R), we get no result.

You can't solve for R directly, but you can solve for %log[10](R):

solve(expr, %log[10](R))

Please give an actual example of two space curves for which you would like this done, using the form

[x(t), y(t), z(t)], t= a..b

For example, an upper semi-circle lying in the xy-plane would be

[cos(t), sin(t), 0], t= 0..Pi

Your 2nd example, 2 + x^2*y, is meaningless to me as a space curve. 

@vv Thank you for testing my procedure.

In all cases, my procedure's time is O(y), where y is the y-value of the final output. In the cases that the OP has presented so far, y < < LCM(m). (In other words, the minimal y has been quite surprisingly smaIl in the OP's cases that we've seen here.) I don't know whether this is coincidence or whether it has to do with details of the OP's overall problem that we haven't seen yet.

My procedure does not automatically reduce the moduli when it's possible to do so. It could easily do that; I simply didn't implement it. In the cases presented so far, the 3rd and 4th moduli can be reduced to 23^2 and 17^2 (as you noticed in your first Answer). Using these reduced moduli, I get the result for your 6-equation example in about 2 minutes, [X = 5220211473, Y = 10734787609]. I am considering some ways to reduce that time.

@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 y solving the equations alone (i.e., irrespective of the inequalities) 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.