If all you want are results of numeric double-integration then you may not have to wait for a preliminary, partial and time-consuming symbolic integration.

Check that I re-entered the expressions correctly.

Note that I used inert Int instead of active int. You can tell because the integral symbol is gray not black, on the 2D Input. I entered it using command-completion, not the palettes. (I type Int and then the Escape key to get the template popup.)

It computed very quickly.

Download integral_doubt_ac.mw

Here is some experiment on the smaller 12x12 system, with some simplification.

It might give you some ideas.

Problem_2_ac.mw

An important matter is what you intend on doing with the results. It's not clear why you need the large symbolic answers.

When working with such large expressions it's often a good idea to suppress ouput by terminating commands with a full colon. Checking expressions for a moderate size before displaying in the GUI is often a good idea in such situations.

There are other ways.

ps. What might help, if you have other such expressions or sums or products of such and you want a systematic and programmatic approach, is to provide more complicated examples.

Download manip3.mw

I don't think that you've made it clear how you want to characterize your rearrangement of the expression, which makes it tricky to supply an operation that will work for other (as yet unstated) examples.

Download manipulation.mw

You also need the option,

   adaptive =false

There are several other ways to get the same effect -- using Vectors of the desired length and plotting the data, etc. But you specifically asked about what you needed with the numpoints option for the plot command.

Download LPSolve_ex.mw

OpProp is a procedure. Procedures have last-name-eval, so when you invoke just,
   lastexception;
you just get the expression sequence containing the literal name OrProp. But when you do
   print(lastexception);
you are requesting more (depending on the value of interface(verboseproc) at the time).

You could also compare the behaviour for,
   lastexception[1];
versus,
   eval(lastexception[1]);
and,
   print(OrProp);
It is unusual, that the last example immediately above also shows the issue.

In the CommandLine interface your code results in the body of OrProp being printed to the terminal. It's not that long.

I don't know yet why the Java GUI thinks that it has to elide altogether the printing of OrProp as a procedure. But I notice a discrepency between the results from,
   printf("%P",eval(OrProp));
and that of,
   showstat(OrProp);
around the code line numbers 52 and 53. It might be related.

But it's stranger because the behavior you've mentioned doesn't seem to depend on the setting of interface(verboseproc) .

I know that you are interested in using timelimit. You could try something like this, instead,

   print(sprintf("%a",lastexception[1]),
            StringTools:-FormatMessage(lastexception[2..-1]));

I mentioned that last bit as I suspect you might not be fully satisfied with the results from your suggestion,
   StringTools:-FormatMessage(lastexception)

Other useful tools include stopat, trace, and showstat.

For example, using trace (after using stopat and showstat to discover the computation path),

Download dsolve_traced.mw

I suspect that it happens because of the following.

restart;

trace(`simpl/simpl/Re/is`):
#stopat(`simpl/simpl/Re/is`):

Re(x) assuming {};

{--> enter \`simpl/simpl/Re/is\`, args = \`x~\`
                x2 := x

<-- exit \`simpl/simpl/Re/is\` (now in \`simpl/simpl/Re\`) = 0}
                   0

Note that when you enter
    ... assuming {}
the assuming facility temporarily places that property on dependent names. So your call amounts to supplying the property x::{} . So the result is the same as this,

Re(x) assuming x::{};
{--> enter \`simpl/simpl/Re/is\`, args = \`x~\`
                x2 := x

<-- exit \`simpl/simpl/Re/is\` (now in \`simpl/simpl/Re\`) = 0}
                   0

If you follow that procedure in the debugger you can see these checks (which I compare against the case of the unassumed name):

restart;
is(x2,'real');
                 false

restart;
is(x2,'real') assuming x2::{};
                  true

# the previous true induces this test
(not type(x2,'complexcons')
     or `property/ProbablyNonZero`(x2) <> true)
and traperror(is(x2,0)) assuming x2::{};
                  true

# perhaps of particular interest
is(x2,0) assuming x2::{};
                  true

is(x2,0);
                false

You can run it through and see what happens (ie. at lines 4 and 5, say),

showstat(`simpl/simpl/Re/is`);

`simpl/simpl/Re/is` := proc(x)
local x2;
   1   if hastype(x,'float') and not type(x,'complex(numeric)') and type(
         x,'complexcons') then
   2       x2 := `simpl/simpl/ReIm/is/float`(x)
       else
   3       x2 := x
       end if;
   4   if (not type(x2,'complexcons') or has(x2,'RootOf') or 
         `property/ProbablyNonZero`(('Im')(x2)) <> true) and traperror
         (is(x2,'real')) then
   5       if (not type(x2,'complexcons') or has(x2,'RootOf') or 
             `property/ProbablyNonZero`(x2) <> true) and traperror(is(
             x2,0)) then
   6           return 0
           else
   7           return x
           end if
       elif (not type(x2,'complexcons') or has(x2,'RootOf') or 
         `property/ProbablyNonZero`(('Re')(x2)) <> true) and 
         traperror(is(-I*x2,'real')) then
   8       return 0
       end if;
   9   return ('Re')(x)
end proc

Invoking your procedure with the command   wrong();   will only display the one plot that happens to be the return value, since the returned value will be displayed as output.

You could also do this,
   proc() print(plot(x)); printf("z"); print(plot(x)); end proc;
which displays both plots.  (It also returns NULL, since that is the result of the last statement which is a print statement.)

And you can vary it. You could have it forcibly print the first plot and return (and thus incidentally display) the second plot.

Here are some comments, and ways. (I'm sure there are others... possibly simpler).

I chose to use a Vector rather than a vector, and to map the `?[]` indexing command.

vector_of_lists_example_ac.mw

Enter a period (lower dot) for Matrix-Vector and Matrix-Matrix multplication, not a star (which displays as a center-dot in 2D Input).

Download trc_ac.mw

I found that using solve might depend on whether the changed equation was expanded, and upon the working precision (Digits).

You can also adjust Digits to see effect on residual (forward) error.

There are other ways to compute this (eg. using procedures which each raise working precision ie. Digits locally while keep fsolve's notion of accuracy (dependent on inbound Digits) coarser. I haven't done that. Similar effects can be had by treating it as an optimization problem (eg. by using DirectSearch, or setting it up that way).

Download no_conjugate_ac.mw

You can also use the command-completion facility, or the palettes, or the Ctl-Shift-G keyboard shortcut to easily construct compound names in 2D Input mode.

This also allows the names to appear in their nice typeset form as 2D Input, and not just as 2D Output.

See Help pages for command-completion and the entry palettes.

Download cmd_completion.mw

As Carl mentioned, you can also enter the compound names using its 1D equivalent notation (which -- as you can see above -- involves a name containing HTML-style entity, here). But for some kinds of typeset name you may not find that easy to guess, eg. names with a caret over them, etc.

In 2D Input mode, you can also use the keyboard acceleration Ctl-Shift-G to temporarily place the GUI into Greek-entry-mode. For your example, the same result for typeset 2D Input can also be had using the keystrokes,
   Ctl-Shift-G D x
There, the "D" makes it enter a Greek uppercase Delta. See the Help page.

In a previous Question you were shown in an Answer that the simplify command accepts the assume=[...] option.

That does not mean that option assume=[...] works for all commands. It does not.

The odetest command does not throw an error if you pass it some extra arguments.

If you want to construct your call (to utilize the assuming facility) from a precomputed list or collection of inputs then you can call using its prefix form:

sol:=y(x)^(1/2)=-1+2*exp(x):
ode:=diff(y(x),x)-2*y(x)=2*y(x)^(1/2):
`assuming`([odetest(sol,ode)], [x::real, x>0]);
                     0