How about inserting a DataTable (from the Embedded Components palette) and associating its data with a name to which you have assigned the imported Maple Matrix?

You can associate a DataTable component with an existing Matrix by right-click to change the components properties. You don't need to make all the rows and columns visible. If you want you can even toggle the visibility of the whole component.

When you close and repoen the worksheet that variable name should automatically have the Matrix as its assigned value.

DT2.mw

acer

Now that I have the problematic worksheet I can reproduce the error in Maple 2015.0, and I recall why it occurs.

In Maple 2015 the statement terminator (colon or semicolon) was made optional for 1D Maple Notation input (on a line with a prompt). See the last section, "More Updates" on this page, the body of which declares:

     Previously, if a command was entered in 1-D without a semi-colon, a warning
     would be returned. In Maple 2015, the missing semicolon warning has been
     removed for 1-D math.

The original implementation of this was buggy in Maple 2015.0, in the following repsect. The GUI was automatically (behind the scenes) including the terminator for 1D input lines that lacked a terminator if the following line in the Group had a prompt. The GUI was not restricting this to only the last line of a mult-line 1D input in an Execution Group.

In Maple 2015.1 the implementation was fixed, and it appears that the statement terminator is now only ever added (behind the scenes) by the GUI to the last line of 1D input in an Execution Group.

I had difficulty reproducing the problem at first because I was using Ctl-Enter to type in the example, or pasting it from your question. I reproduced it by conjoining multiple 1D input lines -- each with their own prompts -- using the F4 key. The input prompt at the start of the second line of the proc body was needed, in order to reproduce.

Where I write "all other statements in the body" below I mean statements other that `global` declaration, `uses` or`use` calls, `description` statement, `option` statement...

Download DM_2015.0.mw

I could add the the "expected" error cases above also produce the same errors in the Command Line Interface (CLI, or TTY). It does seem like an unnecessary restriction, and I don't see why an empty statement couldn't also be a permitted exception.

acer

restart;                                                

ee := 3^(-(1/2)*n)*2^((1/6)*n)-2^((2/3)*n)*6^(-(1/2)*n):

simplify(combine(evalc(eval(ee,n=t+s*I)))) assuming t::real, s::real;

                                       0

simplify(combine(evalc(eval(ee,n=t+s*I))));                          

                                       0

Or,

simplify(combine(evalc(convert(eval(ee,n=t+s*I),exp))));

                                       0

acer

In your assignment to bcs you have an extra space between D(f) and (etainf) which makes that term be parsed as a product (multiplication) instead of a function call.

acer

One thing that seems to work here is converting the abs in the integrand to Heaviside (before integrating).

MWP44_edited.mw

acer

The following works for me. What version are you using?

restart;

kernelopts(version);

                  Maple 2015.0, X86 64 LINUX, Feb 17 2015, Build ID 1022128

p1:=plot(sin, -Pi..Pi,-1..1):

t1:=plots:-textplot([Pi/2,0.8,typeset(x[0],y[0])]): # no comma
t2:=plots:-textplot([-Pi/2,0.8,typeset(x[0],",",y[0])]): # notice comma
t3:=plots:-textplot([-Pi/2,-0.8,typeset([x[0],y[0]])]):
t4:=plots:-textplot([Pi/2,-0.8,typeset([x__0,y__0])]): # notice italic zero

plots:-display(p1,t1,t2,t3,t4);

acer

Your second call to `assume` on sigma wipes out the earlier assumption on sigma.

You can either change the second one to be a call to `additonally` rather than to `assume`, or you can get rid of the second one altogether (as the first implies that sigma is real, as shown using the `about` command).

Download integral_edited.mw

acer

No, they can differ in how evaluation is done relative to the iteration. With $ the first argument may be instantiated, and some single result repeated. With seq each instance is evaluated separately -- the iteration leading evaluation.

For example,

restart;       

f:=rand(1..10):

f()$i=1..5;    

                                 7, 7, 7, 7, 7

seq(f(), i=1..5);

                                10, 6, 2, 4, 6

'f()'$i=1..5; # murky

                                10, 2, 8, 10, 9

I suggest that if one cannot remember this distinction then prefer seq (or figure out the difference over and over...).

acer

The bug is that when using the Matrix palette (likely coincidentally in combination with the expression palette) the entries are not evaluated. Your Matrix has unevaluated calls to `sqrt` in it, rather than actual radicals.

In consequence, type checking does not see radicals and entry recognition (eg, for pivot zero-testing during nullspace computation) goes awry.

You can get around the bug by giving the entries of the Matrix the evaluation they originally deserved, or (for your particular computation!) setting Normalizer strong enough. I very much prefer the former.

Sufficient then should be,

InertiaTensor := map(eval, InertiaTensor);

I can reproduce the bug by entering the Matrix using the Matrix palette and the Expression palette. Here that is.

Let me say again: I strongly recommend working around this Matrix palette bug by giving the Matrix entries their deserved, usual evaluation, rather that by setting Normalizer. (I show about four ways of doing that below.) I say this because setting Normalizer works around this particular computation but doesn't prevent other failings in other computations due to the unevaluated entries. I really hope that point is clear.

Moreover having set Normalizer you really ought to set it back to normal afterwards because otherwise it will not get automatically promoted for other LinearAlgebra computations (in session) in the presence of trig function calls and the same problem could recur for them. For your example either radnormal or simplify is adequate as Normalizer to get the result.

Download InertiaTensor_edited.mw

acer

How about copy (of eval of) the proc?

restart;

interface(prettyprint=1): # to visualize the following, pasted as plaintext

p:=proc(x) option remember; x^2; end proc:

p(3.4);

                                    11.56

op(4,eval(p));

                            TABLE([3.4 = 11.56])

f:=copy(eval(p));

                 f := proc(x) option remember; x^2 end proc;

op(4,eval(f));

                            TABLE([3.4 = 11.56])

addressof(eval(p)), addressof(eval(f));

                 18446744074332570478, 18446744074332570742

restart;

p:=proc(x) x^2; end proc:

p(3.4) := 11.56:

op(4,eval(p));

                            TABLE([3.4 = 11.56])

f:=copy(eval(p));

                         f := proc(x) x^2 end proc;

op(4,eval(f));

                            TABLE([3.4 = 11.56])

addressof(eval(p)), addressof(eval(f));

                 18446744074332570390, 18446744074332570566

acer

Attached is an edited file.

Noter_a.mw

The problem seems to be on the line of text beginning with, "derfor altid". There seems to be an invalid XML character (Unicode 0xb  a vertical tab?) after the "m" in "og m fra" on that line. I deleted that character in an external editor (vi) and resaved. The attached edited copy now opens in Maple 2015 and shows the content below that line.

acer

I have previously submitted a Software Change Request (SCR) that the three angles (as well as the projection value) be made properties of a Plot Component, and this case at hand is typical.

In the past I have made do with the method member vv suggested: 3 sliding components where the plotting call makes use of their values for the orientation option. Of course that does not help with the case of right-click-drag rotation by hand in the Plot Component itself.

It's not very efficient but some data can be pulled off the plot in the Plot Component. It wasn't always the case I believe, but in recent Maple versions when a 3D plot in a Plot Component is rotated manually the orientation is preserved in the PROJECTION(...) substructure when the PLOT3D structure is retrieved from the component using DocumentTools:-GetProperty. (I say not efficient, because this involves making the GUI send the whole structure to the kernel which then has to call indets on it. It should in principle be more efficient to have a new mechanism which sent just one or more of the three angles.)

Here is an example of what I mean. It's unfortunate that it requires a separate Button or other Component (with an associated Action) to grab the data. It would be nicer if we could hook up the click-and-drag code to the manual rotation of a 3D plot, but I don't think that's currently possible.  proj.mw

So a question arises, can we decode the first 9 values in the PROJECTION substructure so as to attain the equivalent three angles theta, psi, phi? I suspect that the 10th value is the projection setting, which can be adjusted using the right-click context menu of a 3D plot. I do not see it explained in the help page on plot structures.

 [edit] It's possible that this is enough to deal with this Question, without decoding the meaning of the values. The "updating" code could yank out the current PROJECTIONS substructure, then create the new 3D plot using its current method, and then substitute that PROJECTIONS into that new 3D plot structure (while also removing any ORIENTATION substructure) before setting it as the value of the Plot Component.

http://lmgtfy.com/?q=.tar.gz

acer

How about isolating for x(s), and then dividing the equation by theta(s)?

After that, you might simplify as you see fit.

isol15.mw

acer

You should google numeric integration rules.

Maple offers several different numeric integration methods, some of which are adaptive. There's no reason why they should poll the integrand at values in an ascending order. Why do you think they ought to??

See the help page for evalf/Int and pay particular attention to the mehtods listed for 1D numeric integration as well as the section "Outline of the Numerical Integration Polyalgorithm (1-D Integrals)". Your example first is first tried with the _d0ajc method using hardware floats, and after that fails (due to non-evalhf'ability) it goes to the _Dexp method (via the routine `evalf/int/quadexp`).

You can get a lot of information about the process by setting infolevel[`evalf/int`] or by tracing through the various routines. Note that if you want to retry in the same session then you have to clear the relevant remember tables using the forget command, or else the prior result may be returned without recomputation.

Download evalfint.mw

acer