acer

10 years, 130 days


These are answers submitted by acer

various

February 05 2016 acer 12145

It seems that you want to get a visual display of the progress being made.

One simple way is to use a command such as print, or printf, or userinfo. One drawback to those is that it clutters the worksheet with all the printed values. You can mitigate that by printing only a select number of values (using irem or mod, say) but then you lose the granularity and still have some clutter. Another drawback is that it doesn't work in a Document Block -- the values are only display (all at once), after the whole computation in that Block completes.

If you're using the Standard GUI then read on, for ways that work even if you call the procedure or loop code from within a Document Block.

You can use Embedded Components for this. One way to do it consists of manually inserting say a TextArea or Slider component into the worksheet and then at each iteration of the loop calling DocumentTools:-SetProperty to update the component using the current value of the loop index variable. A drawback of this approach is that if you insert the component from the palette then its position in the worksheet is not dynamic. The location of the component may not always be convenient if you want to re-use it from several places in your worksheet.

One simple alternative available in Maple 2015 is to use DocumentTools:-Tabulate to inform you of the current loop status. Here is an example.

p := proc()
  uses DocumentTools;
  local i, N;

  N := 5;

  for i from 1 to N do

    Tabulate([sprintf("Doing iteration %a of %a",i,N)],
             ':-widthmode'=':-pixels', ':-width'=150);

    Threads:-Sleep(1); # replace with your own computations

  end do;

  InsertContent(Layout:-Worksheet()); # empty

  return i-1; # or whatever you want
end proc:

So now if you call procedure p you can see the effect.

  p();

tab.mw

The above example can be easily modified to show more intermediate results. The first argument passed to Tabulate doesn't have to be a list with only single formatted string -- you could make it a list with a formatted string as well as some math expression and a plot, etc.

If your loop index takes all values from 1 to 10000 then I suggest that you only display some values. For example, using irem to update the display every 500th iteration:

tab2.mw

There are other interesting alternatives, including programmatic insertion of a Slider component (or other sliding component) for use as a progress indicator, instead of the GUI Table that Tabulate inserts. (I have examples, if people are interested...)

acer

SetProperty

February 04 2016 acer 12145

Look at the help page for ComboBox components.

Suppose that your ComboBox component has identity "ComboBox0". Then you can do it with the following commands,

L := [m, n, c, k]; # Get a list of parameter names

Ls := map(convert,L,string); # convert them to strings

DocumentTools:-SetProperty("ComboBox0", ':-itemList', Ls, ':-refresh');

acer

sigh

January 30 2016 acer 12145

This scalar is not zero.

restart;

ee := (-3/186591314-(2/13327951)*I)*(-((28412308*I)*3^(1/2)+44068556*3^(1/2)
      +(-76328978-49211561*I))/(((4*I)*3^(1/2)+4*3^(1/2)+(-7-9*I))^2
      *((-3-4*I)+2*3^(1/2)+(2*I)*3^(1/2))^6))^(1/2);

       /      3          2      \ /  /            (1/2)
       |- --------- - -------- I| |- \28412308 I 3     
       \  186591314   13327951  / \                    

                      (1/2)                           \//
          + 44068556 3      + (-76328978 - 49211561 I)/ |
                                                        \

                                             2 
         /     (1/2)      (1/2)             \  
         \4 I 3      + 4 3      + (-7 - 9 I)/  

                                             6\\      
         /                (1/2)        (1/2)\ ||^(1/2)
         \(-3 - 4 I) + 2 3      + 2 I 3     / //      

simplify(ee);

                               0

evalf[10000](ee): evalf[10](%);

                            -9                 -8  
             -2.481288046 10   - 2.748412826 10   I

acer

DataTable

January 28 2016 acer 12145

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...

restart;

# This is an expected error, as the local declaration does not
# come before all other statements in the body (including empty ones).
test := proc()
  ;
  local a;
  a := 3
end proc;

Error, unexpected `local` declaration in procedure body

# This is an expected error, as the local declaration does not
# come before all other statements in the body (including empty ones).
test := proc();
  local a;
  a := 3
end proc;

Error, unexpected `local` declaration in procedure body

# In Maple 2015.0 the GUI attempts to execute the following

# while inserting (behind the scenes) a semicolon terminator

# at the end of the first line. That produces the error case

#  immediately above. This was fixed in the Maple 2015.1 update.

test := proc()

  local a;

  a := 3

end proc;

Error, unexpected `local` declaration in procedure body

# This is OK, across versions.``

test := proc()
  local a;

  a := 3

end proc;

proc () local a; a := 3 end proc

# This is OK, across versions.
test := proc()
  local a;
  a := 3
end proc;

proc () local a; a := 3 end proc

kernelopts(version);

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

 

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

complex n

January 26 2016 acer 12145
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

syntax

January 26 2016 acer 12145

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

Heaviside

January 25 2016 acer 12145

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

MWP44_edited.mw

acer

typeset

January 25 2016 acer 12145

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

additonally

January 25 2016 acer 12145

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).

 

NULL

restart

assume(sigma > 0); about(sigma)

Originally sigma, renamed sigma~:
  is assumed to be: RealRange(Open(0),infinity)

NULL

assume(mu, 'real')

int(exp(-x)/(1+exp(-x))^2, x = -infinity .. infinity)

1

NULL

int(exp(-x+mu)/(1+exp(-x+mu))^2, x = -infinity .. infinity)

1

NULL

int(sigma*exp(-sigma*x)/(1+exp(-sigma*x))^2, x = -infinity .. infinity); int(exp(-x/sigma)/(sigma*(1+exp(-x/sigma))^2), x = -infinity .. infinity)

1

1

NULL

int(exp(-(x-mu)/sigma)/(sigma*(1+exp(-(x-mu)/sigma))^2), x = -infinity .. infinity)

1

restart

assume(sigma > 0); about(sigma)

Originally sigma, renamed sigma~:
  is assumed to be: RealRange(Open(0),infinity)


NULL

additionally(sigma, 'real'); about(sigma)

Originally sigma, renamed sigma~:
  is assumed to be: RealRange(Open(0),infinity)


assume(mu, 'real')

int(exp(-x)/(1+exp(-x))^2, x = -infinity .. infinity)

1

NULL

int(exp(-x+mu)/(1+exp(-x+mu))^2, x = -infinity .. infinity)

1

NULL

int(sigma*exp(-sigma*x)/(1+exp(-sigma*x))^2, x = -infinity .. infinity); int(exp(-x/sigma)/(sigma*(1+exp(-x/sigma))^2), x = -infinity .. infinity)

1

1

NULL

int(exp(-(x-mu)/sigma)/(sigma*(1+exp(-(x-mu)/sigma))^2), x = -infinity .. infinity)

1

restart

assume(sigma > 0);

Originally sigma, renamed sigma~:
  is assumed to be: RealRange(Open(0),infinity)


assume(sigma, 'real'):

Originally sigma, renamed sigma~:
  is assumed to be: real

assume(mu, 'real'):

int(exp(-x)/(1+exp(-x))^2, x = -infinity .. infinity);

1

int(exp(-x+mu)/(1+exp(-x+mu))^2, x = -infinity .. infinity);

1

int(sigma*exp(-sigma*x)/(1+exp(-sigma*x))^2, x = -infinity .. infinity);

int(sigma*exp(-sigma*x)/(1+exp(-sigma*x))^2, x = -infinity .. infinity)

int(exp(-x/sigma)/(sigma*(1+exp(-x/sigma))^2), x = -infinity .. infinity)

int(exp(-(x-mu)/sigma)/(sigma*(1+exp(-(x-mu)/sigma))^2), x = -infinity .. infinity);

int(exp(-(x-mu)/sigma)/(sigma*(1+exp(-(x-mu)/sigma))^2), x = -infinity .. infinity)

``

 

Download integral_edited.mw

acer

no

January 21 2016 acer 12145

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

unevaluated entries

January 21 2016 acer 12145

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.

 

restart

with(LinearAlgebra):

InertiaTensor := Matrix(3, 3, {(1, 1) = 5/2, (1, 2) = sqrt(3/2), (1, 3) = sqrt(3/4), (2, 1) = sqrt(3/2), (2, 2) = 7/3, (2, 3) = sqrt(1/18), (3, 1) = sqrt(3/4), (3, 2) = sqrt(1/18), (3, 3) = 13/6})

InertiaTensor := Matrix(3, 3, {(1, 1) = 5/2, (1, 2) = (1/2)*6^(1/2), (1, 3) = (1/2)*3^(1/2), (2, 1) = (1/2)*6^(1/2), (2, 2) = 7/3, (2, 3) = (1/6)*2^(1/2), (3, 1) = (1/2)*3^(1/2), (3, 2) = (1/6)*2^(1/2), (3, 3) = 13/6})

Eigenvectors(InertiaTensor)

Vector(3, {(1) = 1, (2) = 2, (3) = 4}), Matrix(3, 3, {(1, 1) = 0, (1, 2) = 0, (1, 3) = 0, (2, 1) = 0, (2, 2) = 0, (2, 3) = 0, (3, 1) = 0, (3, 2) = 0, (3, 3) = 0})

lprint(InertiaTensor);

Matrix(3, 3, {(1, 1) = 5/2, (1, 2) = sqrt(3/2), (1, 3) = sqrt(3/4), (2, 1) = sqrt(3/2), (2, 2) = 7/3, (2, 3) = sqrt(1/18), (3, 1) = sqrt(3/4), (3, 2) = sqrt(1/18), (3, 3) = 13/6}, datatype = anything, storage = rectangular, order = Fortran_order, shape = [])

Normalizer := simplify; Eigenvectors(InertiaTensor); Normalizer := normal

Vector(3, {(1) = 2, (2) = 1, (3) = 4}), Matrix(3, 3, {(1, 1) = 0, (1, 2) = -3^(1/2), (1, 3) = 3^(1/2), (2, 1) = -(1/2)*2^(1/2), (2, 2) = 2^(1/2), (2, 3) = 2^(1/2), (3, 1) = 1, (3, 2) = 1, (3, 3) = 1})

Eigenvectors(copy(InertiaTensor))

Vector(3, {(1) = 2, (2) = 1, (3) = 4}), Matrix(3, 3, {(1, 1) = 0, (1, 2) = -3^(1/2), (1, 3) = 3^(1/2), (2, 1) = -(1/2)*2^(1/2), (2, 2) = 2^(1/2), (2, 3) = 2^(1/2), (3, 1) = 1, (3, 2) = 1, (3, 3) = 1})

Eigenvectors(map(eval, InertiaTensor))

Vector(3, {(1) = 1, (2) = 4, (3) = 2}), Matrix(3, 3, {(1, 1) = -3^(1/2), (1, 2) = 3^(1/2), (1, 3) = 0, (2, 1) = 2^(1/2), (2, 2) = 2^(1/2), (2, 3) = -(1/2)*2^(1/2), (3, 1) = 1, (3, 2) = 1, (3, 3) = 1})

Eigenvectors(rtable_eval(InertiaTensor))

Vector(3, {(1) = 2, (2) = 4, (3) = 1}), Matrix(3, 3, {(1, 1) = 0, (1, 2) = 3^(1/2), (1, 3) = -3^(1/2), (2, 1) = -(1/2)*2^(1/2), (2, 2) = 2^(1/2), (2, 3) = 2^(1/2), (3, 1) = 1, (3, 2) = 1, (3, 3) = 1})

rtable_eval(InertiaTensor, inplace)

Matrix([[5/2, (1/2)*6^(1/2), (1/2)*3^(1/2)], [(1/2)*6^(1/2), 7/3, (1/6)*2^(1/2)], [(1/2)*3^(1/2), (1/6)*2^(1/2), 13/6]])

lprint(InertiaTensor);

Matrix(3, 3, {(1, 1) = 5/2, (1, 2) = (1/2)*6^(1/2), (1, 3) = (1/2)*3^(1/2), (2, 1) = (1/2)*6^(1/2), (2, 2) = 7/3, (2, 3) = (1/6)*2^(1/2), (3, 1) = (1/2)*3^(1/2), (3, 2) = (1/6)*2^(1/2), (3, 3) = 13/6}, datatype = anything, storage = rectangular, order = Fortran_order, shape = [])

Eigenvectors(InertiaTensor)

Vector(3, {(1) = 1, (2) = 4, (3) = 2}), Matrix(3, 3, {(1, 1) = -3^(1/2), (1, 2) = 3^(1/2), (1, 3) = 0, (2, 1) = 2^(1/2), (2, 2) = 2^(1/2), (2, 3) = -(1/2)*2^(1/2), (3, 1) = 1, (3, 2) = 1, (3, 3) = 1})

 

 

Download InertiaTensor_edited.mw

acer

copy

January 20 2016 acer 12145

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

edited

January 18 2016 acer 12145

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

something...

January 14 2016 acer 12145

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.

 

1 2 3 4 5 6 7 Last Page 1 of 121