Product Suggestions

Post your suggestions on new features and products.

Has this ever happened to you? You’re using Maple Learn, and having a grand old time, but suddenly! The horror! You notice a bug! Of course, it’s a shocking experience to realize that our products are not, in fact, flawless, but unfortunately it’s true. There are bugs. But, what’s this? There’s a glimmer of hope on the horizon… the Flag a Problem button! By using the Flag a Problem button, you can let us know about the problem you found, and with the power of our mighty development team, we’ll fix it! Yes, with our forces combined… we can defeat all of these bugs!

A picture of the Flag a Problem button with glowing rays surrounding it.

In all seriousness, we really do appreciate your feedback. Whether you’ve spotted a bug or are looking for a new feature, let us know! We’re constantly updating and improving Maple Learn, and user feedback is a hugely important part of this process. For example, we had a user suggest that Maple Learn treat Δt as a single entity, as in physics that notation is used to mean a change in time rather than Δ times t. And we’re happy to announce that this is now a feature! Here’s just a taste of some of the other things we’ve changed based on user feedback:

  • Can now use the Context Panel to evaluate operations with matrices
  • Maximum number of intersection points shown has increased to 20
  • Intersection points now shown for parametric equations and circles
  • Using the Context Panel no longer scrolls the page
  • Quick Actions menu no longer parameterizes the f of f(x)
  • Fixed display bug for inverse trig functions

Evidently, not every piece of feedback we get is a feature request. Sometimes there’s bugs! And we want to hear about those too. In all honesty, I think it’s pretty neat to see the bugs I’ve reported being fixed. It wasn’t too long ago that I noticed a small error with tables—when the header of the table had a subscript, pressing the down arrow jumped to the next group instead of the next row. I reported it, and now it’s fixed! I can’t help but feeling a little smug, like I’m the one who fixed it. Of course, the credit for the actual code goes to our developers. But it is also true that they wouldn’t have fixed it if no one had pointed it out. Truly, teamwork makes the dream work. And if you want to feel smug about the bug you pointed out being fixed, or the feature you asked for being added, then head on over to that Flag a Problem button. Let us know what you want to see and we’ll listen. What’s more, we’ll be making more posts every now and then to let you know about what’s new with Maple Learn and what we’ve changed based on your feedback. That way you have something to print out and frame on your wall as proof of the contribution you’ve made to Maple Learn! (Or I suppose you could just read it. But where’s the fun in that?)

In the context of analyzing physical systems I often have to plot results in the form of y=f(x,a,b,c,…). Here the plot variables x and y are physical quantities and the system parameters a,b,c… can have units as well.

After substitution of parameters the expression f(x,a,b,c,…) can be plotted using plot(f(x,a,b,c,…),x_range). Unit choice and labeling of the abscissa work already well when x_range is given in the format x=x0..x1 (where x0 and x1 have a value and a unit). This is already a huge improvement since labeling and unit conversion errors on the abscissa are almost impossible.

Also, the units on the ordinate are correctly displayed. However, if the depended variable y is desired to be displayed on the ordinate it must be added by hand using the label option. In doing so the display units and labels of both axes must be re-entered by hand. This re-entering step is a source of labeling and conversion errors.

To improve ordinate labeling and to reduce conversion errors I would love to see two improvements:

  • A plot option that would allow unit conversion of plot axes. I.e. telling Maple in which units a physical quantity has to be displayed and forcing a rescaling of the values of the physical quantities.
  • With less priority and additional to expressions, the plot command should also accept equations in the form of y=f(x) as input. This would lead to a very compact syntax that produces content rich and, more importantly, correct plots of physical quantities. Wrong labeling and conversion errors would be very unlikely.

Overall, I am very pleased by Maples unit functionality. I have been reluctant to switch from my old work style of using names as unit placeholder and self-made conversion sets. But now I feel that the likelihood of producing unit conversion errors with my old work style has become higher than using Maples units.

I can only encourage interested users to give units a try. Its good!  For me it has turned out to be time worth invested.

I also hope that Maplesoft continues their efforts of providing more unit functionalities. It’s a big task but calculations with physical quantities are also a big differentiator.  

... and two suggestions to the development team

POINT 1
In ?DiscreteValueMap (package Statistics) it's given an example concerning rhe Geometric distribution along with this comment:
"The Geometric distribution is discrete but it necessarily assumes integer values, so (bold font is mine) it also does not have a DiscreteValueMap"

This sentence seems to indicate that "because a distribution is discrete over the set of integers, it cannot have a DiscreteValueMap", some sort of logical implication...

But my feeling is that the Geometric distribution (or any other discrete distribution) does not have a DiscreteValueMap because this attribute has just not been specified when defining the distribution.

restart:
with(Statistics):

GeomRV := RandomVariable(Geometric(1/2)):
f := unapply(ProbabilityFunction(GeomRV, n), n):

AnotherGeomRV := Distribution(
      'ProbabilityFunction'=f,
      'Support'=0..infinity,
      'DiscreteValueMap'=(n->n),
      'Type'=discrete
):
DiscreteValueMap(AnotherGeomRV , n);

Thus having the set of natural numbers as support doesn't imply that DiscreteValueMap cannot exist.

Suggestion 1: modify the ?DiscreteValueMap help page so that it no longer suggests that some discrete distributions cannot have a .DiscreteValueMap 

______________________________________________________________________________________

POINT 2
I think there exists a true problem with the definition of discrete distributions in Maple: the ProbabilityFunction of a (discrete) random variable) takes non zero values outside their definition set.
For instance

ProbabilityFunction(GeomRV, Pi);  # something non null


To ivercome this problem I defined a new Geometric distribution this way (not entirely satisfying):

restart:
with(Statistics):

GeomRV := RandomVariable(Geometric(1/2)):
f := unapply(ProbabilityFunction(GeomRV, n), n):
g := n -> (1-ceil(n-floor(n)))*f(n)    # (1-ceil(n-floor(n))) = 1 if n in Z, 0 otherwise

AnotherGeomRV := Distribution(
      'ProbabilityFunction'=g,
      'Support'=0..infinity,
      'DiscreteValueMap'=(n->n),  # is wanted
      'Type'=discrete
):
ProbabilityFunction(AnotherGeomRV, 2);
                 1/8
ProbabilityFunction(AnotherGeomRV, Pi);
                  0

PS: None of the statistics based upon the  ProbabilityFunction (Mean, Variance, ... ) is correctly computed with the previous construction. This could be easily overcome by completing this definition, just as its done in Maple, for all the requires statistics, for instance 

AnotherGeomRV := Distribution(
      ....
      'Mean'=1   # or more generally (1-p)/p form Geometric(p)
):


Suggestion 2: modify the way discrete distributions are defined in Maple in order to avoid ProbabilityFunction to return wrong values.

Equation labels are great!

I use them extensively to produce textbook style documentation that is understandable for non-Maple users. Even if Maple input is not hidden, documents look much cleaner since auxiliary names and the assignment statement “:=” do not have to be used most of the time.

Suggestions to improve Maple 2021 equation label functionality (in order of preference):

  • In a text passage or Maple input: Double click on a label reference to open the insert label dialogue (crtl-L) in order to change the reference (instead of deleting the reference and inserting a new reference).
  • Right click on an equation label to hide it with the context menu. Or right click on the output and have a “show/hide label" option.
  • After a document is finished, input is hidden and before printout/export is produced: A function that hides/shows all labels that are not referenced in text passages.
  • A search function for equation labels in a document, or alternatively: a pallet simliar to the variable pallet to manage labels.
  • Labels inside a text passage that refer to executable math with toggled input. This would allow the definition of expressions inside a text passage and use them in subsequent calculations. Example for a text passage: “If we insert for the mass m=15 kg in equation (33), the frequency response looks as follows:" plot(subs(label_of(whatever has been attributed to m=15kg),(33)),plot_range). This would reduce redundant entries in the document and potential mismatch between text and calculation results.
  • Renaming of single labels (i.e. assigning an alias) either by right click on the label or by a pallet.
  • Labels for non-executable math inside a text passage for further use in other text passages or later insertion in executable math.

Comments:

  • There is another (not documented?) feature that is very handy: Double click on an equation label inserts the equation label at the cursor position. A nice time saver.
  • Only recently I found out that single equation labels can be hidden/removed using Format>Equation Labels>Selection. Since this option was always grayed out, I could not make sense out of it, because the text was not self-explanatory to me.  Instead of Format>Equation Labels>Selection a more self-explaining menu entry would be desirable. “show/hide selection” would already better describe the action behind the menu item. However, it is still not intuitive to select output in order to make equation labels disappear (that are by the way not highlighted in blue by the selection process when only a single output/execution group is selected). There are many reasons that could make a change to self-explaning menu items not that straight forward as it sounds. In this case a mouse-over is always helpful to get more explanations on a button or a menu item. Alternatively and probably better: It would be more straight forward to select or click onto labels to manipulate them. This of course only works for one label at the time, which in my case is the most common use case.
  • Equation labels are unique. They enable a work and documenting style that other math tools do not provide. If used consistently, they provide a new level of abstraction where explanatory text and computation can be combined in way that a mathematical interpreter (human or a smart machine) could proof results using only textbook style documents as input (e.g. pdf scans). At least, this is theoretically possible. However, I have noticed that many examples from users do not make use of equation labels. They are still pretty much done in a traditional programming style where loads of unnecessary variables are used. This is understandable since many people start mathematical problem solving with the aid of computers by programming. So new users to Maple use Maple pretty much the same way they were trained.
  • I am fully aware that there are many applications where equation labels are not the most efficient way of producing a result. But producing a result is different from documenting results or even documenting a mathematical proof.

 

The https://sites.google.com/view/aladjevbookssoft/home site contains free books in English and Russian along with software created under the guidance of the main author prof. V. Aladjev in such areas as general theory of statistics, theory of cellular automata, programming in Maple and Mathematica systems. Each book is archived, including its cover and book block in pdf format. The software with freeware license is designed for Maple and Mathematica.

Hello everyone,

There is a strange behaviour with code-edit. Namely, when hiding code-edit window and recovering it, sometimes Maple create a very narrow window. It is very hard to see the code that way. After a while the code-edit region window readjusts itself though. However it takes time.

Also another thing, it would be useful when searching in a worksheet, to have an option that allows to search in code-edit region also.

Best regards,

When this question was asked here earlier, I neglected to suggest or to emphasize two further items.  Now, on revising Mathematics for Chemistry with [Maple], I recognise that I should have included these two objectives for inclusion in Maple 2021.

- an extended and improved spreadsheet with symbolic capability; I suspect that Maple was the only software for symbolic computation to include such a facility, which sadly has become deprecated, for no obvious reason.

- a much extended capability to solve integral equations; publications dating from 1976 -- i.e. before Maple! -- have shown what is possible; Maple's capabilities for differential equations might still be superior, although the competition is becoming close, so further efforts in the development of both differential and integral equations are timely and appropriate.  Related to differential equations is naturally the extension of capabilities of special functions, both to extend present functions and to produce new functions, such as those of Lame.

We recently published a paper on multiscale-multidomain simulation of battery models.

https://iopscience.iop.org/article/10.1149/1945-7111/abb37b

Some challenges are listed at 

https://twitter.com/UT_MAPLE/status/1311356957941522438

Maple and symbolic math can play a critical role in solving many challenging problems. For example, consider a seemingly-trivial problem

uxx+uyy = 0

x = 0 and x = 1, ux = 0 for all y

y = 1, u = 0, for all x

y = 0, u =1, 0<=x<=0.5

y = 0, uy = 0, 0.5<x<=1

There is a singularity at (0.5,0) and most numerical methods will have trouble there. In these equations, uxx means the second derivative of u with respect to x.

Maple can help solve this problem with conformal mapping to achieve arbitrary precision. As of today, machine precision is not possible with any numerical method even with millions of Degrees of Freedom. The Maple code is given below. A FEM code is given below as well. Models like this can benefit from Maple adding parallel sparse direct and iterative solvers.


 

 

restart;

Digits:=15;

Digits := 15

(1)

 The domain is tranformed from Z = X+IY to w. The points tranformed are

Zdomain:=[[0,0],[1,0],[1,1],[0,1]];

Zdomain := [[0, 0], [1, 0], [1, 1], [0, 1]]

(2)

wdomain:=[0,1,1+a,a+2];

wdomain := [0, 1, 1+a, a+2]

(3)

eq1:=diff(Z(w),w)=-I*K1/sqrt(w)/sqrt(w-1)/sqrt(w-a-1)/sqrt(w-a-2);

eq1 := diff(Z(w), w) = -I*K1/(w^(1/2)*(w-1)^(1/2)*(w-a-1)^(1/2)*(w-a-2)^(1/2))

(4)

 a is not known apriori. The value of a should be found to make sure [1,1] in the Z coordinate is transformed to [1+a] in the w coordinate.

a:=sqrt(2)-1;

a := 2^(1/2)-1

(5)

 Value of K1 is found using the transformation of [1,0] to 1 in the w coordinate

eq11:=1=int(rhs(eq1),w=0..1);

eq11 := 1 = -K1*2^(1/2)*EllipticK(2^(1/2)/2)

(6)

K1:=solve(eq11,K1);

K1 := -(1/2)*(2^(1/2)/EllipticK(2^(1/2)/2))

(7)

 The height Y in the Z coordinate is found by integrating from 1 to 1+a in the w coordinate.

simplify(int(rhs(eq1),w=1..1+a));

(2*I)*2^(1/2)*EllipticK((2^(1/2)-1)/(2^(1/2)+1))/(EllipticK(2^(1/2)/2)*(2^(1/2)+1))

(8)

evalf(%);

1.00000000000000*I

(9)

 The choice of a = sqrt(2)-1 gives the height of 1 for Z coordinate.

eval(simplify(int(rhs(eq1),w=0..1+a)));

(2^(1/2)*EllipticK(2^(1/2)/2)+EllipticK(2^(1/2)/2)+(2*I)*2^(1/2)*EllipticK((2^(1/2)-1)/(2^(1/2)+1)))/(EllipticK(2^(1/2)/2)*(2^(1/2)+1))

(10)

evalf(%);

1.00000000000000+1.00000000000001*I

(11)

 integration from 0 to 1+a in the w coordinate gives 1,1 in the Z coordinate.

simplify(int(rhs(eq1),w=0..1/sqrt(2)));

EllipticF(2^(1/2)/(2+2^(1/2))^(1/2), 2^(1/2)/2)/EllipticK(2^(1/2)/2)

(12)

evalf(%);

.500000000000001

(13)

 Integrating w from 0 to wmid =1/sqrt(2) gives the point 0.5,0 in the Z coordinate

wmid:=1/sqrt(2);

wmid := 2^(1/2)/2

(14)

 Next w domain is transformed to Z2 domain Z2 = X2+IY2

Z2domain:=[[0,0],[1,0],[1,H],[0,H]];

Z2domain := [[0, 0], [1, 0], [1, H], [0, H]]

(15)

wdomain2:=[0,1/sqrt(2),1+a,a+2];

wdomain2 := [0, 2^(1/2)/2, 2^(1/2), 2^(1/2)+1]

(16)

eq2:=diff(Z2(w),w)=-I*K2/sqrt(w)/sqrt(w-wmid)/sqrt(w-1-a)/sqrt(w-a-2);

eq2 := diff(Z2(w), w) = -(2*I)*K2/(w^(1/2)*(4*w-2*2^(1/2))^(1/2)*(w-2^(1/2))^(1/2)*(w-2^(1/2)-1)^(1/2))

(17)

 K2 is found based on the transformation of wmid to [1,0] in Z2 coordinate.

eq21:=1=int(rhs(eq2),w=0..wmid);

eq21 := 1 = -2*K2*EllipticK(1/(((2+2^(1/2))^(1/2))))/(2^(1/2)+1)^(1/2)

(18)

K2:=solve(eq21,K2);

K2 := -(1/2)*((2^(1/2)+1)^(1/2)/EllipticK(1/(((2+2^(1/2))^(1/2)))))

(19)

 The corner 0,1 in the Z coordinate is mapped by integrating eq2 from 0 to 1 in the w coordinate

 

 

int(rhs(eq2),w=0..1);

1+EllipticF((2-2^(1/2))^(1/2), ((2^(1/2)+1)/(2+2^(1/2)))^(1/2))*I/EllipticK(1/(((2+2^(1/2))^(1/2))))

(20)

corner:=evalf(%);

corner := 1.+.559419351518322*I

(21)

 This is the point 1,0 in the original coordinate.

 The height in the Z2 coorinate is found by integrating eq2 from wmid to 1+a.

ytot:=int(rhs(eq2),w=wmid..1+a);

ytot := EllipticK(((2^(1/2)+1)/(2+2^(1/2)))^(1/2))*I/EllipticK(1/(((2+2^(1/2))^(1/2))))

(22)

evalf(%);

1.22004159128347*I

(23)

 The magnitude in the Y direction is given by the coefficient of I, the imaginary number

Ytot:=coeff(ytot,I);

Ytot := EllipticK(((2^(1/2)+1)/(2+2^(1/2)))^(1/2))/EllipticK(1/(((2+2^(1/2))^(1/2))))

(24)

 The analytial solution in the Z2 corordinate is a line in Y2 to satisfy simple zero flux conditions at X2 = 0 and X2 = 1.

phianal:=1+b*Y2;

phianal := 1+b*Y2

(25)

 The value of phi is zero at Y2 = Ytot (originally the cathode domain in the Z domain)

bc:=subs(Y2=Ytot,phianal)=0;

bc := 1+b*EllipticK(((2^(1/2)+1)/(2+2^(1/2)))^(1/2))/EllipticK(1/(((2+2^(1/2))^(1/2)))) = 0

(26)

b:=solve(bc,b);

b := -EllipticK(1/(((2+2^(1/2))^(1/2))))/EllipticK(((2^(1/2)+1)/(2+2^(1/2)))^(1/2))

(27)

 The analytical solution is given by

phianal;

1-EllipticK(1/(((2+2^(1/2))^(1/2))))*Y2/EllipticK(((2^(1/2)+1)/(2+2^(1/2)))^(1/2))

(28)

evalf(phianal);

1.-.819644188480505*Y2

(29)

 The potential at the corner is given by substituting the imaginary value of corner for Y2 in phinanal)

phicorner:=subs(Y2=Im(corner),phianal);

phicorner := 1-.559419351518322*EllipticK(1/(((2+2^(1/2))^(1/2))))/EllipticK(((2^(1/2)+1)/(2+2^(1/2)))^(1/2))

(30)

evalf(phicorner);

.541475179604475

(31)

local flux/current density calculation, written in terms of w is

curr:=b*rhs(eq2)/rhs(eq1);

curr := -(2^(1/2)+1)^(1/2)*2^(1/2)*EllipticK(2^(1/2)/2)*(w-1)^(1/2)/(EllipticK(((2^(1/2)+1)/(2+2^(1/2)))^(1/2))*(4*w-2*2^(1/2))^(1/2))

(32)

average flux/current density calculation for the anode

currave:=int((curr),w=0..wmid)/wmid;

currave := -(1/2)*((2^(1/2)+1)^(1/2)*(2^(1/2)-1)*EllipticK(2^(1/2)/2)*(2^(3/4)+2^(1/4)+arctanh(2^(3/4)/2))*2^(1/2)/EllipticK(2^(3/4)/2))

(33)

Digits:=25:

 The average current density at Y =0, local current density at X = 0,Y=0 and potential at X=1,Y=0 (Corner) can be used to study convergence of FEM and other numerical methods

evalf(currave),evalf(subs(w=0,curr)),evalf(phicorner);

-1.656507648777793388522396, -1.161311530233258689567781, .5414751796044734741869534

(34)

 


 

Download Conformalmapping.mws


 

This FEM code is for solving Laplace's equation with primary current distribution considered in Model 1.
This code is based on FEM weak-form. Biquadratic Lagrange shape functions (9nodes in an element) are used.

restart;

with(LinearAlgebra):

Lx:=1: #length in X

Ly:=1: #length in Y

nx:=10: #number of elements in X (even numbers only)

ny:=10: #number of elements in Y, to be kept same as nx in this version

hx:=Lx/nx: #element size x

hy:=Ly/ny: #element size y

Procedure to perform numerical integration on shape functions to obtain local matrices (can be replaced with analytical integration for this particular problem)
  -Shape functions are also used as weight functions in applying weak formulation. Numerical integration is done using Simpson's rule.
  -Local cartesian coordinates x,y are converted to natural coordinates zeta and eta. This transformation is not required for this simple geomerty but useful in general. zeta and eta are obtained by scaling x and y with hx/2 and hy/2, respectively, in this code.

 

localmatrices:=proc(a1,a2,a3,b1,b2,b3,q1,q2)
global Kx,Ky,Nx,Ny,zeta,eta,c;
local A,dAdzeta,dAdeta,y,x,J,terms,i,j,k,l,dx,dy,fx,fy,fxy,fyy,dzeta,deta,J1,J2;

A:=[(1-zeta)*zeta*(1-eta)*eta/4,-(1-(zeta)^2)*(1-eta)*eta/2,-(1+zeta)*zeta*(1-eta)*eta/4,(1-(eta)^2)*(1+zeta)*zeta/2,(1+zeta)*zeta*(1+eta)*eta/4,(1-(zeta)^2)*(1+eta)*eta/2,-(1-zeta)*zeta*(1+eta)*eta/4,-(1-(eta)^2)*(1-zeta)*(zeta)/2,(1-(zeta)^2)*(1-(eta)^2)]; #bi quadratic langrange shape functions

dAdzeta:=diff(A,zeta);

dAdeta:=diff(A,eta);

y:=[-a1,-a2,-a3,0,a3,a2,a1,0,0];x:=[-b1,0,b1,b2,b3,0,-b3,-b2,0];

J:=simplify(add(dAdzeta[i]*x[i],i=1..9)*add(dAdeta[i]*y[i],i=1..9)-add(dAdzeta[i]*y[i],i=1..9)*add(dAdeta[i]*x[i],i=1..9));

Nx:=[seq((simplify(add(dAdeta[i]*y[i],i=1..9))*dAdzeta[j]-simplify(add(dAdzeta[i]*y[i],i=1..9))*dAdeta[j])/simplify(J),j=1..9)];

Ny:=[seq((-dAdzeta[j]*simplify(add(dAdeta[i]*x[i],i=1..9))+dAdeta[j]*simplify(add(dAdzeta[i]*x[i],i=1..9)))/simplify(J),j=1..9)];

Kx:=Matrix(nops(A),nops(A),datatype=float[8]):

Ky:=Matrix(nops(A),nops(A),datatype=float[8]):
c:=Vector(nops(A),datatype=float[8]):

terms:=20:#number of terms for numerical integration
dzeta:=2/terms:
deta:=2/terms:

for i from 1 to nops(Nx) do #loop to obtain local matrices      

for j from 1 to nops(Ny) do
Kx[i,j]:=0;
Ky[i,j]:=0;

for k from 0 to terms do #outer loop double integration, integration in zeta

if k = 0 then fx[k]:= subs(zeta=-1,Nx[i]*Nx[j]*J); fy[k]:= subs(zeta=-1,Ny[i]*Ny[j]*J);  
elif k = terms then
fx[k]:= subs(zeta=-1+(k*dzeta),Nx[i]*Nx[j]*J);
fy[k]:= subs(zeta=-1+(k*dzeta),Ny[i]*Ny[j]*J);  
elif irem(k,2) = 0 then
fx[k]:= 2*subs(zeta=-1+(k*dzeta),Nx[i]*Nx[j]*J);
fy[k]:=     2*subs(zeta=-1+(k*dzeta),Ny[i]*Ny[j]*J);
else fx[k]:= 4*subs(zeta=-1+(k*dzeta),Nx[i]*Nx[j]*J);
fy[k]:=     4*subs(zeta=-1+(k*dzeta),Ny[i]*Ny[j]*J);  end if;

for l from 0 to terms do #inner loop double integration, integration in eta

if l = 0 then fxy[l]:= subs(eta=-1,fx[k]); fyy[l]:= subs(eta=-1,fy[k]);
elif l = terms then fxy[l]:= subs(eta=-1+(l*deta),fx[k]); fyy[l]:= subs(eta=-1+(l*deta),fy[k]);
elif irem(l,2) = 0 then fxy[l]:= 2*subs(eta=-1+(l*deta),fx[k]); fyy[l]:= 2*subs(eta=-1+(l*deta),fy[k]);
else fxy[l]:=4*subs(eta=-1+(l*deta),fx[k]); fyy[l]:=4*subs(eta=-1+(l*deta),fy[k]); end if;
Kx[i,j]:=Kx[i,j]+fxy[l];
Ky[i,j]:=Ky[i,j]+fyy[l];

end do;
    
end do;
Kx[i,j]:=Kx[i,j]*dzeta*deta/9;
Ky[i,j]:=Ky[i,j]*dzeta*deta/9;
end do;
end do:

end proc:

n:=nx*ny; #total number of elements

n := 100

(1)

Nx1:=nx*2+1: #number of nodes in x in one row

N:=Nx1*(2*ny+1); # total number of nodes/equations

N := 441

(2)

K:=Matrix(N,N,storage=sparse): # global K matrix

C:=Vector(N,storage=sparse): # global c matrix

L2G:=Matrix(n,9):  #mapping matrix - each row has node numbers for each element

l:=1:k:=1:
localmatrices(hy/2,hy/2,hy/2,hx/2,hx/2,hx/2,0,0): kx:=copy(Kx):ky:=copy(Ky):c0:=copy(c):

for i from 1 to n do #modifying,adding and assembling matrices to get global matrix
 
if i<=nx/2 then  
a1:=copy(kx); a2:=copy(ky); a3:=0; a1[1..3,1..9]:=IdentityMatrix(3,9); a2[1..3,1..9]:=Matrix(3,9,shape=zero); a4:=a1+a2; c:=copy(c0); c[1..3]:=1.0;

elif i=nx/2+1 then  a1:=copy(kx); a2:=copy(ky); a3:=0; a1[1,1..9]:=IdentityMatrix(1,9); a2[1,1..9]:=Matrix(1,9,shape=zero); a4:=a1+a2; c:=copy(c0); c[1]:=1.0;

elif i>nx*(ny-1) then a1:=copy(kx); a2:=copy(ky); a3:=0; a1[5..7,5..7]:=IdentityMatrix(3,3);
a1[5..7,1..4]:=ZeroMatrix(3,4);
a1[5..7,8..9]:=ZeroMatrix(3,2); a2[5..7,1..9]:=Matrix(3,9,shape=zero); a4:=a1+a2; c:=copy(c0); c[5..7]:=0;

else a1:=kx; a2:=ky; a3:=0;a4:=a1+a2; c:=c0;  end if;

L2G[i,1..9]:=Matrix([l,l+1,l+2,l+2+Nx1,l+2+Nx1*2,l+1+Nx1*2,l+Nx1*2,l+Nx1,l+1+Nx1]):

k:=k+1:
 
if k>nx then k:=1; l:=l+Nx1+3;

else l:=l+2; end if:

indx2:=L2G[i,1..9]:
indx2:=convert(indx2,list):

C[indx2]:=C[indx2]+c[1..9];
c[1..9];

for i1 from 1 to 9 do
indx1:=L2G[i,i1]:
K[indx1,indx2]:=K[indx1,indx2]+a4[i1,1..9]:
end do:

end do:

phi:=LinearSolve(K,C,method=SparseLU): #linear set of equations solved using Sparse LU solver

phi_at(1,0):=phi[Nx1];
 

phi_at(1, 0) := .546587799122513

(3)

dNdy:=copy(Ny):

dNdy_bottom_left:=subs(eta=-1,zeta=-1,dNdy):

current_at(0,0):=add(dNdy_bottom_left[i]*phi[L2G[1,i]],i=1..nops(Ny));

current_at(0, 0) := -1.15773815354626

(4)

if irem(nx/2,2)=0
then current_at(0,0.25):=add(dNdy_bottom_left[i]*phi[L2G[nx/4+1,i]],i=1..nops(Ny));
else
dNdy_bottom_center:=subs(eta=-1,zeta=0,dNdy):
current_at(0,0.25):=add(dNdy_bottom_center[i]*phi[L2G[(nx/2+1)/2,i]],i=1..nops(Ny));
end if;

dNdy_bottom_center := [0, -30, 0, 0, 0, -10, 0, 0, 40]

current_at(0, .25) := -1.26989097821724

(5)

 

 


 

Download FEM_2D.mws

What are the things you most like to see improved/add to next version of Maple? 

This is my list for a starter:

1.  Improve the debugger. Debugger is very useful but needs more work. At least be able to see code listing in larger view as one steps in for example. See Matlab debugger for inspiration.

2.  Improve Latex. It still does not do fractions well. Posted about this before.

3. Eliminate hangs when using timelimit(). On long runs, random hangs happen when timelimit() do not expire as requested. Posted about this before.

 

 

I don't stand by all I said here, so I'm deleting. I think there was valid criticism to be made, but I didn't make it any valid way.

Hello all ,

It's been years and years that I have been using Maple (since Maple V.2 in 1992 if my memory is still

correct. Now we are at Maple 2020 and the brilliant scientific library GMP is still in Maple at version

5.1.1.

kernelopts(gmpversion);
                            "5.1.1"

The relatively new GMP is 6.2.0 : https://gmplib.org/

I wonder if in a not too far version of Maple we could have GMP updated. It is really an impressive mathematical library alongside with GSL.

Voilà !

 

Kind regards to all,

 

Jean-Michel

 

Hi, 

This is more of an open discussion than a real question. Maybe it would gain to be displaced in the post section?

Working with discrete random variables I found several inconsistencies or errors.
In no particular order: 

  • The support of a discrete RV is not defined correctly (a real range instead of a countable set)
  • The plot of the probability function (which, in my opinion, would gain to be renamed "Probability Mass Function, see https://en.wikipedia.org/wiki/Probability_mass_function) is not correct.
  • The  ProbabiliytFunction of a discrte rv of EmpiricalDistribution can be computed at any point, but its formal expression doesn't exist (or at least is not accessible).
  • Defining the discrete rv "toss of a fair dice"  with EmpiricalDistribution and DiscreteUniform gives different results.


The details are given in the attached file and I do hope that the companion text is clear enough to point the issues.
I believe there is no major issues here, but that Maple suffers of some lack of consistencies in the treatment of discrete (at least some) rvs. Nothing that could easily be fixed.


As I said above, if some think this question has no place here and ought to me moved to the post section, please feel free to do it.

Thanks for your attention.


 

restart:

with(Statistics):


Two alternate ways to define a discrete random variable on a finite set
of equally likely outcomes.

Universe    := [$1..6]:
toss_1_dice := RandomVariable(EmpiricalDistribution(Universe));
TOSS_1_DICE := RandomVariable(DiscreteUniform(1, 6));

_R

 

_R0

(1)


Let's look to the ProbabilityFunction of each RV

ProbabilityFunction(toss_1_dice, x);
ProbabilityFunction(TOSS_1_DICE, x);

"_ProbabilityFunction[Typesetting:-mi("x",italic = "true",mathvariant = "italic")]"

 

piecewise(x < 1, 0, x <= 6, 1/6, 6 < x, 0)

(2)


It looks like the procedure ProbabilityFunction is not an attribute of RV with EmpiticalDistribution.
Let's verify

law := [attributes(toss_1_dice)][3]:
lprint(exports(law))

Conditions, ParentName, Parameters, CDF, DiscreteValueMap, Mean, Median, Mode, ProbabilityFunction, Quantile, Specialize, Support, RandomSample, RandomVariate

 


Clearly ProbabilityFunction is an attribute of toss_1_dice.

In fact it appears the explanation of the difference of behaviours relies upon different definitions
of the set of outcomes of toss_1_dice and TOSS_1_DICE

LAW := [attributes(TOSS_1_DICE)][3]:
exports(LAW):

law:-Conditions;
LAW:-Conditions;

[(Vector(6, {(1) = 1, (2) = 2, (3) = 3, (4) = 4, (5) = 5, (6) = 6}))::rtable]

 

[1 < 6]

(3)


From :-Conditions one can see that toss_1_dice is realy a discrete RV defined on a countable set of outcomes,
but that nothing is said about the set over which TOSS_1_DICE is defined.

The truly discrete definition of toss_1_dice is confirmed here :
(the second result is correct

ProbabilityFinction(toss_1_dice, x) = {0 if x < 1, 0 if x > 6, 1/6 if x::integer, 0 otherwise

ProbabilityFunction~(toss_1_dice, Universe);
ProbabilityFunction~(toss_1_dice, [seq(0..7, 1/2)]);

[1/6, 1/6, 1/6, 1/6, 1/6, 1/6]

 

[0, 0, 1/6, 0, 1/6, 0, 1/6, 0, 1/6, 0, 1/6, 0, 1/6, 0, 0]

(4)


One can also see that the Support of both of these RVs are wrong

(see for instance https://en.wikipedia.org/wiki/Discrete_uniform_distribution)

There should be {1, 2, 3, 4, 5, 6}, not a RealRange.

Support(toss_1_dice);
Support(TOSS_1_DICE);

RealRange(1, 6)

 

RealRange(1, 6)

(5)

 

0

 

{1, 2, 3, 4, 5, 6}

 

 


Now this is the surprising ProbabilityFunction of TOSS_1_DICE.
This obviously wrong result probably linked to the weak definition of the conditions for this RB.

# plot(ProbabilityFunction(TOSS_1_DICE, x), x=0..7);
plot(ProbabilityFunction(TOSS_1_DICE, x), x=0..7, discont=true)

 


These differences of treatments raise a lot of questions :
    -  Why is a DiscreteUniform RV not defined on a countable set?
    -  Why does the ProbabilityFunction of an EmpiricalDistribution return no result
        if its second parameter is not set to one  its outcomes.

 All this without even mentioning the wrong plot shown above.
 

I believe something which would work like the module below would be much better than what is done

right now

 

EmpiricalRV := module()
export MassDensityFunction, PlotMassDensityFunction, Support:

MassDensityFunction := proc(rv, x)
  local u, v, N:
  u := [attributes(rv)][3]:
  if u:-ParentName = EmpiricalDistribution then
    v := op([1, 1], u:-Conditions);
    N := numelems(v):
    return piecewise(op(op~([seq([x=v[n], 1/N], n=1..N)])), 0)
  else
    error "The random variable does not have an EmpiricalDistribution"
  end if
end proc:

PlotMassDensityFunction := proc(rv, x1, x2)
  local u, v, a, b:
  u := [attributes(rv)][3]:
  if u:-ParentName = EmpiricalDistribution then
    v := op([1, 1], u:-Conditions);
    a := select[flatten](`>=`, v, x1);
    b := select[flatten](`<=`, a, x2);
    PLOT(seq(CURVES([[n, 0], [n, 1/numelems(v)]], COLOR(RGB, 0, 0, 1), THICKNESS(3)), n in b), VIEW(x1..x2, default))
  else
    error "The random variable does not have an EmpiricalDistribution"
  end if
end proc:

Support := proc(rv, x1, x2)
  local u, v, a, b:
  u := [attributes(rv)][3]:
  if u:-ParentName = EmpiricalDistribution then
    v := op([1, 1], u:-Conditions);
    return {entries(v, nolist)}
  else
    error "The random variable does not have an EmpiricalDistribution"
  end if
end proc:

end module:
 

EmpiricalRV:-MassDensityFunction(toss_1_dice, x);
 

piecewise(x = 1, 1/6, x = 2, 1/6, x = 3, 1/6, x = 4, 1/6, x = 5, 1/6, x = 6, 1/6, 0)

(6)

f := unapply(EmpiricalRV:-MassDensityFunction(toss_1_dice, x), x):
f(2);
f(5/2);
 

1/6

 

0

(7)

EmpiricalRV:-PlotMassDensityFunction(toss_1_dice, 0, 7);

 

 


 

Download Discrete_RV.mw

 

 

I'm only just hearing (haven't experienced) about some serious issues with the 2019.2 updates.  I would recommend waiting for Maplesoft to release an emergency 2019.3 fix update - Maplesoft can NOT leave the last update of 2019 in this state.

I have noticed that there exists a Stack Exchange site for mathematica, and not for maple. My discussions with the part of Stack Exchange that handle the creation of a new Stack Exchange community have said that I must accrue a certain level of interest in the subject in order for it to be approved, and so I thought I would begin here to see if there is suffice level of interest.

This would not diminish the use of the Maple Primes forum, and an additional proposal, in consideration of the years of dedication that have gone into this domain, be to pool the data between the two, make reputation points the same on both, perhaps even user profiles and questions answered already linkable, and all of the questions already addressed here showing up in the search on both domains.

I am proposing this simply because I want to encourage the use of maple, and have noted that Stack Exchange is very popular. 

So I am posting this to get overall feedback from other Maple users, as to what their opinion is regarding this proposal, and advice on whether it should and how it ought to be pursued.

We are currently in the process of updating the support FAQs at https://faq.maplesoft.com. We’ve been working on updating the existing content for clarity, and have added several new articles already.

 

The majority of our FAQs are from questions people ask us in Technical Support at support@maplesoft.com, but we’d also like to like to add content from other sources.

Since we have such a great community here at MaplePrimes, we wanted to reach out and ask if there are any articles or questions that you'd like to see added to our FAQ.

 

We look forward to hearing your feedback!

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