If you don't need them marked up especially as 2D Math input then you might just be able to use the alias command, or pdetools[declare].

Here are two posts that relate to 2D Math input forms: one, and two.

acer

It looks doubtful that an exact result is forthcoming. But (effectively) you can compute an arbitrary number digits of an approximate floating-point solution.

restart:

r:=arccosh(RootOf(8*_Z^7-65532*_Z^6+7108920*_Z^5-123513390*_Z^4
                  +697296600*_Z^3-1645944300*_Z^2+1702701000*_Z
                  -638512875, index = 2)^(1/2)):

evalf[20](r);

                           0.47649585654800266209

u:=diff(ln(cosh(t)),t$15):

evalf[100]( eval(u,t=r) ): # for better accuracy

evalf[10](%); # and displayed shorter

                                             7
                               9.858206439 10 

Optimization:-Maximize( u, t=0..50, method=branchandbound,
                        evaluationlimit=1000 );

               [                   7                         ]
               [9.85820643880540 10 , [t = 0.476495856343965]]

acer

Programming it in a loop or sequence might give a little relief.

restart:

for var in [x,y,z,p] do assume(var>=0); end do:

assume(w<0);

is( x+y+z+p >= 0 );

                              true

is( (x+y+z+p)*w <= 0 );

                              true

acer

eq:=A*x^beta=R-A*beta/(x^(1-beta)*(1-t));

                  beta             A beta       
               A x     = R - -------------------
                              (1 - beta)        
                             x           (1 - t)

map(z->1/((1-t)*z), R-eq);

                                        (1 - beta)
                        1              x          
              ---------------------- = -----------
                      /    beta    \     A beta   
              (1 - t) \-A x     + R/              

One minor variation on that is,

map( z->1/z, (R-eq)*(1-t) );

acer

You could hit it with the `expand` command instead.

inp := [1,2] + [3,4]*x;

                       [1, 2] + [3, 4] x

expand(inp);

                       [3 x + 1, 4 x + 2]

whattype(%);

                              list

That produced list, which seems to be what you wanted.

Is there a reason that you choose lists here, instead of (uppercase) Vectors?  I'm just curious. For Vectors, that arithmetic should carry through automatically.

acer

(I believe that most of Christopher2222's explanation, posted as Answer before mine, is incorrect.)

The Asker passed 'temp' with uneval-quotes to `unassign` (and that succeeded).

If there is no remaining reference to the memory allocated for the Matrix originally assigned to `temp` then it should be collectable. The act of trying to create another sufficiently large object should trigger a garbage-collection that recovers that memory, if in fact there is no outstanding references to it.

The %,%%, and %%% may still reference to the rtable, in his example, which would be adequate to prevent its collection. But even when those are cleared the collection is not triggered by either gc() call or fresh Matrix() call. I find this unexpected.

The following is with size 9400x9400 in the Maple 16 Classic GUI, but the same happens in 64bit Standard with size 25000x25000 on my machine. The problem appears to be pure kernel, not an interface thing. In the following session the large rtable is not collected during a garbage-collection (that is shown to have counted), but there appears to be no outstanding reference to the rtable object. So the attempt to create a new large rtable ought to trigger collection of the previous unreferenced one.

The smaller sized example for Classic (because it's a 32bit kernel) worked in Maple 15, and his larger example worked in 64bit Maple 15 (5GB Matrix) provided that %,%%, and %%% were cleared.

Here it is failing on the second Matrix call, after gc occurs, in Maple 16's Classic.

restart:kernelopts(gctimes), kernelopts(gcbytesreturned),
> kernelopts(gcbytesavail), kernelopts(bytesalloc);

                          1, 0, 884, 4194304

> temp:=Matrix(9400):
> kernelopts(gctimes), kernelopts(gcbytesreturned),
> kernelopts(gcbytesavail), kernelopts(bytesalloc);

                        2, 0, 884, 1417957376

> unassign('temp'); a:='a': b:='b': c:='c':
> %, %%, %%%;

                               c, b, a

> temp;

                                 temp

> kernelopts(gctimes), kernelopts(gcbytesreturned),
> kernelopts(gcbytesavail), kernelopts(bytesalloc);

                        2, 0, 884, 1417957376

> gc();
> kernelopts(gctimes), kernelopts(gcbytesreturned),
> kernelopts(gcbytesavail), kernelopts(bytesalloc);

                        3, 0, 884, 1417957376

> temp:=Matrix(9400):
Error, (in Matrix) Maple was unable to allocate enough memory to complete this computation.  Please see ?alloc 

> anames();

           unassign, interface, Matrix, debugger/no_output

> anames('active');

                                Digits

> anames('environment'); # none of these should refer to the original rtable

  Testzero, UseHardwareFloats, Rounding, %, _ans, %%%, Digits,

        index/newtable, mod, %%, Order, printlevel, Normalizer,

        NumericEventHandlers

Here is is succeeding on the second Matrix call in 64bit Maple 15's Standard GUI. (It's a 5GB rtable, and my machine has only 6GB, and Windows 7 and other stuff running, so it swapped for a while in the OS. But it worked.)

restart:
kernelopts(gctimes), kernelopts(gcbytesreturned),
kernelopts(gcbytesavail), kernelopts(bytesalloc);
                      1, 23576, 0, 1572576
temp:=Matrix(25000):
kernelopts(gctimes), kernelopts(gcbytesreturned),
kernelopts(gcbytesavail), kernelopts(bytesalloc);
                  2, 18992, 516208, 5001577968
unassign('temp'); a:='a': b:='b': c:='c':
%, %%, %%%;
                            c, b, a
temp;
                              temp
kernelopts(gctimes), kernelopts(gcbytesreturned),
kernelopts(gcbytesavail), kernelopts(bytesalloc);
                  2, 18992, 516208, 5001577968
gc();
kernelopts(gctimes), kernelopts(gcbytesreturned),
kernelopts(gcbytesavail), kernelopts(bytesalloc);
             3, 5000000448, 5000510384, 5001577968
temp:=Matrix(25000):
anames();
           debugger/no_output, Matrix, unassign, temp
anames('active');
                              temp
anames('environment'); # none of these should refer to the original rtable
 Testzero, UseHardwareFloats, Rounding, %, _ans, %%%, Digits, 

   index/newtable, `mod`, %%, Order, printlevel, Normalizer, 

   NumericEventHandlers

So it looks to me like a (corner case?) bug in the new memory management of Maple 16.

acer

This is just an idea of something you could try: using the older Classic with the new kernel.

I tried it with 11.02 and 15.01, but you might try 13.01 and 16.01. It'd be interesting to hear if it gained you anything concrete.

The reason this kind of thing has even a hope of working is that 1) Classic doesn't change much, 2) the interfaces communicate with the kernel over sockets and aren't actually linked against their dynamic libraries, and 3) the interface and kernel pass information in so-called .m (dotm) format which also changes rarely. To illustrate point 2), cwmaple.exe is linked to mclient.dll but not to maple.dll.

This kind of unofficial kludging is why the 32bit Classic can mostly be made to use the 64bit kernel of the same release.

But now I tried it by using the Maple 11.02 Classic GUI with the (32bit) Maple 15.01 kernel. I did this in the most simple-minded way. I suppose that I could have reinstalled a duplication of my full Maple 15.01. But instead I just copied the whole M15 folder and gave it a new name like Maple11plus15. I left my original M15 installation alone, of course. Then I copied the cwmaple.exe and the mclient.dll from the "Maple 11/bin.win" folder into the "Maple11plus15/bin.win" folder.

Unlike some earlier melds of 32bit & 64bit, I didn't copy over any other binaries (eg. plotXYZ.dll). And I figure it complains about the .ini file because I just copied the whole folder rather than reinstalled a duplicate from scratch.

I have no idea how stable this thing is. It'd be very interesting if your M13 Classic worked at all reliably with a more recent Maple release such as M15 or M16.

Help from the top menubar doesn't work, but the programmatic help() command brings up the standalone M15 Java Help system.

Here's a screenshot.

Follow these instructions and use the resulting system entirely at your own risk.

acer

Try,

[op(indets(mat,name))];

and if you have Pi, gamma, etc,

[op(indets(mat,name) minus {constants})];

acer

Did you forget a multiplication sign between (1-t) and the other terms?

...or, if in 2D Math input mode, a space between the (1-t) and other terms in order to denote multiplication implicitly?

With pairs of round bracketed terms side-by-side as in (y/A))(1-t) it gets parsed as function application y(1-t)/A(1-t) which contains unevaluated function calls to y and A with argument 1-t.

acer

It's possible that the integral isn't being computed accurately enough for fsolve (which is basing its own accuracy demand on the value of Digits). I'm not yet sure whether that's the issue. But this seems to work,

restart:
F := Int(sqrt((2.138+0.3e-2*exp((4.2^2-z^2)/d^2))^2-2.141^2), z=0 .. 4.2) = .5:
f:=unapply((lhs-rhs)(F),d):

#plot(f,2.0..6.0);

RootFinding:-NextZero(f,2.0);

                          3.957142935

acer

The proc T does not know the beta that you passed to g. Perhaps you meant to pass beta as a thrid argument to T.

Also, you may have intended the first conditional (the `and) to be different (missing a minus sign?).

Lastly, you might want to reduce the accuracy for the numerical integration, so that it succeeds across more values. You may have to play with that a bit...

restart;

Delta := proc(beta) options operator, arrow; sqrt(1-1/beta^2) end proc;

T := proc(`ε`, Z, beta) options operator, arrow;
 piecewise(`&epsilon;` < Delta(beta) and -Delta(beta) < `&epsilon;`,
 2*Delta(beta)^2/(`&epsilon;`^2+(Delta(beta)^2-`&epsilon;`^2)*(2*Z^2+1)^2),
 `&epsilon;` < -Delta(beta) or Delta(beta) < `&epsilon;`,
 2*abs(`&epsilon;`)/(abs(`&epsilon;`)+sqrt(`&epsilon;`^2-Delta(beta)^2)*(2*Z^2+1)))
end proc;

g := proc(V, Z, beta) options operator, arrow;
 1/(Int(T(`&epsilon;`, Z, beta)*beta*exp(beta*(`&epsilon;`-e*V))/
(exp(beta*(`&epsilon;`-e*V))+1)^2, `&epsilon;` = -infinity .. infinity,
 ':-epsilon'=1e-4, method = _NCrule)) end proc;

e := 1;

plot('g'(V, .1, 10), V = -4 .. 4);

acer

The attached worksheet tries a couple of methods to control output display size, but are not about PDF export per se.

scaleout1.mw

acer

You can use the Statistics:-Moment command.

You could do this starting with a random variable produced wih the RandomVariable command. But you mentioned getting there from the pdf, so let's start with that:

restart:
with(Statistics):

assume(sigma::real):
pdf:=(1/2)*2^(1/2)*exp(-(1/2)*(t-a)^2/sigma^4)/(Pi^(1/2)*sigma^2):

X:=Distribution(PDF=unapply( pdf, t )):

Moment(X,5);
                 5       3      4             8
                a  + 10 a  sigma  + 15 a sigma 

restart:
with(Statistics):

pdf:=(1/2)*2^(1/2)*exp(-(1/2)*(t-a)^2/sigma^4)/(Pi^(1/2)*sigma^2):

X:=Distribution(PDF=unapply( pdf, t )):

Moment(X,5):
simplify(%)  assuming sigma::real;

                 / 4       2      4           8\
               a \a  + 10 a  sigma  + 15 sigma /

acer

rtable(1..4,1..5,random(0..1),subtype=Array,datatype=float[8]);

                            [0.  0.  0.  0.  0.]
                            [                  ]
                            [1.  1.  1.  1.  0.]
                            [                  ]
                            [0.  1.  0.  0.  0.]
                            [                  ]
                            [1.  1.  0.  1.  1.]

rtable(1..4,1..5,random(0..1),subtype=Array,datatype=integer[1]);

                               [0  0  0  0  1]
                               [             ]
                               [0  0  0  1  0]
                               [             ]
                               [1  0  1  0  1]
                               [             ]
                               [0  1  1  0  1]

The integer[1] datatype will use the smallest amount of memory to store your huge Array.

If your huge Array is still too big to fit into memory then you could consider rewriting your program so that it only needed a chunk of it at any one time. In recent Maple versions the Statistics:-Sample command accepts an optional argument which is an rtable to be re-ued and re-populated with data. In this way you can use a great many input values while only ever needing to store a smaller amount of input values at any given time (keeping total allocation lower). Eg,

restart:
with(Statistics):

m:=Vector[row](1..6,datatype=float[8]):  # the re-usable container

X:=RandomVariable(EmpiricalDistribution([0,1])):

for i from 1 to 3 do
  # first, re-populate rtable `m`
  Sample(X,m);
  # now `m` is ready to re-use, and has fresh values
  print(m);
end do:
                          [1., 1., 0., 1., 1., 0.]
                          [0., 1., 1., 1., 0., 1.]
                          [1., 0., 1., 0., 0., 1.]

acer

Q: "Does it really means that there are 32950 digits between the two parts of the expression?"
A: Yes.

You can get the number of digits in a various ways. For positive integer `x` you could try length(x) or something like  ceil(log[10](x*1.0)) but you should probably test those first smaller values.

If you really want to print out all the digits then you could lineprint them (without special 2D Math output typesetting) using the `lprint` command, or if you feel brave you could try and bump up the Standard GUI's term elision threshold. But be warned that both of those (lprint, less so) can drive the Standard GUI into a nearly inoperable state. You should be able to change the term elision threshold using either the main menubar's Tools>Options (and choosing the "Precision" tab in the pop-up window) or the `interface` command.

Another possibility, for printing out a posint with bery many digits, might be to use the `writeto` command to remporarily redirect output to a plainttext file.

acer