Advanced Search

aroche

Dr. Austin Roche

780 Reputation

11 Badges

12 years, 337 days
Maplesoft
Waterloo, Ontario, Canada
Contact Dr. Austin Roche
I am a Software Architect in the Math Group, working mostly on the Maple library. I have been working at Maplesoft since 2007, in various areas including differential equations, integration, mathematical functions, simplification, root finding, and logic. I completed a Master's degree from McGill University with a thesis in Differential Geometry, and a PhD from Simon Fraser University with a thesis on Differential Equations.

MaplePrimes Activity


These are answers submitted by aroche

Fixed, Maplesoft Physics Updates v.1749...

aroche 780
May 29 2024
5 1

Hi,

Thanks for finding this bug!

As mentioned by other commenters, simplify always just maps into the operands of non-algebraic objects like equations. So there is no way to use simplify to manipulate an equation as you are trying to do here, but again as mentioned, convert could be a better option.

Nevertheless, the simplify extension mechanism was broken in the case where the name of the extension doesn't occur as a function in the input expression. So for example, this worked:

> 

`simplify/F` := u -> G(u):
simplify(F(x), F);

G(F(x))

but this didn't:

> 

simplify(x, F);

x

This issue has now been fixed. After installing the latest Physics Updates (v.1749), we now have:

> 

`simplify/F` := u -> G(u):
eq := (a*x + b)/(c*x + d) = 11/3:
simplify(eq, F);

G((a*x+b)/(c*x+d)) = 11/3

> 

eq := (a*x + b)/(c*x + d) = sqrt(2):
simplify(eq, F);

G((a*x+b)/(c*x+d)) = G(2^(1/2))

> 

eq := (a*x + b)/(c*x + d) = y:
simplify(eq, F);

G((a*x+b)/(c*x+d)) = G(y)

Note that simplify also avoids applying any simplification to expressions which it deems are already simple enough (in particular that means anything of type complex(extended_numeric)), in this case the rhs of the first input 11/3 because it's numeric.

As an aside, I'll note that this problem with the extension mechanism first happened due to an improvement in simplify that was put in for Maple2023. Before that, if you called simplify with multiple extra arguments specifying sub-algorithms to be applied, it would just apply them once each, and this sometimes meant that by applying the same simplify command twice in succession, the second result would be an improvement:

 
> 

e := RootOf(_Z^2 - exp(2*RootOf(_Z^2+1,index=1)*x) - 1):
> 

simplify( diff(e-subs(RootOf(_Z^2+1,index=1) = I, e), x), RootOf, exp);

-I*(RootOf(_Z^2-exp((2*I)*x)-1)^2*exp((2*I)*x)-exp((2*I)*x)-exp((4*I)*x))/(RootOf(_Z^2-exp((2*I)*x)-1)*(exp((2*I)*x)+1))

> 

simplify(%, RootOf, exp);

0

After that improvement was put in from Maple 2023, simplify will continue to alternate through the requested simplifications until the result stabilizes, which in this example means that simplify only needs to be called once to achieve the desired answer:

 

When multiple particular simplification procedures are requested via extra arguments to simplify, they will each be retried as many times as needed to obtain the full simplification. For example, the extra arguments exp and RootOf can now be given in either order to achieve the full simplification:
> 

e := RootOf(_Z^2 - exp(2*RootOf(_Z^2+1,index=1)*x) - 1):
> 

simplify( diff(e-subs(RootOf(_Z^2+1,index=1) = I, e), x), RootOf, exp);

0

Download simplify_ext.mw
Download simplify_ext2.mw
Download simplify_ext3.mw
Download simplify_ext4.mw

As usual, the fix is distributed for everybody using Maple 2024 within the Maplesoft Physics Updates v.1749 or newer. To install the Updates, open Maple and input Physics:-Version(latest)

Austin Roche
Maplesoft

Fixed, Maplesoft Physics Updates v.1747...

aroche 780
May 28 2024
4 0

 

Hi,

Thank you for finding this bug!

The general form of the ODE where this problem occurred is this one:

> 

ode := F(x,y(x))*diff(y(x),x) = 0;

F(x, y(x))*(diff(y(x), x)) = 0

It so happens that Student:-ODEs was relying on odeadvisor to classify the input ODE. Now, while a call to odeadvisor with no extra arguments produces the expected answer,

> 

DEtools:-odeadvisor(ode);

[_quadrature]

Student:-ODEs was actually trying the 'exact' method first, and odeadvisor - for this very specific, trivially solvable class and when provided the extra argument [exact] - was asserting that indeed the ODE is exact.

> 

DEtools:-odeadvisor(ode, [exact]);

[_exact]

This is of course not an exact ODE unless F has no dependence on x.

In any case these bugs are now fixed. The new result from odeadvisor will be [NONE] signifying that the ODE is not exact:

> 

DEtools:-odeadvisor(ode, [exact]);

[NONE]

 and the previously wrong results from Student:-ODEs are now replaced by the expected answer

> 

Student:-ODEs:-Solve(ode);

y(x) = c__1

With regard to the result for y(x)*diff(y(x),x)=0, there was in my opinion no bug - the result (which has not changed after this fix) was correct, although not fully simplified.

> 

Student:-ODEs:-ODESteps(y(x)*diff(y(x),x)=0);

"[[,,"Let's solve"],[,,y(x) ((ⅆ)/(ⅆx) y(x))=0],["•",,"Highest derivative means the order of the ODE is" 1],[,,(ⅆ)/(ⅆx) y(x)],["•",,"Integrate both sides with respect to" x],[,,∫y(x) ((ⅆ)/(ⅆx) y(x)) ⅆx=∫0 ⅆx+`c__1`],["•",,"Evaluate integral"],[,,((y(x))^2)/2=`c__1`],["•",,"Solve for" y(x)],[,,{y(x)=sqrt(2) sqrt(`c__1`),y(x)=-sqrt(2) sqrt(`c__1`)}]]"

The y(x) = 0 is fully contained in the given answer when c__1 is set to 0, so the only issue really is that the two answers could be combined into one simpler answer y(x) = c__1, but this kind of polishing is not really the main goal of the Student package.

Download Answer6.mw

The issue is fixed, and the fix is distributed for everybody using Maple 2024 within the Maplesoft Physics Updates v.1747 or newer. As usual, to install the Updates, open Maple and input Physics:-Version(latest)

Austin Roche
Maplesoft

The fix will also go into Maple2024.1...

aroche 780
March 26 2024
2 0

Apart from being available in the Physics updates as mentioned by @ecterrab, this fix should also appear in the next patch release (2024.1).

Fixed for Maple 2024...

aroche 780
March 25 2024
3 0

This bug was fixed for Maple 2024.0:

> 

expr := -1/7 - (-1/7*7^(5/7)*exp(2/7*Pi*I)*sin(1/7*Pi)*I - 1/7*cos(1/7*Pi)*7^(5/7)*exp(2/7*Pi*I))^(7/2);
simplify(expr);

-1/7-(-((1/7)*I)*7^(5/7)*exp(((2/7)*I)*Pi)*sin((1/7)*Pi)-(1/7)*cos((1/7)*Pi)*7^(5/7)*exp(((2/7)*I)*Pi))^(7/2)

-1/7-(1/7)*(-1)^(2/7)*(-(-1)^(3/7))^(1/2)

Download mp_tmp.mw

Fixed as of Maple2024...

aroche 780
March 25 2024
4 0

This weakness was fixed for Maple2024.0:

expr:=c[2]*sin(sqrt(3)*x/2) + c[3]*cos(sqrt(3)*x/2);
expr:=convert(expr,tan);

simplify(expr);

Fixed...

aroche 780
June 30 2021
3 1


Hi Réjean
,
Thank you for the report. This bug is now fixed in the development Maple. The new answer is:

Sum(Sum(a[u]*a[v]+2*a[u]*b[v],u = 1 .. n),v = 1 .. n);

                              n   /  n                            \
                            ----- |-----                          |
                             \    | \                             |
                              )   |  )   (a[u] a[v] + 2 a[u] b[v])|
                             /    | /                             |
                            ----- |-----                          |
                            v = 1 \u = 1                          /

Cheers,

   Austin

The bugs you posted are now fixed....

aroche 780
April 18 2020
3 0

As Edgardo mentioned in another answer, the bugs you posted in simplify are now fixed, and the fixes are available in the Physics Updates (Maplesoft Physics Updates v.643 or higher) which can be used now if you have Maple 2020. These fixes are also expected to be included in the next dot release for Maple 2020.

I just want to give a bit of explanation about what happened because this bug indeed seemed a bit mysterious. First of all, the factorial functions were being converted to GAMMA using n! = GAMMA(n+1). The simplification that was then being applied was the following:

1/(GAMMA(x)*GAMMA(k - x)) = sin(Pi*x)/(Pi*Product(x - i, i = 1 .. k - 1));


which is generally valid when k is an integer as was the case in your examples. Typically, this is a useful simplification to make as the result only involves elementary functions. Unfortunately, when x is also an integer, the numerator in the rhs is sin(Pi*x) which evaluates to 0. There may also be factors in the denominator which are 0, either explicitly or under assumption. In such cases, it is better to avoid applying this simplification and indeed, Maple has been careful to recognize these cases and avoid this substitution in such cases for the most part. The one exception here is that it didn't recognize that if x is actually a summation index (as the n in your examples is), then it is implicitly assumed to be an integer, even though no such assumption has been explicitly made using the assume facility. The fix was to make the GAMMA simplifier aware that summation indices are also integers and to have it take extra care in those cases as well.

Note that in your last example, simplify(op4), the n in the expression op4 has neither an explicit nor implicit assumption of being an integer, so the above simplification still goes ahead (and is valid in general).

Austin Roche

1 2 3 Page 3 of 3