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

Would your Maple code still be valid and work as intended if you used .~ or perhaps *~ for the multiplcations in question? Or could you adjust it easily so that was the case?

If that holds then you may be able to extend the CodeGeneration[Matlab] translator so that those get translated to .* as Matlab syntax. (See here for some notes on that...).

Just an idea.

acer

What you've described seems similar to what I usually see. Ie, if I run cmaple.exe the Command Line Interface (CLI) under cygwin (a Unix-like environment for MS-Windows) then after an input syntax error the offending input is redisplayed and the cursor is positioned where Maple supposes that the error lies.

I can then use the right- and left-arrow keys to move the cursor, and the Backspace and Delete keys work, and it's in insert mode. So I can easily edit the input and make a correction.

The up- and down-arrow keys also step through my command history. The behaviour is much as if I were running the CLI under Linux or Unix. Ie, usual readline behaviour.

Alternatively, if I hit the Esc key (Escape) then the CLI maple prompt and input line respond to vi editor key bindings. I find this very handy.

The above works for me in the CLI under cygwin, and it doesn't seem to rely on whether I pass the `-u` option when invoking the CLI.

You didn't mention your OS. You didn't mention whether you are in fact using the CLI in a terminal window. If you are then does any of the above work for you?

acer

You could try running the Matlab[FromMFile] command against it.

Eg, if the original is in file "matin.txt" say,

Matlab[FromMFile]( "matin.txt", string );

or,

Matlab[FromMFile]( "matin.txt", "mapleout.mpl" );

where either those file names are changed to have their fully explicit paths or currentdir() has been called to set the location.

You may have to make a few edits to the original though, before doing that. You seem to be missing a second "end" for the double for-loop at the end of the code. Amd you may have to change the single backslashes "\" to double backslashes "\\" in the call to the Matlab `textread`.

The final result may need some work (you didn't supply the referenced data file so it's hard to test). But it may give you something to start with. You might wish to add "datatype=float[8]" to some of the resulting `rtable` constructor calls. And there may be other things to fix up.

The source is pretty simple. If you know basic syntax in both languages then you may find it easier to just write it manually.

acer

How about using GroupTheory:-Intersection from the GroupTheory package new to Maple 17?

(There is also group[inter] in the older group package.)

acer

Try the Programming Manual. There is a chapter on it. It has examples.

acer

Use a semicolon rather than a colon at the end of the command which would normally cause the plot to be displayed (ie. in this case the `plot3d` call).

acer

You can use so-called 2-argument `eval` for this.

eval( theta3, sol);

If the choice of variable names are changed then using `eval` in this way will be more robust then referring to some member of the set `sol` by position. For some other choice of variable names the position of the equation for `theta3` might be different (ie. not necessarily the 5th place).

acer

Import as datatype anything to Matrix M. The extract the column of interest, eg. V:=M[..,3] for the third column, say. Extract the column of M that you believe to contain floats.

At this point the entries of V are either all floats, or at least one is not. You wrote that the corresponding column in M does contain all floats. If that is true then so should V.

Then try executing Vector(V,datatype=float[8]) and if it produces an error message then post that here.

Other tests you might possibly find useful are,

type(V,'Vector(float)');

{seq(whattype(x), x in V)}; # could be slow

You wrote, "That fails since my data are now not floats." What was "that" operation that failed?

acer

If you only need a plot (reasonably) quickly, and only require the plotted function to be as accurate as is reasonably discernable by eye, then you can plot the numeric integral using relaxed accuracy requirements. Turning off adaptive plotting can also speed it up, but you may need to adjust the forced number of plotted points as the plotting range of the oscillatory function is increased.

The plot looks smoother in the Std GUI than is shown below. I lose resolution when exporting and uploading here. It doesn't take much longer, with keeping the adaptive plotting turned on.

To reduce the accuracy requirement I pass the epsilon=value option to evalf(Int(...)) , and so I rename your variable `epsilon` to `varepsilon` in order to avoid a naming conflict.

It's not strictly necessary to symbolically take the real part of your original integrand here, but it is a bit faster I think.

restart:  

igrand:=exp(I*epsilon*ln((2+t)/(2-t)))*exp(I*n*t)/sqrt(4-t^2)/Pi:
igrand:=simplify(evalc(Re(igrand))) assuming real, t>-2, t<2:            
newigrand:=subs(epsilon=varepsilon,igrand):                                  

ee:=Int(newigrand,t=-2..2,epsilon=1e-5,method=_d01ajc):                      

st:=time():
plot(eval(ee,[varepsilon=-0.4]),n=-10..10,adaptive=false,numpoints=100); 
time()-st;

                                 0.260

acer

restart:

v:=[seq(0.29+i/100,i=1..8)]:
k:=[seq(2*i,i=1..50)]*0.5*10^(-15):

M:=ExcelTools:-Import("data1.xlsx"):

plots:-surfdata(M, v[1]..v[nops(v)], k[1]..k[nops(k)]);

The `surfdata` command would accept Matrix(M) as well as listlist M, which would let you compare with calling `matrixplot`.

And of course you could just use 8 and 50 instead of nops(v) and nops(k). Or just use the first and last entries of your current v and k (and don't bother to construct either of those two lists unless you need them for something else...). Ie,

plots:-surfdata(M, v[1]..v[8], k[1]..k[50]);

plots:-surfdata(M, 0.3..0.37, 1e-15..5e-14);

and so on.

acer