ecterrab

13431 Reputation

24 Badges

19 years, 362 days

MaplePrimes Activity


These are replies submitted by ecterrab

@Rouben Rostamian  

I disagree with your arguments, perhaps with the words you choose, while on the other hand I myself introduced the code in dsolve that attempts to return using sin and cos instead of exp when there are pairs of conjugate roots. With what I disagree is with "sometihing went wrong ...", where nothing actually went wrong, and "Maple 11 did this correctly" while there is nothing incorrectly done - at all - in returning exponentials, which in fact are preferred in some contexts (frequently in Physics when working in field theory for instance).

Anyway the reason dsolve was not already returning with sin and cos was an unexpected ordering of the roots returned by solve. I adjusted that and the solution is now expressed using sin and cos as designed originally. The link to the updated library is the same one found in my previous answer in this thread.

Just to not pass a wrong impression: disagreeing is one thing, appreciating your participation and feedback is an entirely different thing. I really appreaciated your comments, Rouben, we all grow with feedback, and that is great.

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

I just added a note to my previous answer in this thread with a link to a library for Maple 16 that resolves this issue. That update library actually works fine probably in all Maples (I don't have copies of all of them but it should work fine).

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

@Michael_Watson 

I still don't see the expression you want to convert but for which you say that convert doesn't work. Without that I cannot help you more concretely.

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

@Dmitry Lyakhov 

I see now what you meant, but "Example 2)", that illustrates your point, to me only tells about a weakness in our program: up to degree 4, the factorization is always doable and trivial. When rewriting DifferentialGeometry we used factor, it escaped my mind that it sometimes requires the field extension ... that as said it should not be necessary for polynomials of these degrees. This is one thing (that I call "A"), and in fact is easy to improve, besides the fact that you can also use the hint option to workaround with ease this unnecessary limitation.

Independent of that DifferentialGeometry:-LieAlgebra:-Decompose indeed does what you want (what I call "B"), i.e. you get the maximal dimension of an abelian subalgebra directly from its output.

There is a myriad of things to do but I will see if I can address this unnecessary limitation in DifferentialGeometry:-LieAlgebra:-Decompose more or less soon.

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

... I think I know what is going on, I will be posting a fix today in the Maplesoft R&D Differential Equations webpage.

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

@Dmitry Lyakhov 

Without further details, I don't have something to add: my understanding is that DifferentialGeometry:-LieAlgebras:-Decompose gives you what you are asking, in that it decomposes a given Lie Algebra into a sum of idencomposable Lie algebras, and the number of them is the maximal dimension you are asking; did you give a look at the Examples section of its help page? If yes, could you please post a worksheet with the concrete problem that you think it cannot be tackled with this command?

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

@Carl Love 

in "arctan(y" you have an open parenthesis; in that case you can keep the comma in the denominator, only. When the parenthesis are closed, in my opinion there is no point in keeping the comma in the denominator - I agree with Christopher2222, and even if that were necessary in some obscure case, it would suffice to provide a way - say with an extra key pressed, for instance as in Ctrl + comma, or whatever that would server the same purpose.

Besides, if I were to design this from scratch I'd probably follow the same rules you have in 1D, so that it would be intuitive, as opposed to "you have to learn two dialects" regarding precedence. Then for instance not just a comma but also a "+" would automatically jump out of the denominator if there are no open parenthesis.

Anyway ... 

Edgardo Cheb-Terrab
Physics, DifferentialEquations and MathematicalFunctions, Maplesoft

@Michael_Watson 

This is about something else, the presentation of your worksheets in Mapleprimes. As you can see in this thread, your worksheet overflows to the sides. So, to read a single line, you need to scroll horizontally to the right, then to read the beginning of the next line you scroll to the left and so on. Your worksheet has no text but you see this need to scroll when trying to read the formulas.

So how could you avoid this need to scrool? Open Maple's preferences, go to "Export" and where you read Math linebreaking width, set it to 6.5 (the default is 8, which is what causes the overflow to the sides), then click on "Apply Globally" and you are done: next time you post, everything will appear presented within margins.

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

@Carl Love 

What I implemented is the standard multi-index notation for sums. Your question is now clear in this third iteration, and no, you cannot set different lower limits for each of the symbols entering the multi-index notation in a sum. By the way that is not standard in  multi-index notation, where the lower limits are always determined by the value of the right-hand-side of the multi-index sum. More important, I do not recall ever seeing the need of setting the lower value for each of these symbols entering the left-hand side of a multi-index sum notation, in all my career. Of course that is not a "solid" argument against that though. Do you have a couple of interesting examples that would motivate allowing for someting like that?

If not, for me at this point what we have is fantastic functionality working for this. Multi-index notation for sums together with the novelties for symbolic sequences, nth order symbolic differentiation, and some other stuff I posted recently here in Mapleprimes all these things are adding interesting layers of abstraction to the capabilities of the Maple symbolic algebra engine, allowing for more and more advanced mathematics and mathematical-physics methods to be implemented. Sort of "very good enough" :) I'm really happy with each of these developments.

By the way, correcting something I said in a previous reply in this thread: when you Physics:-Setup(redefinesum = true), the redefined sum already handles well, and since Maple 18, the notation "1 <= a+b = c" even when that automatically evaluates to false outside the context of sum. What requires delay evaluation quotes is Sum, not sum. Sum, as all symbols used to represent inert functions, has nothing assigned to it. On the other hand, the redefined sum has the first and second arguments of type 'uneval', so that the evaluation is controlled, avoiding in this way all those "premature evaluation" problems that pervade our old (the not redefined) sum.

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

 

@Carl Love 

Carl, in this other post you ask: "I want the inner sum to be done for all pairs of positive integers (j,k) such that j+k = m-1. ".  It works the same way, but for the detail that in Maple 1 <= j+k = m-1 automatically evaluates to false. So the first workaround is to quote that, as in '1 <= j+k = m-1', but still you cannot do it in two steps because in the middle this will again automatically evaluate to false. One way is then 

> value(Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), ‘1 <= j+k = m-1'), m = 1 .. 5))


The other way is to adjust the code a bit to accomodate this input without having to delay its evaluation - at first sight I'd say this is pretty easy to do. I will give a look.

EDIT I see you also asked about the typesetting. No, I didn't change the GUI. I only adjusted the typesetting rule for sum and with that automatically also the one for Sum (now that the typesetting for inert functions is derived from the rule from the active functions). There is no documentation for this though, as changing the typesetting code is not meant to be done by everybody. I do have an old project, however, of a mapplet allowing one to change the typesetting of everything ... It is not difficult. But I have had no time yet for this.

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

@Rouben Rostamian  

Yes, simplify(.., size) is very simple and yet incredibly handy functionality. What you probably don't know is that you can make Maple post-process, with simplify/size, every single computation you input. The post-processing happens automatically, only once, and right before returning to the screen. This saves you to have to decipher complicated expressions with your brain, or having to remember to apply simplify/size to some result that you see or suspect it does not present its algebraic structure in evident manner.

Anyway, you may want to try it, to have this running all you need to do is to input

> Physics:-Setup(automaticsimplification = true)

(... and magically :) from here on everything is automatically returned simplified in size).

This feature is explained in the page for what is new in Physics for Maple 18.

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

@Axel Vogt 

I don't know what you wanted to say with your formulas without comments. The notation used is standard notation in mathematics. See for instance Multi-index notation, and for one example of the form presented in this thread see the multi-binomial theorem. The example shown in the Maple help page that presents this functionality is actually the multinomial theorem, also standard in the literature:

Physics:-Setup(redefinesum = true):

(a+b+c)^n = sum(factorial(n)*a^p*b^q*c^r/(factorial(p)*factorial(q)*factorial(r)), p+q+r = n);

(a+b+c)^n = sum(factorial(n)*a^p*b^q*c^r/(factorial(p)*factorial(q)*factorial(r)), p+q+r = n)

(1)

eval((a+b+c)^n = sum(factorial(n)*a^p*b^q*c^r/(factorial(p)*factorial(q)*factorial(r)), p+q+r = n), n = 2)

(a+b+c)^2 = a^2+2*a*b+2*a*c+b^2+2*b*c+c^2

(2)

eval((a+b+c)^n = sum(factorial(n)*a^p*b^q*c^r/(factorial(p)*factorial(q)*factorial(r)), p+q+r = n), n = 3)

(a+b+c)^3 = a^3+3*a^2*b+3*a^2*c+3*a*b^2+6*a*b*c+3*a*c^2+b^3+3*b^2*c+3*b*c^2+c^3

(3)

``

 

Download power_expressed_as_a_sum_using_multi-index_notation.mw

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

@Carl Love 

Hi Carl

Have you actually tried? Put m to start at 3

Physics:-Setup(redefinesum = true)

[redefinesum = true]

(1)

Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), j+k = m-1), m = 3 .. 5)

Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), j+k = m-1), m = 3 .. 5)

(2)

value(Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), j+k = m-1), m = 3 .. 5))

16*(D@@2)(f)*f+8*D(f)^2+32*(D@@3)(f)*f+32*(D@@2)(f)*D(f)+64*(D@@4)(f)*f+64*(D@@3)(f)*D(f)+32*(D@@2)(f)^2

(3)

So, it works as fine. Compare with the result you get using your suggested rewriting of the summand to use only one summation index

add(add(2^m*(D@@j)(f)*(D@@(m-1-j))(f), j = 0 .. m-1), m = 3 .. 5)

16*(D@@2)(f)*f+8*D(f)^2+32*(D@@3)(f)*f+32*(D@@2)(f)*D(f)+64*(D@@4)(f)*f+64*(D@@3)(f)*D(f)+32*(D@@2)(f)^2

(4)

Note also that the multi-index notation in the redefined sum handles not just `=` but also `<=`. For example: 1 <= j+k and j+k <= m-1

Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), 1 <= j+k and j+k <= m-1), m = 3 .. 5)

Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), 1 <= j+k and j+k <= m-1), m = 3 .. 5)

(5)

value(Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), 1 <= j+k and j+k <= m-1), m = 3 .. 5))

112*D(f)*f+112*(D@@2)(f)*f+56*D(f)^2+96*(D@@3)(f)*f+96*(D@@2)(f)*D(f)+64*(D@@4)(f)*f+64*(D@@3)(f)*D(f)+32*(D@@2)(f)^2

(6)

Make it  0 <= j+k and j+k <= m-2

 

Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), 0 <= j+k and j+k <= m-2), m = 3 .. 5)

Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), 0 <= j+k and j+k <= m-2), m = 3 .. 5)

(7)

value(Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), 0 <= j+k and j+k <= m-2), m = 3 .. 5))

56*f^2+112*D(f)*f+96*(D@@2)(f)*f+48*D(f)^2+64*(D@@3)(f)*f+64*(D@@2)(f)*D(f)

(8)

All this is presented in that section "Redefine Sum for Multi-Index Summation" in the help page for updates,Maple18,Physics


Download Multi-Index_summation_(II).mw

@shzan 

L is a polynomial in Dx, so degree(L, Dx) will directly tell you the order; to the side of your question, note there is also ldegree for lower order.

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

@escorpsy 

I see nothing wrong at first sight - will give this a deeper look by the end of today and write again.

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

First 37 38 39 40 41 42 43 Last Page 39 of 60