@C_R Yes, another purely text-based approach would be to simply append using printf.

(ie. without using "\n" in the format string.)

for i from 1 to 10 do
  Threads:-Sleep(0.75);
  printf("  %a",i);
end do:

Another very simple approach is to call DocumentTools:-Tabulate inside the loop. That just overwrites the embedded assembly (for that Execution Group or Document Block). It also allows for some look&feel options, as well as handling of a mixed/combined text, typeset math, and plots. I think this is easier than writing all this Post's DocumentTools code -- especially if it's a one-off.

with(DocumentTools):
for i from 1 to 10 do
  Threads:-Sleep(0.75);
  Tabulate([sprintf("done %a of %a",i,10)],
           exterior=none);
end do:

There are also a couple of other "progress bar" approaches in the stock Example worksheet page,
   Programmatic Content Generation

In 2016 I wrote some code for a Slider approach, in a Mapleprimes response here. (That could also be saved to a Library archive for convenient future re-use...)

Now, a comment: it might be useful to some people if the running progress indicator were visible in some separate "console" window, so that one could pan around a large document while still having the running indicator present. I suspect that I could force it into the GUI's right-panel (used these days for context-menus and PlotBuilder), but I don't have time for it.

Your code makes the assignment,

   tolerance := 1e-6

What effect do you hope that might have on the ensuing computations?

Are you trying to increase/force the working precision at which the floating-point evaluation (following a substitution) will be done? Or are you trying to do something else with `tolerance`, and, if so, what?

It's difficult to correct your code if you do not explain in detail what it's supposed to accomplish.

Please add your close followup queries on this here, instead of spawning a wholly separate Question thread for this problem.

@delvin Your equations contain the following, as a function call of sinp ,

sinp(-2*cosh(d)*sinh(d)
     *((a[1]+b[1])*cosh(d)^2+(-a[1]+b[1])*cosh(xi[n])^2-b[1])
     /(cosh(d)^4-cosh(xi[n])^4-cosh(d)^2+cosh(xi[n])^2))

How can that make sense here, as a function call of an unassigned name? How could you possibly expect to be able to solve for variables like a[1],b[1] as they appear within a call to an unknown function?

The same kind of thing happens with cosp.

Did you intend something else, rather than function calls?

Perhaps you intended multiplication by sinp, and forgot a multiplication symbol after the name -- instead of applying that name to arguments?

What are sinp and cosp supposed to mean in your code?

@Carlos36r A very easy way, IMO, is to suppress all usual output from the loop by terminating it in a full colon, and then using the print command to forcibly show what parts you want.

For example,

restart;

for x in [0,1,2] do                           
    if is(x in RealRange(Open(0),infinity)) then                                                 
        print(yes);
    else
        print(no);    
    end if;
end do:

            no
            yes
            yes

I think that gives you nice, legible code which can be easily augmented with additional computations added throughout it.

I also think that a solution for this that has to get finicky with printlevel has already gone astray. A sign that it's suboptimal is that if you want to add/remove additional do-loop/if-then layers then such code for more involved examples might need extra editing in several places.

@tomleslie I'm not disagreeing with this Answer; using the stopperror command (from the debugger suite) like that is a perfectly decent suggestion here. (I vote up.)

But I will mention that the line of code on which the recursive assignment occurs might not always be the line of code that ought to be fixed.

In Tom's simple example it is clear that the problem lies all within a single line of code. But in a complicated program the line that does the assignment might be correct, with the coding mistake lying elsewhere. For example, it's not inherently wrong to have a pair of separate statements like, say,
   temp := sin(y);
and another, later statement,
   y := G(temp);
if earlier in the code y is assigned some value (a numeric value might be typical, etc). And that earlier code could be complicated, doing such earlier initialization according to a process or under a complicated decision tree. It's quite possible that a subtle mistake in that process could leave a logical hole -- a situation in which y is accidentally not initialized, with the recursive assignment error ensuing.

It's not always possible for a code analyzer to locate a specific line at which a recursive assignment might occur. And the line at which the recursive assignment occurs during execution is not necessarily the line of code which ought to be fixed.

Sorry if that seems at all obvious. I'm trying to clarify the OP's query, "Presumably there is an error in the Maple syntax that prevents execution... Why can't Maple 2023 tell me what line the error is on?".

@MaPal93 What is the end-goal to solving these systems symbolically? Is it something explained in one of your earlier, related Question threads?

ps. I don't see an explanation of "optimal", as I asked above.

@MaPal93 What do you mean by optimal when you write of the optimal 3-equations sub-system?

Going back a bit, there are sometimes alternate techniques which can more easily eastablish an absence of solutions, as opposed to requesting an attempt that would produce any/all such in full. That may be leverage to you.

In a somewhat related way, I don't know how useful some potentially enormous exact symbolic subsystem might actually be.

@MaPal93 There appear to be no solutions to your system EqN with all of lambda__1, lambda__2, & lambda__3 being real and positive.

Does this not mean something relevant to your attempt to solve the 3x3 EqN system?

newEqN:=eval(EqN,[lambda__1=v1,lambda__2=v2,lambda__3=v3]):

andmap(coulditbe,newEqN=~0) assuming v1>0,v2>0,v3>0;

             false

@MaPal93 There is also a Veil command in the LargeExpressions package.

That, along with `freeze`, can sometimes be useful. (But hiding dependencies upon variables might matter.)

@MaPal93 To me a tricky part of your Question is the bit about your wanting to find the optimal formulation (of some of t__1,t__2,t__3 in terms of some others, with other mixed terms).

I don't think that the temporary variables I showed is going to provide an avenue for that. At least, I don't see how it'd be any better than manipulations done using the tools algsubs, eliminate, simplify(...,{..}) aka "simplify-with-subrelations", or some basis generator.

But since you asked how it (ie. what I showed above) could be programmed, here is some fun. Some of the following is done a bit crudely. And there are more finesses possible.

Download rearrangingterms_q3a.mw

@Carl Love The type checks you've used,  suffixed(x) and suffixed(x, nonnegint) , could fail if the name x itself were assigned. Now that I come to think of it, I suppose that the name suffixed is (alas) not protected.

So those type specs could all get wrapped in uneval-quotes, to guard against those cases.

@sursumCorda I thought that my wording -- and what I computed, and how -- made it quite clear and obvious that it provided no guarantee that there were no other solutions. I did allude to the larger problem as being fundamentally different.

I showed it primarily because nobody (including you) had yet showed any way to programmatically generate the as-yet known five exact solutions.