One thing to consider is that the terms in a sum (SUM dag) are stored in a particular order, at uniquification (aka simplification) time. Maple stores just one instance of such expressions, which may get pointed at by other more complicated expressions, for efficiency. Once -x+1 gets stored with its terms in that particular order then you have to work hard to get it changed to the order that would instead print as 1-x, in the same session.

One way around this is to force the uniquification of the expression stored as 1-x to begin with, before the form -x+1 is introduced.

Look here, how the form which is first introduced is the one that Maple insists upon.

restart:

1-x;

                             1 - x

-x+1;

                             1 - x

restart:

-x+1;
 
                            -x + 1

1-x;

                             -x + 1

But there is another way to change the form in the session's internally stored uniquification/simplification tables, by using the `sort` command. This can change the form that Maple insists upon, for that session, even if it is not the form that was first introduced. For example,

restart:
-x+1;

                             -x + 1

Q:=1-x:
Q;

                             -x + 1

sort(1-x,[x],ascending):

Q;

                             1 - x

restart:
1-x;

                             1 - x

Q:=-x+1:
Q;

                             1 - x

sort(1-x,[x],descending):

Q;

                             -x + 1

Ok, hopefully that subtlety is out of the way, for now. Now on to the Asker's example. We see the form that is requested. But the kind of transformation that is being asked, to get there from the problematic form (being complained about) is not unique. Does he want just a way to negate both numerators and denominator? Does he want a way to divide both numerators and denominator by the numerator? Does he want the `sign` of the numerator to become 1? For the given example all of these transformations can result in the same (stated as desired) result.

restart:
Q:=sum(x^k,k=0..infinity):

res1:=normal(sign(numer(Q))*numer(Q))/normal(sign(numer(Q))*denom(Q));


                               1   
                             ------
                             -x + 1

res2:=subs(a=1, normal(subs(x=x/a,Q))); # as per Joe

                               1   
                             ------
                             -x + 1

res3:=1/expand(denom(Q)/numer(Q));


                               1   
                             ------
                             -x + 1

sort(1-x,[x],ascending):

res1;

                               1  
                             -----
                             1 - x

res2;

                               1  
                             -----
                             1 - x

res3;

                               1  
                             -----
                             1 - x

acer

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