By default, Maple carries 10 decimal digits through its floating-point computations. That's not enough to accurately evaluate f(31536000.).  You can change the number of digits of precision with

Digits:= 15;

for example.

From what I've been able to find out from some very cursory web searches, Mathematica uses "machine precision" by default. This corresponds to about 17 decimal digits (53 bits, to be precise). You can get Maple to use machine precision by setting

UseHardwareFloats:= true;

Maple has no practical limit on the number of Digits you can use. I believe that's true for Mathematica also.

From what I've been able to find out from very cursory web searches, the HP Prime uses and is limited to 12 digits, and the TI Nspire uses 10 by default and is limited to 14.

No matter what system you use or what digits setting you use, you will always be able to find some number for which this computation has significantly fewer accurate digits than you asked for. Indeed, it'll always be possible to find a large number x such that f(x) = 1.

*All information about Mathematica, TI, and HP is based on very quick ad hoc web searches. Please don't quote me on those.

To show that Maple knows the other half of the Fundamental Theorem of Calculus, I'd do

Diff(Int(f(t), t= a..x), x):  % = value(%);

If you want Q on the vertical axis versus B on the horizontal axis, then do

plot([B, Q, Q= 1..5], labels= ['B', 'Q']);

That should be

derivative:= D(f);

Maple can verify the identities that you gave, but you need to enter them with the correct syntax. This syntax is somewhat different from (and more precise than) the syntax used in your textbook. The rules include the following:

• All letters are lowercase.
• Function arguments always go in parentheses.
• Exponents go after the closing parenthesis.
• Explicit multiplication operators should be used.

Here are your two examples:

combine(cos(5*x)^2 - sin(5*x)^2);

     cos(10*x)

expand(tan(3*x));

     (3*tan(x)-tan(x)^3)/(1-3*tan(x)^2)

So what are combine and expand? The combine command tends to reduce the exponents and raise the coefficients of the arguments. The expand command tends to reduce the coefficients of the arguments and raise the exponents.

Use fsolve to solve your equation. I would've done it, but I'm not going to retype your expression. So, next time, post the expression in plaintext or post it as a worksheet with a link.

Your Question is about Maple and not about Maple TA, MapleSim, etc. Do not check off all the boxes next time; it's disrespectful.

Your optimization problem can be solved in the following sense. There are real nonnegative values of A and B such that your objective function is real. We will minimize it over those values of A and B.

theta:= Complex(1,1):
z:= theta^3-3*(A*theta^2+B):
S1:= solve({evalc(Im(z)) = 0});

     S1 := {A = 1/3}

eval(z, S1);

     -3*B-2

Now it is clear that this expression has no lower bound for nonnegative B. So the answer is -infinity.

Using the package LargeExpressions, I was able to simplify your expression to one that fits as a single long line on my monitor, using the normal font size. It won't fit on one line in this MaplePrimes post, but that's irrelevant.

As John has shown, the first step is to select the nontrivial branch of the piecewise. A clean way to do this (I consider using op to do this "dirty") is to add t >= theta to the integral's assuming clause. (I also removed nu > 0 because it's superfluous since it's implied by the limits of integration.)

Then I used LargeExpressions:-Veil to rename each LaguerreL subexpression.

Download LargeExpressions.mw

Your integral seems closely related to my current research, which involves simplifying integrals involving distributions and re-expressing them as other distributions*. Did you expect this integral to be another distribution? If so, I'd like to include it as an example in my research.

*Specifically, I'm making a Maple program, which, hopefully, will automatically perform most or all of the transformations in this famous chart.

Simply add option explicit to the solve command.

You need to use the correct Maple derivative and function syntax. Dependent variables either need to be declared or always used with their independent variables.

Download Deriv_syntax.mw

Add these options to the dsolve command:

method= bvp[midrich], maxmesh= 2^14

Also, here's an easier and much-more-accurate way to get your integral: Add the following ODE and BC to your system that you pass to dsolve:

diff(J(y), y)= E*diff(a(y), y),  J(-h/2) = 0

Then the integral is

1/2/(1+nu)*eval(J(y), aa(h/2));

and you can do away with the for loop and the PolynomialInterpolation.

If it's possible to solve at all, then I think that the following will do it:

P:= v-> cos(v)^2 + sin(v)^2 - 1:
V:= [Psi, Theta[1], Theta[2]](t):
U:= [(cos,sin)~(V)[], [x[1], x[2], z[1], z[2]](t)[]]:
thaw([eliminate(subs(U=~ freeze~(U), [[eqsys[], P~(V)[]], U])[])]);

This treats the sin and cos of Psi, Theta[1], and Theta[2] as separate variables and adds three equations based on the Pythagorean identity. So the system becomes a quadratic system of 10 equations in 10 variables. I let this run for over an hour and consume 5 Gig of memory, but I didn't have the patience to let it finish. I suggest replacing several of the parameters with small integers and trying again.

I used your ListParameters to set all parameters to 1, and I got no solution. So I think that there's a good chance that there's no solution.

There is a difference in the way Matrices evaluate between your Maple 15 and the current Maple 2016. I don't know the precise details, but you need to add something to VV's command in order for it to work in your Maple. Change

C[p0]:= eval(C[iso], const);

to

C[p0]:= eval(rtable_eval(C[iso]), const);

I have verified that

• the command that VV gave works in Maple 2016. That is, it produces a fully evaluated numeric Matrix;
• VV's command by itself doesn't work in Maple 16;
• and the modified command that I gave works in Maple 16.

It's very difficult for me to describe to you what exactly rtable_eval does. It's a bit mind boggling.

You wrote:

The resulotion of plot is not so good, and when I export this plot as jpeg file, quality of resolution deteriotate even more, I mean pixel tear out on zooming the image. How I fix this issue which I guess might be due to wrong way of exporting plot ?

JPEG is not a good format for most plots. JPEG is intended for photos (the P in JPEG stands for Photographic), which have continuous color changes. Plots tend to have crisp, abrupt, discontinuous color changes, especially in the transition from foreground to background. The "pixels tearing out" is JPEG's attempt to convert those abrupt changes into continuous ones.

On the other hand, the G in both PNG and GIF stands for Graphics. These are better than JPEG for most plots.

You had many syntax errors---too many for me to list right now---and your procedure CreaF would've been very inefficient if it had worked. Here's a better way:

f:= (x,y,i,j)-> ((x+j-1)/2^i, (y+2^i-j-1)/2^i):
CreaF:= (i::posint)-> unapply(Vector(2^i-1, j-> f(x,y,i,j)), (x,y)):

And call it like this:

CreaF(2)(.35,.465)[1];

     0.875000000000000e-1, .616250000000000

Note that I changed the call order from your CreaF(2)[1](.35,.465) because I thought that that would generally be more efficient. In other words, CreaF now returns a procedure which returns a Vector as opposed to CreaF returning a Vector of procedures. If you need it to be the latter way, let me know.