Procedures are of type last_name_eval. (Visit that link and see near the end for a tip on returning a procedure as the result from another procedure.)

> Phi := unapply(A1[1], x1, x2);

                           Phi := (x1, x2) -> A1[1]

> Phi;

                                      Phi

> eval(Phi,1);

                               (x1, x2) -> A1[1]

> type(Phi,last_name_eval);

                                     true

acer

Try it with the exponent ``(1/2) instead of 0.5 where `` is two single left-quotes (name-quotes).

If it gets the behaviour you are after, then try applying the expand command to the entire expression and see if that gets you back to normal. (If it works then the sqrt(2) should pop out from the rest.)

acer

If your real, floating-point data is symmetric then try,

B := Matrix(..., shape=symmetric);

Eigenvalues(B);

so as to get an appropriate solver which returns a real result. The argument to `Matrix` above (where I had ... ellipsis) could be an Array, or listlist, or another Matrix the previous version of B, etc.

It's difficult to answer about that error message (indicating a missing argument) without seeing your code. Could you upload a self-contained worksheet that demonstated the problem?

acer

There certainly would be good uses for an "Interpolate" command which, given data, could return an interpolating procedure. Such a returned interpolating procedure might even be made clever in that it could know how to apply the integrated version of its own simple interpolatory formulae (splines, say). But such a thing does not yet exist, as described.

As you say, one need is for very low overhead in on-the-fly interpolation at a given (single) point, which might be done repeatedly but cannot all be done in bulk at once.

Having said that, it might still be possible to speed up your application a bit. If you don't have a great deal of data points then you might be able to use BSplineCurve and instead get an interpolating piecewise polynomial (which could be integrated, once). Or, if sticking with ArrayInterpolation then a little relief might be had with reusable 1-element float[8] Arrays for input/output. Or, possibly, for a fixed degree spline use in ArrayInterpolation then a particular differencing scheme might be able to quickly integrate "exactly".

Any chance you could upload a self-contained worksheet that implemented your current methodology?

acer

I think that your second example is misprogrammed. Since `result` is a table the procedure `make` should return `eval(result,1)` or `eval(result)`.

[edited] A Maple table has type `last_name_eval`. See the help-page last_name_eval which states, "A procedure that returns a table, module, or another procedure normally requires an evaluation at the return site, using the two-argument form of eval in which the second argument is 1."

acer

ee := cos(x^2+x)-sin(x+1/6*Pi)-cos(x+1/3*Pi);

                          2                 Pi              Pi
               ee := cos(x  + x) - sin(x + ----) - cos(x + ----)
                                            6               3

> ff : combine(expand(ee));                    

                                  2
                             cos(x  + x) - cos(x)

I'm not sure that we really need to rely on Maple to get from there to,

            x^2 + x = x + (2*n)*Pi

where n is any integer. Anyway, we can get some solutions, x = +-sqrt(2*n*Pi) for n=0,1,2...And there are other solutions which may be found numerically. There's no reason to stop this search at 2*Pi, as below. Note this this also produces the solutions described exactly above.

ee := cos(x^2+x)-sin(x+1/6*Pi)-cos(x+1/3*Pi);

Digits:=20: # your choice
FF:=unapply(combine(expand(ee)),x):
NZ:=RootFinding:-NextZero:         
S:={0.0}: last:=0.0:               
while is( last < 2*Pi ) do         
  last := NZ(FF,last);
  S := S union {NZ(FF,last)};
end do:
S;

  {0., 2.5066282746310005024, 2.6832554370229568635, 3.4552840449895851091,

    3.5449077018110320546, 4.1120192907224387652, 4.3416075273496059562,

    4.6934986199961384012, 5.0132565492620010048, 5.2208610210386085156,

    5.6049912163979286993, 5.7068843101888305450, 6.1399602476789309309,

    6.1599917917157343495, 6.5860838226726890216, 6.6319150439565422209}

So, is there are nice way to represent these,

evalf[10](S) minus evalf[10]({seq(evalf[20](sqrt(2*n*Pi)), n=0..7)});

   {2.683255437, 3.455284045, 4.112019291, 4.693498620, 5.220861021, 5.706884310,
    6.159991792, 6.586083823}

acer

All:=map(`*`,combinat[partition](15,5),10):

F:=(n::posint)->select(u->nops(u)=n,All):

F(3);

                         [[50, 50, 50]]

F(4);

    [[30, 40, 40, 40], [30, 30, 40, 50], [20, 40, 40, 50], 

      [20, 30, 50, 50], [10, 40, 50, 50]]

F(5);

         [[30, 30, 30, 30, 30], [20, 30, 30, 30, 40], 

           [20, 20, 30, 40, 40], [10, 30, 30, 40, 40], 

           [10, 20, 40, 40, 40], [20, 20, 30, 30, 50], 

           [10, 30, 30, 30, 50], [20, 20, 20, 40, 50], 

           [10, 20, 30, 40, 50], [10, 10, 40, 40, 50], 

           [10, 20, 20, 50, 50], [10, 10, 30, 50, 50]]

and so on up to F(15).

acer

I don't understand why the maplenet server used by Mapleprimes is causing the gridlines to show up below. The gridlines don't appear when run in 64bit Maple 16.01 on Windows 7.

Download uniform.mw

acer

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