Unprotecting system names is very rarely a sound approach. If one is not crystal clear about how to do it, what it entails, or what the consequences might be, then it's often a bad idea.

In Maple 17 one can declare a local version of a name... at the top level! Ie, outside of any procedure. This allows a name such as gamma to be used in a variety of common and useful ways (eg. assigned to) without the need to unprotect and overwrite the global of the same name.

In the following code the global name `:-gamma` retains its original meaning, which can be very important. eg. in cases where the special meaning is intended when it occurs in the return value of some computation by the system.

restart:

local gamma;

gamma := 4;

                                 gamma := 4

evalf(gamma);

                                     4.

evalf(:-gamma);

                                0.5772156649

kernelopts(version);

          Maple 17.01, X86 64 WINDOWS, Jun 25 2013, Build ID 849430

I expect that there are wrinkles to be ironed out. But this looks like a step forward.

Does your data form a grid in the x-y plane? Or do you have only an irregular collection of x-y point pairs?

You could look at the following (which covers the case of a grid), here. The constructred procedure `B` can be used to compute f(X,Y) for any given X,Y point. It does not return a bivariate picewise polynomial (formula). But it is possible that you might not actually need a formulaic result, if you have a procedure such as `B` which can be polled at any arbitrary point (X,Y).

There is also an Example worksheet in the Maple help system or recent versions, under the topic examples,Interpolation_and_Smoothing (using underscore for the two spaces between words).

acer

To create a system which is like SI except that the dimension of "action" is given in terms of MeV*s you could try,

Units:-AddSystem('Accelerator',Units:-GetSystem('SI'),'MeV*second'); 
Units:-UseSystem('Accelerator');

You could compare the output of, say, simplify( Unit('h_bar') ) both with and without the above.

nb. You could also use ScientificConstants:-Constant('hbar') and test with ScientificConstants:-GetUnit(...) etc.

Your original definition of system 'Accelerator' associated units with the (separate, simple) dimensions of energy, length, and time, but not with others dimensions. In the call to `AddSystem` that I have above the new system 'Accelerator' comprises all that Maple understands for the 'SI' system as well as a new override for the dimension of action=energy*time.

I don't understand what you've written about contexts, sorry.

acer

Try the GenerateMatrix command in the LinearAlgebra package.

makefill:=(z1,z2,a,b)->plottools:-transform(
(x,y)->[x,y+z1])(plot(z2-z1,x=a..b,filled=true,thickness=0,_rest)):

plots:-display(makefill(2,5,-3,3,color=blue),view=0..10,gridlines=true);

Another way is,

plots:-display(plottools:-rectangle([-3,2],[3,5],color=blue,
thickness=0,transparency=0.35),view=0..10,gridlines=true);

With your original approach I don't see how you can make the white layer opaque so as to mask the underlying blue while still being transparent so as to not mask the underlying gridlines.

acer

Don't reduce Digits the working precision. Reduce the tolerance (accuracy target) for the numeric integration. If you're "only plotting" then you likely don't need results more accurate than about 1e-3 or 1e-4.

Also, the `_dcuhre` method may do better than an iterated 1-D method (since the latter can involve as many evaluations of the integrand as approximately the number of points required for the 1-D case raised to the number of dimensions; here two). 

Also, you could turn off adaptive plotting in the `plot` case. And a coarser grid in the `plot3d` case might still produce a smooth surface; eg. 25-by-25 grid points is about 4 times as few evaluations as Maple 17's default 49-by-49 grid points, but might still be enough for your surface.

test3modif.mw

With all of the above changes the `plot` took less than 2 seconds and the `plot3d` about 15 seconds on my Intel i7 64bit Linux machine. But with Digits=8 your original code took 13 seconds and 200 seconds.

acer

When the procedure `BlocksLSymm` is defined as you've shown then the following message should be seen,

   Warning, `x` is implicitly declared local to procedure `BlocksLSymm`

This means that within your procedure the name `x` used for building up `vars_set` is the implicitly declared local name `x`. With your original code the `x` instances inside `vars_set` -- following the call to the procedure -- are so-called "escaped locals"

That occurs because you assigned to x[1] using a colon-equals assignment statement and `x` was not declared as a global of procedure `BlocksLSymm`.

You have several choices of how to make this code work, even when the statement x[1]:=x[2] is present. Here are a few ways:

One way is to declare `x` as a global of that procedure.

Another way is to change instances of `x` to `:-x` (the global name reference) in the procedure, such as in the line which augments the set assigned to `vars_set`.

Yet another (probably less generally useful) was is to convert `vars_set`, after the computation (either inside the proc, or after it is called). Eg.

  BlocksLSymm(5);
  vars_set := convert(vars_set, `global`);
  `minus`(vars_set, {x[1], x[2]})

My personal preference is to not declare globals in a procedure if it can be sensibly avoided. An alternative method would be to pass in the name as an argument of the procedure. This makes the procedure nicely independent of that particular name to be used later, when calling it. In a somewhat related way there is no clear reason why `vars_set` should be declared as a global of the procedure, since it could simply be used for the return value.

restart:

BlocksLSymm:=proc(stringLength, nm::name) 
local i, j, V, vars_set;
V:=Vector(2^(stringLength)+1,symbol=nm):
# Create List
vars_set:={};
nm[1]:=nm[2];
for i from 0 to stringLength do 
 for j from 0 to i do
  vars_set:={op(vars_set), nm[2^i-2^j+1]};
 end do; 
end do;
return vars_set;
end proc: 

res := BlocksLSymm(5, x):

res minus {x[1],x[2]};

       {x[3], x[4], x[5], x[7], x[8], x[9], x[13], x[15], x[16], x[17], x[25], x[29], 

        x[31], x[32]}

In other words: I suggest getting values (including symbolic names, as well as computed sets) both into and out from procedures by using passed arguments (procedure parameters) and return values. Using declared globals for such things, as a usual way of operating, is not great.

acer

I don't know much about the Calculus Study Guide you mentioned, but even without it I was able to do that problem very easily in Maple 17's Integration Tutor.

I launched it from the main menubar, Tools->Tutors-Calculus -Single Variable->Integration Methods...

I could also have launched it with the command call,

Student[Calculus1][IntTutor]();

In the Function input box I typed,

        cos(5*x)

The syntax has to be valid 1D Maple Notation input.

Both cos5x or cos(5x) are incorrect as 1D Maple Notation for the problem you've described.

Entering cos5x will make Maple think that you've entered the single five character name `cos5x`. It'd be like asking for int(K,x) where the answer is K*x and of course only the Comstant Multiple rule could be used.

And cos(5x) is not valid 1D Maple Notation syntax. As 1D Maple Notation it needs the multiplication sign between the "5" and the "x".

inttutor.mw

There is also an entirely point-and-click mouse driven way to launch the tutor for an expression entered in 2D Math.

* First, load the Student Calculus 1 package using the main menubar. That is, Tools->Load Package->Student Calculus 1  which is the Clickable Math equivalent to the command with(Student:-Calculus1) 

* Next, enter your nicely typeset math expression as 2D Math and right-click on it with the mouse pointer to get the context-sentitive menus. It should be possible to do this for either 2D Math output or input.

* Next, in the popup context-menu, select the Tutors -> Calculus - Single Variable -> Integration Methods

Doing the steps above should launch the Integration Tutor with the given math expression as the Function to be integrated.

acer

One way to go about this is to create an interpolatory procedure. By that I mean a procedure which takes an (x,y) point and returns the interpolated height. With linear interpolation you can thus mimic the `matrixplot` result. And with a procedure you can then easily make an implicit plot of the intersection with z=3.5 say.

Download 3dinterp.mw

You might also consider using a higher order interpolation, by changing `linear` in this code to `cubic` or `spline`. And you can make it finer by using different grids.

And of course you can fiddle with options to plots:-implicitplot, etc.

That technique of obtaining an interpolatory procedure is in the example worksheet Interpolated Plotting and Smoothing.

acer

The Explore command is not deducing that the special words on the right-hand-side of optional plot arguments are not parameters.

There are two ways to deal with this, one of which continues to give you the pop-up window and another which does not. [edited] Neither of these two approaches will work with versions earlier than Maple 17. [/edited]

By creating a procedure or operator `F` which returns your plots then you can call `Explore` on a function call to `F`. The effect here is that only the names of your desired parameters appear in the `Explore` call, and hence only those names appear in the popup window too. But you can still get the popup window.

Another way is to specify all the desired parameters and their ranges by passing an additonal `parameters` argument to the `Explore` command. This bypasses the popup window altogether. The optional `parameters` argument for the `Explore` command was added in Maple 17, so this approach won't work in earlier versions.

[edited] When I originally answered in this thread I had forgotten that I once posted an answer to another, similar question. In that earlier answer I gave some code which would redefine the Explore command in Maple 16 so that the variable (parameter) names could be specified right in the `Explore` call. This is a way to get something like the 2nd approach above (which Maple 17 allows without modification). [/edited]

I've put both of these in the attached worksheet.

Adding_Col_modif.mw

ps. You could also just do it as you had before, and click the "skip" checkboxes in the popup for all names you want ignored.

acer

There is no foolproof method for simplifying everything.

restart:

ee:=-(1/2*I)*(I*Pi*ln(2)-I*Pi*ln(g+4)-2*ln(2)^2
    +2*ln(2)*ln(g+4)-2*ln(2)*ln(-1/2*I)
    +ln(g+4)*ln(-1/2*I)-ln(g+4)*ln(2*I)
    +ln(-1/2*I)*ln(4-g)+ln(4-g)*ln(2*I))/Pi:

S:=combine(expand(ee)) assuming g<>-4;

                                      /    1  \
                              S := -ln|2 + - g|
                                      \    2  /

The above simplified formula seems valid for all g<>-4, which one can visualize,

plots:-display(Array(
  [plot([Re,Im](ee), g=-10..2),plot([Re,Im](S), g=-10..2)]));

I believe that ee=S holds on the complex plane and not just for the real line, except at g=-4. The 2D plot of the imaginary part of ee and S are interesting on account of a similar simplification done at bottom.

Two other ways to get a similar formula that is equivalent to the above S (ie. also valid for all g<>-4) include (as well as the way that Carl showed),

simplify(expand(ee)) assuming g<>-4;

                       -ln(g + 4) + ln(2)

simplify(evalc(ee),size) assuming g<>-4;

                       -ln(g + 4) + ln(2)

The following formula appears to be invalid for real g<-4,

Q:=combine(expand(ee)) assuming g>-4;

                                      /  2  \
                               Q := ln|-----|
                                      \g + 4/

plots:-display(Array(
  [plot([Re,Im](ee), g=-10..2),plot([Re,Im](Q), g=-10..2)]));

You can try the above plots out to see. Here are the imaginary parts of ee and Q for the latter simplification.

plot([Im(ee),Im(Q)],g=-10..2,thickness=3);

acer

It may be that the conversion to exact rationals is causing a problem.

Try is as,

dsolve({ode1,ode2,ic1,ic2},{V(t),L(t)},useint,convert_to_exact=false);

That gives an answer containing an integral, and if you plan on evaluating it at many values of `t` (eg. to plot the L(t) or V(t)) then you might use dsolve,numeric instead (as Carl suggested). You might be better off from a performance or accuracy standpoint, if that is your end goal.

One possible benefit of here is that with common subexpressions in the output (as Classic and the commandline interface give) you may get some additional insight by observing how V(t) depends in form upon L(t),

ode1:=diff(L(t),t)*(V(t))=0.682*10^(-7):

ode2:=137*10^6*diff(V(t),t)*V(t)
      =(1/(4*3.14))*1.66*10^(-10)*L(t)^2*(3.5*10^3-V(t))^2;

ic1:=V(0)=0.01:
ic2:=L(0)=0:

sol:=dsolve({ode1,ode2,ic1,ic2},{V(t),L(t)},
             useint,convert_to_exact=false);

                                              -7   3
                               0.4625796178 10   %1  + 0.00008009
   sol := {L(t) = %1, V(t) = ---------------------------------------}
                                            -10   3
                             0.1321656051 10    %1  + 0.008008651454

   %1 := RootOf(

           _Z
          /                  8                     3
         |    0.1466275660 10  (-0.0001619024037 _f  - 0.2803020000)
       - |    ------------------------------------------------------ d_f + t)
         |                             -7   3
        /              -0.4625782962 10   _f  - 28.03020000
          0

It's awkward to use common subexpression labelling in the Standard GUI, but something like this might do somewhat ok on this example. Given the code above, then in the Std GUI I get,

interface(prettyprint=1):
interface(labelwidth=60):
sol;

      /                                                       3       \     
      |                          -0.000005775998876 RootOf(%1)  - 0.01|     
     < L(t) = RootOf(%1), V(t) = ------------------------------------- >    
      |                                           -9           3      |     
      \                            -1.650285393 10   RootOf(%1)  - 1  /     
        /  /_Z               7 /                  3               \    \    
        | |    1.466275660 10  \0.0001619024037 _f  + 0.2803020000/    |    
 %1 := -| |    ---------------------------------------------------- d_f| + t
        | |                           -8   3                           |    
        \/0             4.625782962 10   _f  + 28.03020000             / 

and looking at these abbreviated forms reveals why the plot of V(t) may appear nearly flat.

acer

restart:
with(LinearAlgebra):

N:=5:

A:=RandomMatrix(N):
C:=RandomMatrix(N):
E:=RandomMatrix(N):

CM:=A-L*C-L^2*E;

vals:=[fsolve(Determinant(CM),L,complex)];

for i from 1 to nops(vals) do
   vecs[i]:=NullSpace(eval(CM,L=vals[i]));
end do:

# Now check
seq(seq(Norm(eval(CM.x,[L=vals[i]])),
        x in vecs[i]),i=1..nops(vals));

acer

Using Maple 13.01 for 64bit Linux I get that same error message.

Using Maple 14 I get a return value of `undefined` for 64bit Linux.

 T:=ln(ln(n))*(ln(n)*(n*(
       (abs(sin(n))/n^2)/(abs(sin(n+1))/(n+1)^2)-1)-1)-1);

                        /      /  /                  2    \    \    \
                        |      |  || sin(n) | (n + 1)     |    |    |
         T := ln(ln(n)) |ln(n) |n |------------------- - 1| - 1| - 1|
                        |      |  |  2                    |    |    |
                        \      \  \ n  | sin(n + 1) |     /    /    /

MultiSeries:-limit(T, n=infinity);

                                   undefined

kernelopts(version);

            Maple 14.00, X86 64 LINUX, Apr 5 2010, Build ID 479326

acer

I got down to about 1-2 seconds for Qsim to run with the original value of Size.

This was on a a machine for which I got similar timings to what you reported when I ran your original code.

I got that by compiling SampleQ. And it automatically falls back to the fast evalhf interpreter if the compiler fails (or is not set up, etc).

I think that I'd try and roll multiple B[i] calculations right into the SampleQ routine, before I tried parallelizing. I say this because Maple function calls are relatively expensive. That might require forming the random sample `A` (from X) with enough data for multiple B[i] calculations.

Simulation_comp.mw

acer