ecterrab

10699 Reputation

20 Badges

16 years, 199 days

MaplePrimes Activity


These are replies submitted by ecterrab

@Carl Love 

They appear in white in my Google Chrome ... but I wrote using Safari's dark mode ... It must be that. So far I mentioned three examples:

exp(0);
                              exp(0)
simplify(%);
                                   1

Then

int(f(x), x) - %int(f(x), x)
simplify(%);
                                                       0?     or     int(f(x), x) - %int(f(x), x)

and

%diff(x^2, x) - 2*x
simplify(%);
                                                       0?

Currently, and for many years they all return as I am suggesting; the last two return 0. If you change %int by Int you also get 0, so nothing of this is really new. The new thing would be to make the simplification of %int and Int work the same way. And make both closer to what you see at this moment in simplify/Int, so do not use value, but for a few exceptional situations like perhaps the above.

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

@acer 

Any change implies different behaviour, And if there is code depending on the previous behaviour, that code needs to adapt. It's always that way, uncomfortable to some point, and things change nevertheless. It is otherwise impossible to progress. So that is for me not an argument against change.

On to the topic: I'm here doing something few people do these days: listening. So far three people said things. While each person thinks her opinion is the good one, each opinion is only one in a universe of opinions. At my end, I am in charge of the simplifier, and it is my opinion that it is good to listen to others' opinions, think, then decide.

Int and %int currently behave differently under simplify. That is incorrect and, of course, we can continue incorrectly, but generally speaking, I prefer to fix these things. In this moment, as noted by @Preben Alsholm, simplify(%int(x, x)) returns x^2/2, unlike simplify(Int(x, x)) that returns Int(x, x). Whether that is convenient for you because you use Int instead of %int doesn't change the matter. Int and %int are two-supposed-to-be-the-same thing, the inert form of int.

The proposed change under consideration goes more into a) making simplify@%int behave like simpify@Int, so do not value things, b) in some cases we may want some equivalences detected - I mentioned some examples above, asked for "Opinions?"; and c) for Functions, (not int, diff, sum, product or limit), for now we may want to keep the current behaviour, where things like %exp(0) become exp(0) when exp(0) is something simpler.

To the side, your comment about "do not remove usefulness" sounds to me a bit out of place. Not only for what implies for me (the guy who removes usefulness? I feel more like the guy who perhaps thinks differently than you) but also because it could be read as "you think that whoever thinks differently than you is indisputably wrong." @acer , that is not useful. Let's just collect some opinions without disqualifying anyone's.

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

 

@Ambrozy Zbój 

Consider this example:

int(f(x), x) - %int(f(x), x)
simplify(%);
                                                       0?     or     int(f(x), x) - %int(f(x), x)

I prefer 0. One could argue this is not about value but about having the inert and active form at the same time. OK that is one exception where we want the inert to become active.

Still how about this other one

%diff(x^2, x) - 2*x
simplify(%);
                                                       0?

Again I prefer 0 and, more generally, if the result is a constant, I prefer it.

Opinions?

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

@Preben Alsholm 

Interesting question. I wrote simplify/inert in 2008. Revising the notes, I was not thinking of "value" but this:

# verify whether transforming inert functions into active ones diminishes the total number of them

Well, in the example you posted, indeed, that is the same as combining with value. Perhaps this other example illustrates the original idea of 12 years ago better:

exp(0);
                              exp(0)
simplify(%);
                                   1

Looking at this result today, I think I want it but can see it is debatable. We can also go with "yes but not in all cases," for example, not in the case of integrals, where the distinction between %int and int has perhaps a more special meaning: in several scenarios, we just do not want integrals computed, at all. In fact, although in computer algebra integrals are implemented as functions, before computer algebra, I never thought of an integral as a "function" to the point that when coding dsolve added `type/Function` to make this distinction clear.

Regarding the difference you noticed between simplifying %int and Int, that caught my attention too, is due to historical reasons only. There is `simplify/Int` from before the existence of inert objects, and simplify calls that routine instead of the more modern `simplify/inert.` That is to be fixed, %int and Int should go both either through simplify/Int or simplify/inert, depending on how this conversation ends.

So, opinions?

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

@Carl Love 

For me the important thing is, generally speaking, "give me the chance to reproduce it, and I will do my best to fix it, otherwise it is an impossible task". So although I realize the frustration this or that can cause, providing a way to reproduce the problem you are experiencing is the only reasonable or useful-in-practice way to go, I think. To the side, however, related: to invoke shame for a bug in code by others, or feel shame for a bug in your code, is never the way to go. And concerning 2D display of input, something I use and enjoy, I am particularly interested in collecting bugs, issues or suggestions. At every release, I see those fixed more and more.

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

Hi,

I just saw this post from 2018 ... Within the Maplesoft Physics Updates there is a new command, Latex (uppercase L), that has this issue corrected 

> Latex(sol);
-\frac{3}{2 \left(x^{3}+3 z \right)}


This command also provides more functionality than the old lowercase latex, for example: inert functions, that in the worksheet appear displayed in grey, are tex-translated with color:

> Latex(Int(f(x), x));
\textcolor{gray}{\int }f \left(x \right)\textcolor{gray}{d }x


and alias are taken into account, which allows you, for instance, to use an indexed c[n] instead of the old convention _Cn for integraion constants entering solutions of differential equations:

> alias(seq(c[n] = _C || n, n = 1 .. 3));
> Latex(dsolve(diff(y(x), x $ 3)));
y \left(x \right) = \frac{1}{2} c_{1} x^{2}+c_{2} x +c_{3}


More important, the new Maple Latex command translates everything. So if you see it on the screen, expect to see the same in the tex translation - no exceptions. The trick for that is that Latex is based on the modern Maple Typesetting package. So, as soon as new mathematical notation is implemented in the system, it is automatically available in LaTeX form.

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

@nm 

To the side, I see _C1(n) in the solution you posted. That was meant to be _F1(n), according to notational conventions in all the DE code, but I see I forgot adjusting that an year ago. It is adjusted now, in v.824 of the Maplesoft Physics Updates.

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

A workaround for installing the Maplesoft Physics Package in the Windows platform (some people experienced problems with that) or for the case other MapleCloud packages, is available. See "Workaround for the problem of installing MapleCloud packages in the Windows platform"

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

@JonMcLoone 

... hmm I wonder how is that my name ecterrab appears in your reply, Jon. In my reply to you in that Mapleprimes post of 2015, I gave my opinion that both systems have their strengths. Then elaborated about Maple's capabilities in mathematical functions (FunctionAdvisor), mentioned DifferentialAlgebra, DifferentialGeometry, Differential Equations and Physics, areas where I think Maple has better performance, or in the case of Physics, there is nothing really similar in Mathematica to compare with. I work on these projects and feel comfortable talking about them. But  I don't write Maple's advertisements - but for perhaps some sentences related to these areas just mentioned only - not the topics of this thread.

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

@rlopez 

Hi Robert,

That option exists, alias. Further below Pascal mentioned it in the context of Latex, but it is of course valid outside that context too. For example, something in your mapleini file like 

alias(seq(c[k]=_C||k,k=1..10));

would make 1) the _Cn invisible forever (you basically never use equations of order > 10, and if it where the case, make it 20) and 2) keep all the library working properly; many library routines scan for _Cn, they will all find it even when they look like c[n].

On the other hand, making an option like in LinearAlgebra:-LeastSquare has the obstacle that all the library routines that scan for _Cn will not find it anymore, because now something else would be in use (and no alias around to help to find the right object).

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

@nm 

In view of your goal being Latex related, Pascal's idea seems to me simplicity at its best. I like that. You can complement his suggestion to cover your concern about N as follows:

> N := sol -> `PDEtools/max_C`(`PDEtools/_C`(sol)) - 1:      # the answer to your question

> sol:=dsolve(diff(x(t),t$4) = x(t));
> alias(seq(c[k] = _C||k, k = 1..N(sol)));              # Pascal's suggestion
                                      c[1], c[2], c[3], c[4]


Besides, suppose you know the differential order of the equations you are handling, and you know they are all of order 5 or less. Well, then N = 5 suffices. In the _Cn, the maximum value of n is the differential order.

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

@Carl Love 

You are 100% right. Sometimes my brain does literal translations without thinking ... I fixed the pages now; not differential to non-differential in: PDEtools/ConsistencyTest, PDEtools/DeterminingPDE, PDEtools/Infinitesimals, PDEtools/InvariantSolutions, PDEtools/ReducedForm, PDEtools/SimilaritySolutions and PDEtools/SymmetryTest.

7x Thanks :)

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

@nm 

In Maple, there is type algebraic. It is not a good idea to use that word in the context of Maple help pages. Not differential is understandable but non-differential is also OK - @Carl Love, does it read better? If so I have no problem in changing it.

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

@nm 

There is a different processing of the PDE determining system for the infinitesimals (DEtools:-odepde, or PDEtools:-DeterminingPDE). The symgen routines are more oriented to getting one pair of infinitesimals - that is enough to solve an ODE - while those in PDEtools are oriented to get all existing pairs of infinitesimals - not just one to solve an DE. In doing so, they can end up facing an almost untractable problem from the point of view of differential elimination (packages DifferentialAlgebra, DEtools:-rifsimp, or DifferentialThomas). Try PDEtools:-casesplit(DEtools:-odepde(ode, [f(x), x*g(y)])) and you see the hang. There is nothing wrong with that: the underlying differential elimination problem is - in practice, for the existent differential elimination software - untractable. Perhaps adding some option with the meaning of "get something for me, not just everything" ... I'd need to think about.

PS: next answer only in a day or more - am busy with other stuff.

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

@nm 

So it wasn't \mathbf after all. OK. Regarding \boldsymbol: this Tex StackChange thread tells me it was obsolete in 2017.

Your discovery and comment, however, is always welcome and useful, don't get me wrong please. And in this case took me to discover there is \boldmath (not \mathbf) which requires no additional package and accomplishes bold & italics in the presence of \mathit.

I will do some more tests here. If everything passes to my satisfaction I will change textbf & textit by boldmath & mathit and put the change in the next version of the Maplesoft Physics Updates so that everybody can try it.

PS (I) after posting: tried. There are several problems, it is not a solution. Being that in this particular case textbf & textit works perfectly fine, this becomes a sort of irrelevant thing at this point, I will keep it as is until I see a solution that works as well, without having to load yet another package, and without having to add to the complexity of the code, in a case like this one, with no gain in functionality.

PS (II) after posting: did more experimentation, and taking everything into account \boldsymbol does look like the winner. So in the Maplesoft Physics Updates v.793 there is only \mathit and only \boldsymbol, to respectively get italicized and bold, and spaces between words are preserved.

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

 

5 6 7 8 9 10 11 Last Page 7 of 52