Thomas Richard

Mr. Thomas Richard

2708 Reputation

12 Badges

12 years, 220 days
Maplesoft Europe GmbH
Technical professional in industry or government
Aachen, Germany

MaplePrimes Activity


These are answers submitted by Thomas Richard

Please see here, easy to find from the Documentation Center start page.

I have not checked all steps in detail, but I think the substitution you applied (via eval) is incomplete so that JacobiSN calls remain in the result, thus it's going to be large...

What about this modification?

Eq3J := eval(Eq2J, [JacobiCN(eta,omega) = x, JacobiSN(eta,omega) = sqrt(1-x^2)]):

By the way, the identity check succeeds after simplifying:

is(simplify(JacobiSN(z,k)^2 + JacobiCN(z,k)^2) = 1);

 

The error could be related to the new handling of integration constants. But you must have manipulated the output of dsolve further (the sign of the the second term seems wrong.) If you simply feed it into odetest, that check will succeed as always, independent of the Maple version.

You will need to insert multiplication symbols in sys (for all three multiplications). This is a common trap that 2D users can fall into. My suggestion is to always enter those symbols even when implicit multiplication may work.

You could try

expr := convert(expr,‘phaseamp‘,t);

which yields the most compact form. However, I doubt that it will help much with using the maximize command...

I didn't feel like pinpointing which assumptions are needed in which step, so I turned them into global ones:

restart:
assume(y::real,x>0);
eq:=sqrt(exp(y))=tanh(x);
                             /1  \          
                    eq := exp|- y| = tanh(x)
                             \2  /          

sol:=solve(eq,y);
Warning, solve may be ignoring assumptions on the input variables.
                      sol := 2 ln(tanh(x))

 

The last statement in your grey code block contains two syntax problems: the curly braces around ic1 need to be removed (there is no set involved here), and the multiplication symbol needs to be replaced by a comma, like this:

simplified_PDEL1 := eval(PDEL1,ic1);
sol := pdsolve(simplified_PDEL1); # assign the solution, for postprocessing
pdetest(sol,simplified_PDEL1); # optional check

And pdsolve should be used for PDEs; whereas dsolve is covering ODEs.

No, that number cannot be changed. The list is hard-coded, as you can see in the GUI settings (e.g. AppData\Roaming\Maple\<version>\Maple.ini in your home directory on Windows): FileMRU1 ... FileMRU10

... like this:

ode:=b%*(x+x^2)*diff(y(x),x$2)+x%*(2*a - 1)*diff(y(x),x)+c*y(x)=0;

If you want to expand later on, simply call value(L).

combine(simplify(expr));

BTW: I would not use the same variable for different representations - because it would confuse me...

It's probably best to contact support@maplesoft.com with some details of your system (hardware and software specs). Also attach your install log file for diagnostics.

A graphics driver update may be needed, as recommended in our FAQs.

The AMD processor as such is not a problem.

Writing to a file is somewhat "hidden" in the documentation (see ?CodeGeneration,General,CodeGenerationOptions or ?CodeGenerationOptions): use the output=string option where string is the filename:

mymapleproc := proc(...) end proc;
CodeGeneration:-C(mymapleproc, output="C:/Temp/mycproc.c");

This holds for all 12 target languages of CodeGeneration, not just C.

SetAttachment (which you found already in the MapleSim:-LinkModel API) should still work as usual.

If you are talking about the Global Optimization Toolbox, instructions can be found here in the Documentation Center.

Don't be mislead by the version number; the installation method has not changed in years. And e.g. GOT 2022 needs Maple 2022.

I don't know exactly what's going on here, but it seems that the inner integration result of -cos(theta)^2/4 is too simplistic.

If you insert

f := combine(f);

before integrating, then you get a piecewise expression, and the numerical integration results match.

If you insert

simplify(Maple, 'wronskian')

after the integration, you see that the non-Bessel expression is off by a factor of 1/2.

BTW: Thanks for bringing this problem to our attention. I have created an internal bug report. You can also submit reports via MaplePrimes directly; see the "More > Submit Software Change Request" menu.

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