ecterrab

8483 Reputation

20 Badges

15 years, 79 days

MaplePrimes Activity


These are answers submitted by ecterrab

It is probably related to the large number of changes happening at this point. I am adding a test for this example.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Nice to see someone playing with the symgen routines; there are, for me, several beautiful ideas behind this code. This is my first work in differential equations, done in 1995 with Luiz Duarte and Luis da Mota in Brasil. On to the problem, the core idea in the symgen routines, that surprised several for their efficacy, is that we map differential equations into an algebraic problem for which, frequently, solutions exist that are computable without solving any differential equation. You realize the gain this represents. On the other hand, it is not the case that such solutions always exist.

Take your ODE

You see, the solution is easy to compute BUT requires solving differential equations and so are out of the scope of symgen. That is why DEtools:-symgen(ode, HINT = [f(x), g(x)*y]) doesn't succeed in this example. An important consideration is that, at the time the symgen routines were written, the capabilities of Maple's dsolve were rudimentary. Mapping an ODE into a problem that required solving differential equations was just of no use. It was actually the presentation of symgen that changed the game, triggering a full rewriting of Maple's dsolve in 1997, now using the symgen routines at its core.

Years later I wrote the symmetry routines of PDEtools, a package also originally written in 1995 in Brasil, with Katherina von Bulow . Basically all the symmetry commands in (O)DEtools have an equivalent in PDEtools. For symgen, the equivalent is Infinitesimals. At the time of writing it, however, Maple's dsolve was already a powerful command, so I coded Infinitesimals such that it tackles the problem for the infinitesimals as a differential equations problem. That is why PDEtools:-Infinitesimals(ode, HINT = [f(x), g(x)*y]) succeeds in this case.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

In particular, dsolve(equation, useint) will request dsolve to try to compute the integrals, regardless of their complexity or the result potentially be a wallpaper. Analogously, the useInt option requests not to attempt computing any integral. The output is a solution in terms of integrals. The call dsolve(equation) - neither useint nor useInt around - uses an internal algorithm that will attempt computing the integral most of the times but not always, and also discard wallpaper integrations preferring the compact uncomputed integral. That algorithm is pretty efficient, but it may end up avoiding the computation of an integral in a case where the integration can be performed smoothly.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Carl Love,  nm

I wrote this help page and program. I wrote "work as well", that is what I meant. Not at all "works well". The page actually says, as you quoted, that for 1st order ODEs by using this algorithm you map the original problem into an equivalent one, so no gain, i.e. in that case it does not work well. I am a non-native-English speaker but I don't see what would be wrong with this use of "work as well" in this sentence of this help page.

Regarding the hang, as the help page tells, in the first step the algorithm constructed another ODE "equivalently difficult to solve", whose solution involves integrals with wallpaper integrands involving unresolvable RootOfs. The system hangs when trying to perform those integrations in order to move to the second step. You see the flow entering debug(`symgen/formal`). I don't see a problem here. The use of formal for 1st order ODEs is just inappropriate, even if allowed mainly for pedagogical purposes.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

The problem with mathit is that it removes blank spaces, while in Maple, it is valid to have "symbols" with blank spaces. The textit approach resolved that. There are, of course, other options: add an extra \; after textit, or use the alternatives to work around the removal of blank spaces.

I will think about it.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

One of the bugs in the old latex command is, precisely, what you are showing: the imaginary unit is I but appears translated as i. The fix consists of: respect your choice.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Thanks for the report; this one is fixed in the Maplesoft Physics Updates v.786 or newer. That version also added one more Usexxx variable: Latex:-UseColor := true (default value). With that, for example, Latex(Int(f(x),x)) gets translate using gray, but if you don't want colours set Latex:-UseColor := false.

Regarding one other question you posted: a) now, Typesetting settings do not get changed unless you with(Physics). Besides, you can also assign Latex:-UseTypesettingCurrentSettings := true for that same purpose. And b) assuming does not use Physics:-Assume unless you with(Physics), or you explicitly enter Physics:-Setup(assumingusesAssume = true). For an example of the convenience of using Physics:-Assume instead of assume, see the explanation and examples in ?assuming,details.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Update to Maplesoft Physics Updates v.779 or newer, then put Physics:-Latex:-UseTypesettingCurrentSettings := true at the top of your scripts, or in a worksheet before using Physics exports (e.g. Latex), or in your .mapleinit file read when you open Maple. Then your "current" Typesetting settings (whatever they are) will not be "extended", when you load Physics, or when you use Physics exports like Latex and execute a product that requires initializing the package.

Details.

In Maple, for a long time, the default was interface(typesetting = standard). Since some years it is interface(typesetting = extended). I like that. For a release or two interface(typesetting = extended) implied on Typesetting:-EnableTypesetRule(Typesetting:-SpecialFunctionRules); Typesetting:-Settings(':-typesetdot' = true); and Typesetting:-Settings(':-typesetprime' = true). And physicists enjoyed that, up to the feedback I receive,

But then those three Typesetting settings were removed from "interface(typesetting = extended)", which remained the default. After asking for opinions, we end up maintaining these three settings active when you initialize Physics (using 'with' or using its exports) and interface(typesetting = extended) (or the equivalent Physics command Setup(mathematicalnotation = true). Since then It's been several years, and it is the first time someone using Physics complains about using the prime or the dot settings - naturally because they are of no use in your case.

In brief, a possible solution to this is as implemented now: set your Typesetting settings as you prefer then enter Physics:-Latex:-UseTypesettingCurrentSettings := true, before using any Physics command or before loading the package, and your Typesetting settings will not be extended or changed.

As for any other issue you noticed (e.g. itsme seems to have crossed with other things but didn't provide examples), please recall the package is not finished, your feedback is very welcome, either describe them in an email with attached worksheet to physics@maplesoft.com, or post that worksheet here (Green arrow please). Thanks.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft


Both the equation and sol are translated properly ... this is what I see:

 

 

restart; sol := dsolve(t*(t-2)^2*(diff(diff(y(t), t), t))+t*(diff(y(t), t))+y(t) = 0, y(t))

y(t) = _C1*HeunC(1/2, 1, -1, -1/2, 3/2, -2/(t-2))+_C2*HeunC(1/2, 1, -1, -1/2, 3/2, -2/(t-2))*(Int(exp(1/(t-2))/HeunC(1/2, 1, -1, -1/2, 3/2, -2/(t-2))^2, t))

(2)

ode := t*(t-2)^2*(diff(diff(y(t), t), t))+t*(diff(y(t), t))+y(t) = 0

t*(t-2)^2*(diff(diff(y(t), t), t))+t*(diff(y(t), t))+y(t) = 0

(3)

with(Physics)

Latex(ode, output = string)

"t \left(t -2\right)^{2} \Mapleoverset{\ldots}{y}\left(t \right)+t \Mapleoverset{.}{y}\left(t \right)+y \left(t \right) = 0"

(4)

Latex(sol, output = string)

"y \left(t \right) = \textit{\_C1} \textit{HC}\left({\frac{1}{2}, 1, -1, -\frac{1}{2}, \frac{3}{2}, -\frac{2}{t -2}}\right)+\textit{\_C2} \textit{HC}\left({\frac{1}{2}, 1, -1, -\frac{1}{2}, \frac{3}{2}, -\frac{2}{t -2}}\right) \left(\int \frac{{\rm e}^{\frac{1}{t -2}}}{\textit{HC}\left({\frac{1}{2}, 1, -1, -\frac{1}{2}, \frac{3}{2}, -\frac{2}{t -2}}\right)^{2}}d t \right)"

(5)

``


Note anyway that the package is not finished.

About \Mapleoverset and other stuff: among the core elements of this new Physics:-Latex there are: to take full advantage of everything already implemented in the Maple Typesetting package, don't be shy in using CTAN official LaTeX packages, and naturally use the Maple own .sty file, maplestd2e.sty. This is how the equation looks when latex processed:

Because all the translation to latex is done taking advantage of the Maple Typesetting package, you can also control some of this translation using Typesetting settings, for example to not use the dot to represent time derivative (see the Typesetting help pages). The same applies to translating mathematical functions.

Regarding using CTAN official LaTeX packages, it is since 1997 that I am Editor at Computer Physics Communications. I have seen enough papers taking advantage of existing advanced typesetting. Perhaps for that reason, in Physics:-Latex, the idea is to really get the most, not just cover gaps in the old latex.

Download xyz.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical functions, Maplesoft

Hi
Indeed, the three numbers refer to chapter, equation and case. I am correcting that in the help page. Regarding your other question, I cannot reproduce your problem. This is what I get:

You see the Coordinates there. To understand what could be the problem at your end, It is better if you upload a worksheet showing the input and output; for that purpose you can use the green arrow you see when you post a question or Edit your previous post.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Hi

Input ?Physics,Updates and you will see links to most of the pages and posts produced every year, several are related to general relativity. Under Physics Maple 2017 updates, the first link (itemized as "x.") is General Relativity: classification of solutions to Einstein's equations and the Tetrads package. Click it and you will see a couple of paragrams followed by Examples, the second reads "Equivalence for Schwarzschild metric (spherical and Kruskal coordinates)". The contents of that example answer your question. See also the toolbar: you can click the icon that opents that help page in a worksheet, then reproduce the computation pressing enter or running the whole worksheet (that `!!!` icon), and change the metrics of the example by the metrics you have in mind, the adjust things here and there to make this sort-of-template serve your purpose.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

A PDEAdvisor command, although part of the design of PDEtools, never took off: besides "linear PDEs" or those that admit travelling wave solutions, the classification is scarce. There is, however, the infolevel: set it as in infolevel[pdsolve] := 3 (or 2) and you will see significant and relevant information regarding the type of problem and the methods used to tackle - eventually solve - it.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

The claim that one can write the solution for any (all) Abel equation is 100% false. As explained in ?odeadvisor,Abel, only when the invariants are constant (see eq (2)) is that the solution is always possible. 

For reference, these 3 papers present the problem, collected all the solutions available scattered in the literature (many by Abel and Liouville themselves), represented a change in the status of things for Abel equations (the discovery of the AIA class, and its connection with hypergeometric equations using non-point symmetry transformations that involve derivatives, then the development of the AIR algorithm, implemented in Maple), and are relatively easy to understand

  • Cheb-Terrab, E.S., and Roche, A.D. "Abel ODEs: Equivalence and  integrable classes." Computer Physics Communications. Vol. 130. (2000): 204-231.
  • Cheb-Terrab, E.S., and Roche, A.D. "An Abel ordinary differential equation class generalizing known integrable classes." European Journal of Applied Mathematics. Vol. 14. (2003): 217-229.
  • Cheb-Terrab, E.S. "A connection between Abel and pFq hypergeometric differential equations." European Journal of Applied Mathematics. Vol. 15. (2004): 1-11.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

 

PDEtools:-Solve is a unified command for solving equations: symbolically, numerically, in series, differential (ODES and PDES) or not,  solutions freeof(variables), etc. Besides providing more functionality than all those commands together, a single interface, and a unified form of the output, this output is also free of that (annoying for me) nuance that you are pointing at: "x =" is missing in the output of solve or otherwise it puts curly brackets, or undesired square brackets around each solution, etc. So you get

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

In Maple, perhaps more than in other systems, known-function calls are normalized. This really makes life easier regarding simplification and zero recognition in general. In brief, in the case of known-function calls, to normalize means writing things always the same way (as much as possible, e.g. what you show). So for example, sin(p - a) + sin(a - p) automatically returns 0. It makes sense to me. What you are asking, although possible and also reasonable design (make normalizations only within the simplilfier), it is against Maple's design. So the answer is no, in Maple you cannot avoid normalization of known-function calls. You can still use inert functions, as mentioned in Kitonum's reply.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

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