A population  governed by the logistic equation with a constant rate of harvesting satisfies the initial value problem . This model is typically analyzed by setting the derivative equal to zero and finding the two equilibrium solutions . A sketch of solutions  for different values of a suggests that the larger equilibrium is stable; the smaller, unstable.

When a is less that the unstable equilibrium,  becomes zero at a time , and the population becomes extinct. If  is not interpreted as pertaining to a population, its graph exists beyond , and actually has a vertical asymptote between the two branches of its graph.

In the worksheet "Logistic Model with Harvesting", two questions are investigated, namely,

1. How does the location of this vertical asymptote depend on on a and h?
2. How does the extinction time , the time at which , depend on a and h?

To answer the second question, an explicit solution , readily provided by Maple, is set equal to zero and solved for . It turns out to be difficult both to graph the surface  and to obtain a contour map of the level sets of this function. Instead, we solve for  and obtain a graph of  with  as a slider-controlled parameter.

To answer the first question, the explicit solution, which has the form , exhibits its vertical asymptote when . Solving this equation for  gives the time at which the vertical asymptote is located, a function that is as difficult to graph as . Again the remedy is to solve for, and graph, , with  as a slider-controlled parameter.

Download the worksheet: Logistic_with_Harvesting.mw

Let us consider 

Student[Precalculus]:-LimitTutor(sqrt(x), x = 2);

One expects a nice illustration of the result sqrt(2). But instead of that one reads "f(x) approaches 1.41 as x approaches 2". This is simply clueless and forms a wrong understanding of limits. It should also be noticed that all the entries (left, 2-sided, and right) produce the same animation. The same issue with other limits I tried, e.g.

Student[Precalculus]:-LimitTutor(sqrt(x), x = 1);

. I think this command should be completely rewritten or excluded from Maple. 

A number of MaplePrimers have asked how one might use the section and subsections of a Maple worksheet to structure the source code of an extended Maple package.  The usual answer is that it cannot be done; a module-based Maple package must be assigned in a single input region in a worksheet.  A recommended alternative is to write the source in text files and use either command line tools or the Maple read command from a worksheet to assign the package.  Because the read command handles Maple preprocessor macros, specifically the $include macro, the source can be conveniently split into smaller files.

I prefer this file-based method for development because text files are generally more robust than Maple worksheets, can be edited with the user's preferred editor, can be put under version control, and can be searched and modified by standard Unix-based tools.  However, not everyone is familiar with this method of development.  With that in mind, I wrote a small Maple package, CodeBuilder, that permits splitting the source of a Maple package (or any Maple code) into separate code edit regions in a standard Maple worksheet, using $include macros to include the source of other regions.  To build the package, the code edit regions are written to external files, using the names of the regions as the local file name relative to a temporary directory.

The package includes a method to run mint on the source code.  The result can be either printed in the worksheet or displayed in a pop-up maplet that allows selecting the infolevel and the region to check.

CodeBuilder includes help pages and a simple example (referenced from the top-level help page) demonstrating the usage.  To install the package, unzip the attached zip file and follow the directions in the README file.

CodeBuilder-1-0-3.zip

Errata Just noticed that a last minute change broke some of the code.  Do not bother with the 1-0-1 version; I'll upload a new version shortly.  The latest version (1-0-3) is now available.

Let us look in RealDomain and then in the RealDomain:-solve command. One is addressed to the usual solve command. The commands of the RealDomain package are not still documented since Maple 7 when the package was introduced. There is a general description only 

• By default, Maple performs computations under the assumption that the underlying number system is the complex field. The RealDomain package provides an environment in which computations are performed under the assumption that the basic underlying number system is the field of real numbers.
• Results returned by procedures are postprocessed by discarding values containing any detectable non-real answers or replacing them with undefined where appropriate.

The above is not enough. Here is an example which confuses me: 

RealDomain:-solve(exp(I*x) = -1, AllSolutions);
NULL

though 

solve(exp(I*x) = -1, AllSolutions);
                         Pi (2 _Z1 + 1)

and 

RealDomain:-solve(exp(I*x) = -1);
                               Pi

I lie awake thinking about that. Maplesoft staff help me!

Let us consider 

Statistics:-Mode(Binomial(n, p));
                        floor((1 + n) p)

Up to Wiki, the output is not correct. Simply no words.

There seems to be a bug in determining the folowing integral analytically:

Maple gives as a result

However, numerically integrating it

gives

In fact, integrating it from a to b,

gives

suggesting that Maple thinks the integrand is just 3/2. If one plots it, then it becomes obvious that this is not the case.

There were recently submitted a dozen Maple bugs by me and others. Maplesoft have brought no responses. They keep strategic silence. True merit is not afraid of criticism.

Download Bug_in_Statistics_PDF.mw

Let us consider 

restart; J := int(cos(a*x)^2/(x^2-1), x = -infinity .. infinity, CPV);
-(1/4)*Pi*sin(2*a)*csgn(I*a)-(1/4)*Pi*sin(2*a)*csgn(I/a)

This result is not true for a=I:

eval(J, a = I);
                               0

In this case the integral under consideration diverges because of 

cos(I*x)^2;
                                
                            cosh(x) ^2

Let us consider 

maximize(int(exp(-x^4), x = k .. 3*k), location);

Error, (in maximize) invalid input: iscont expects its 1st argument, f, to be of type algebraic, but received x = k .. 3*k
whereas the expected output is 

[(2*((1/40)*GAMMA(1/4, (1/80)*ln(3))*5^(1/4)*ln(3)^(3/4)-(1/40)*GAMMA(1/4, (81/80)*ln(3))*5^(1/4)*ln(3)^(3/4)))*5^(3/4)*(1/ln(3))^(3/4), [k = (1/10)*10^(3/4)*ln(3)^(1/4)]]

as Mma 11 produces. The following 

RealDomain:-solve(diff(int(exp(-x^4), x = k .. 3*k), k));
  -(1/10)*5^(3/4)*ln(3)^(1/4), (1/10)*5^(3/4)*ln(3)^(1/4)

is not a workaround because of 

int(exp(-x^4), x = (1/10)*5^(3/4)*ln(3)^(1/4) .. (3/10)*5^(3/4)*ln(3)^(1/4));
  FAIL

Let us consider 

MultiSeries:-series(Psi((2*x+1)/(2*x))-Psi((x+1)/(2*x)), x = 0);

x-(1/2)*x^2+(1/4)*x^4-(1/2)*x^6 +O(x^7)

The above result contradicts 

MultiSeries:-limit(diff(Psi((2*x+1)/(2*x))-Psi((x+1)/(2*x)), x), x = 0);
                           undefined
MultiSeries:-limit((Psi((2*x+1)/(2*x))-Psi((x+1)/(2*x)))/x, x = 0, right);
                               1
MultiSeries:-limit((Psi((2*x+1)/(2*x))-Psi((x+1)/(2*x)))/x, x = 0, left);
                           undefined
plot((Psi((2*x+1)/(2*x))-Psi((x+1)/(2*x)))/x, x = -0.1e-1 .. 0.1e-2, discont, y = -5 .. 5);

restart; with(Statistics):
X := RandomVariable(Normal(0, 1)): Y := RandomVariable(Uniform(-2, 2)):
Probability(X*Y < 0);

crashes my comp in approximately 600 s. Mma produces 1/2 on my comp in 0.078125 s.

Let us consider

with(Statistics):
X1 := RandomVariable(Normal(0, 1)):
X2 := RandomVariable(Normal(0, 1)):
X3 := RandomVariable(Uniform(0, 1)): 
X4 := RandomVariable(Uniform(0, 1)):
Z := max(X1, X2, X3, X4); CDF(Z, t);

int((1/2)*(_t0*Heaviside(_t0-1)-_t0*Heaviside(_t0)-Heaviside(1-_t0)*Heaviside(-_t0)+Heaviside(-_t0)+Heaviside(1-_t0)-1)*(1+erf((1/2)*_t0*2^(1/2)))*(2^(1/2)*Heaviside(_t0-1)*exp(-(1/2)*_t0^2)*_t0-2^(1/2)*Heaviside(_t0)*exp(-(1/2)*_t0^2)*_t0-2^(1/2)*Heaviside(-_t0)*Heaviside(1-_t0)*exp(-(1/2)*_t0^2)-Pi^(1/2)*undefined*erf((1/2)*_t0*2^(1/2))*Dirac(_t0)-Pi^(1/2)*undefined*erf((1/2)*_t0*2^(1/2))*Dirac(_t0-1)+2^(1/2)*Heaviside(-_t0)*exp(-(1/2)*_t0^2)+2^(1/2)*Heaviside(1-_t0)*exp(-(1/2)*_t0^2)-Pi^(1/2)*undefined*Dirac(_t0)-Pi^(1/2)*undefined*Dirac(_t0-1)+Pi^(1/2)*Heaviside(_t0-1)*erf((1/2)*_t0*2^(1/2))-Pi^(1/2)*Heaviside(_t0)*erf((1/2)*_t0*2^(1/2))-exp(-(1/2)*_t0^2)*2^(1/2)+Pi^(1/2)*Heaviside(_t0-1)-Pi^(1/2)*Heaviside(_t0))/Pi^(1/2), _t0 = -infinity .. t)

whereas Mma 11 produces the correct piecewise expression (see that here screen15.11.16.docx).

Edit. Mma output.

Let us consider 

J := int(x^n/sqrt(1+x^n), x = 0 .. 1) assuming n > 0;

2*(2^(1/2)-hypergeom([1/2, 1/n], [(n+1)/n], -1))/(2+n)

limit(J,n=infinity);
FAIL
MultiSeries:-limit(J,n=infinity);
FAIL

Mma 11 finds the limit is zero. Hope one feels the difference.

limit((x^2-1)*sin(1/(x-1)), x = infinity, complex);
infinity-infinity*I
MultiSeries:-limit((x^2-1)*sin(1/(x-1)), x = infinity, complex);
infinity

whereas the same outputs are expected. The help http://www.maplesoft.com/support/help/Maple/view.aspx?path=infinity&term=infinity does not shed light on the problem. Here are few pearls:

• infinity is used to denote a mathematical infinity, and hence it is usually used as a symbol by itself or as -infinity.
• The quantities infinity, -infinity, infinity*I, -infinity*I, infinity + y*I, -infinity + y*I, x + infinity*I and x - infinity*I, where x and y are finite, are all considered to be distinct in Maple. However, all 2-component complex numerics in which both components are infinity are considered to be the same (representing the single point at the "north pole" of the Riemann sphere).
• The type cx_infinity can be used to recognize this "north pole" infinity.

This MaplePrimes guest blog post is from Dr. James Smith, an Assistant Lecturer in the Electrical Engineering and Computer Science Department of York University’s Lassonde School of Engineering. His team has been working with Maplesim to improve the design of assistive devices.

As we go through our everyday lives, we rarely give much thought to the complex motions and movements our bodies go through on a regular basis. Motions and movements that seem so simple on the surface require more strength and coordination to execute than we realize. And these are made far more difficult as we age or when our health is in decline. So what can be done to assist us with these functions?

In recent years, my research team and I have been working on developing more practical and streamlined devices to assist humans with everyday movements, such as standing and sitting. Our objective was to determine if energy could be regenerated in prosthetic devices during these movements, similar to the way in which hybrid electric vehicles recover waste heat from braking and convert it into useable energy.

People use – and potentially generate – more energy than they realize in carrying out common, everyday movements. Our research for this project focused on the leg joints, and investigated which of the three joints (ankle, knee or hip) was able to regenerate the most energy throughout a sitting or standing motion. We were confident that determining this would lead to the development of more efficient locomotive devices for people suffering from diseases or disabilities affecting the muscles around these joints.

In order to identify the point at which regenerative power is at its peak, we determined that MapleSim was the best tool to help us gather the desired data. We took biomechanical data from actual human trials and applied them to a robotic model that mimics human movements when transitioning between sitting and standing positions. We created models to measure unique movements and energy consumption at each joint throughout the identified movements to determine where the greatest regeneration occurred.

To successfully carry out our research, it was essential that we were able to model the complex chemical reactions that occur within the battery needed to power the assistive device. It is a challenge finding this feature in many engineering software programs and MapleSim’s battery modeling library saved our team a great deal of time and effort during the process, as we were able to use an existing MapleSim model and simply make adjustments to fit our project.

Using MapleSim, we developed a simplified model of the human leg with a foot firmly planted on the ground, followed by a more complex model with a realistic human foot that could be raised off the ground. The first model was used to create a simplified model-based motion controller that was then applied to the second model. The human trials we conducted produced the necessary data for input into a multi-domain MapleSim model that was used to accurately simulate the necessary motions to properly analyze battery autonomy.

The findings that resulted from our research have useful and substantial applications for prostheses and orthoses designs. If one is able to determine the most efficient battery autonomy, operation of these assistive devices can be prolonged, and smaller, lighter batteries can be used to power them. Ultimately, our simulations and the resulting data create the possibility of more efficient devices that can reduce joint loads during standing to sitting processes, and vice versa.