@digerdiga I am wondering whether you are specifying it backwards.

Consider your shorter followup example. It doesn't make sense to collect wrt `x` and then expect the common `a` term to be factored out -- since the terms with powers of `x` will be handled separately. Instead, collect first wrt `a`.

g := a*x*(x+1);
                        g := a x (x + 1)

collect(g,[a,x])
                           / 2    \  
                           \x  + x/ a

As for your primary example, are you looking for one of the last two of these?

Download collect_nc.mw

@permanoon123 What do you want to export and to which Excel file, each time through the loop? Do you want it to append to the same Excel file? Please be clear.

@digerdiga I shall leave any clarifying comments on your Question.

What is the target expression, explicitly? It may be clear in your mind, but I have not yet seen it.

For example, when you write, "for the third term I would actually mean this" do you mean that is what you want, or what you don't want?

I have deleted my Answer, since it seems to me that the question is still not being explained properly, ie. with the goal explicitly or clearly described.

@nm Last year I reported that kind of problematic example with fractions and LaTeX export. (If I recall correctly, it was about the time that your issue with an extraneous factor of 1 in LaTeX output was reported.)

@macrobbair I find it very difficult to take seriously your issue when you keep failing to provide meaningful details.

I cannot make proper sense of this, the only snippet of detail that you've provided so far:
    `What is does is take the whole of the previous "Z=X+Y" and
  add it to the new A thus "A+Z=X+Y" instead of "A+Z"'

Why do you not try and isolate the problematic Matrix behavior, that reproduces the issue while not giving away precious details of your secret project work?

Perhaps you have set up some Matrices with a recursive definition.

But how can you reasonably expect us to suggest a concrere revision, when all you provide is a nebulous description? It it not reasonable.

@BarKop That option is spelled summarize.

You can also get programmatic access to additional details such as the "rsquared" statistic, etc, using the solutionmodule output.

Download svdfit_solmod.mw

@Joe Riel I thought that you were describing incorrect behavior, ie. a bug. The example that you've shown  in your last Comment contains correct output, unless I'm missing some point.

But the original behavior shown -- with the Typesetting stuff -- was clearly incorrect and illustrates a bug.

If the OP was trying to ask something about the output from statements within do-loops then it could have been stated more clearly (because it is not specific to rand, etc). In that case, sure, terminating the end do with a colon, or setting printlevel, etc, could be appropriate.

This is interesting, and will require a careful read. Thank you.

I have been reading posts over at the Wolfram Community site, for the past few weeks. In particular:
 - Robert Rimmer's articles, including here (updated here), and here (related to here).
 - Robert Nachbar's article here on epidemiological models.
 - Vitaliy Kaurov's compendium article here.

[edit] An interesting and more recent post (by the aforementioned Robert Rimmer) on a logistic growth model is here.

@Joe Riel Hi Joe, please could you be more specific about what's still added, and with examples (regressions, or not)? Thanks.

@Christopher2222 I don't understand what you mean, once again. Why do you post comments about issues without full accompanying code?!

The spline fit grows large for y values above the largest in xx. Extrapolation isn't a great idea.

restart;
yy:=[3,3,3,4,6,7,8,6,7,13,8,9,6,7,12,14,16,34,42,23,32,45]:
xx:=[seq(i, i = 1 .. nops(yy))]:
s:=CurveFitting:-Spline(xx, yy, v):
plots:-animate(plot3d,[[s, th, v], v=0..y, th=0..2*Pi,
                       coords=cylindrical, style=surface],
               y=0..25);

@Christopher2222 Without resorting to weird and arcane methods, then I'd expect it to compare well, yes.

What I showed computed on my machine about 13 times faster than rotate@SurfaceofRevolution (as Tom originally had it) and about 8 times faster if rotate were skipped (since that's just an orientation thing).

Do you need it to construct fast or play fast? (Explore vs `animate`, say).

I might mention that I used the very same (pretty straightforward) method for both your examples.

ps. plottools:-rotate can be expensive, in time and memory. Use orientation or viewpoint instead, if possible.

@Carl Love I was mistaken about a detail, yes, although the overall rationale is right. Thanks! It's not the float approximation to Pi per se that hobbles the expensive checking. Changing the coefficient of 2 ro 2.0 within the sqrt call inside P1 is adequate (and that's what was happening in Kitonum's suggestion to unapply the evalf'd expression to become Jhk).

For example (significantly faster, but not fastest),

P1:=(r,R)->(2/Pi)*(arccos(r/(2*R))-(r/(2*R))*sqrt(1-(r/(2.0*R))^2)):
J0:=(r,shk)-> BesselJ(0, 2*Pi*r*shk):
Jhk:=(s,shk,R)-> evalf((1/s)*Int(P1(r,R)*J0(r,shk)*sin(2*Pi*r*s), r=0..2*R)):

CodeTools:-Usage(plot(Jhk(s,2.14,38), s=0..5)):
memory used=441.40MiB, alloc change=139.01MiB, cpu time=4.58s, real time=4.47s, gc time=293.50ms

Also quicker is altering the upper end-point of the range of integration slightly, ie, r=0..(2-10^(-9))*R , with P1 left as is, even with no floats present and no evalf of the unapplied expression.

restart;
P1:=(r,R)->(2/Pi)*(arccos(r/(2*R))-(r/(2*R))*sqrt(1-(r/(2*R))^2)):
J0:=(r,shk)-> BesselJ(0, 2*Pi*r*shk):
Jhk:=(s,shk,R)-> ((1/s)*Int(P1(r,R)*J0(r,shk)*sin(2*Pi*r*s), r=0..(2-10^(-9))*R)):

CodeTools:-Usage(plot(Jhk(s,214/100,38), s=0..5));
memory used=447.00MiB, alloc change=133.01MiB, cpu time=4.62s, real time=4.50s, gc time=299.21ms

I am going to submit an SCR for a keyword option to disable expensive checking.

@rowlesmr The two main effects are:
1) It avoids calling J0 and P1 for each different numeric value of s generated by plot.
2) Since J0 and P1 are called before evalf, the symbolic Pi within the J0 call (withing the unapply call) becomes the float approximation 6.28... . And that has a beneficial effect on how evalf(Int(...)) "wastes" time poking about the integrands looking for discontinuties.

If you remove the evalf but keep that outer unapply then it can also take long.

Sorry that it's tricky to explain thoroughly. See my Answer for more technical comments.

@Christopher2222 Are you using 2D Input mode? Do you have the right-panel (aka context-panel) open, and if so does the problem recur if you keep it closed?