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

You could use a nonzero transparency for the surface. Or you could use plottools:-transform to raise B to the surface (or use P_Pi2 for the third element of the spacecurve) instead of using it just as a background. Or plot B as a transparent cylinder. Or all of the above.

acer

I sometimes do this sort of thing as follows:

restart;

cav1 := proc (a)

     printf("degree = %f\n", a);

     printf("radian = %d\n", evalf((1/180)*a*Pi));

end proc:

cav1(260);
  degree = 260.000000
  radian = 
  Error, (in fprintf) integer expected for integer format

stoperror(lasterror);
            ["integer expected for integer format"]

And now when I call cav1(260) once again the debugger stops at the problematic line, which happens to be in fprintf not cav1. So at the debugger prompt I'd then enter where so as to see how it got from the user-defined procedure (cav1) to the current location. After entering where the debugger shows something like,

TopLevel: cav1(260)
	[260]
cav1: printf("radian = %d\n",evalf(1/180*a*Pi))
	["radian = %d\n", 4.537856054]
printf: fprintf('default',args)
	[default, "radian = %d\n", 4.537856054]
fprintf:
   1   iolib(9,args)

which I think makes it more clear which statement in cav1 led to the problem.

acer

@Mac Dude I see a few different kinds of oddness in your document.

One kind is the rhs of assignment statements, where the lhs is like "H :=" in 2D Math black, and the rhs is what I'd normally expect to see as the 2D Output (ie. its echoes the assignment big, being like "H := ...." but all in blue). This kind seems to be fixable by right-click contextmenu action to convert the whole input to 1D, and then back to 2D Input. Minor touch up to turn Physics[Vectors][Norm] back into just a marked up Norm may be desired, etc.

A second kind was the same effect by on non-executable 2D Math, inline in a paragraph of text say.

A third kind seems to be where normally black 2D Input is partially in blue.

I think I could fix up the second and third kind too, as a one-off fix. But I should ask some questions.

- How did the Document arrive at this state? Do you think that it was because a Maple 2015 Document was reopened and saved in Maple 15, or some such thing?

- What are you hoping for here? A fixed document, or a reliable way to re-fix if the problems resurface? I believe that I can do the former, but not the latter. (I figure that you might accomplish most the former too, if just by rewriting...)

- Is the third class of oddness described above a problem for you, or just my imagination? Did you ever have Equation Labels turned on, when authoring this?

- I didn't see instances of 2D output completely separate from any input (which is what I'd originally imagined, document unseen, based only on your description). Did I overlook another kind of problem?

You mentioned the XML of a .mw file. 2D Input and Output can get stored in the XML with two blobs of base64 encoded dotm (.m), one for the math expression and one for the typeset quantity. For example when the typesetting mode is "extended" then both of those can be utilized. You document appears to have Input for which the encoded expression is OK but somehow the associated encoded typeset blob has been clobbered with the encoded typeset blob of some Output. (That sort of detail helps me, and may help me repair, and it may provide hints to us, but otherwise I offer it just as detail -- I don't expect you to have to act upon it.)

I'll be visiting this site seldomly over the next 7-10 days. Please add a note if you need a fix up fast, even if only for some portion.

Using Maple 13.01,

Download convertQ.mw

acer

What are you trying to ask, when you write, "compute this equation"?

is( (x^2)^(0.5) = x ) assuming x>0;

                                    true

simplify( (x^2)^(0.5) ) assuming x>0;

                                      x

is( (x^2)^(1/2) = x ) assuming x>0;

                                    true

simplify( (x^2)^(1/2) ) assuming x>0;

                                      x

acer

I'm guessing that you mean the Standard GUI.

You could change (the color of) the Character Style for "2D Output", and then save that as a new style set and make it your new default. See here for a style set overview.

acer