Hi @nm ,

This new problem you reported is fixed now. The recursion was happening in the simplification of properties, namely `property/signum`. The new result for the odetest call is a timeout rather than a recursion:

Austin

@nm I do hope we can get to the bottom of this moderation problem soon. I find your contribution here very valuable and it wil lbe a shame if you leave.

For the record, here is the new bug report you posted:

> sol:=-(-3+I*3^(1/2))^(1/2)*(-x(y)-1)^(1/2)*((I*3^(1/2)-2*x(y)+1)/(I*3^(1/2)+3))^(1/2)*((3^(1/2)
       -2*I*x(y)+I)/(3*I+3^(1/2)))^(1/2)*2^(1/2)*EllipticF((-2*x(y)-2)^(1/2)/(-3+I*3^(1/2))^(1/2),
        2/(3^(1/2)+I))/(x(y)^3+1)^(1/2)+2/3*I/((x(y)+1)*(x(y)^2-x(y)+1))^(1/2)*3^(1/2)
       *(I*(y-1/2-1/2*I*3^(1/2))*3^(1/2))^(1/2)*((y+1)/(3/2+1/2*I*3^(1/2)))^(1/2)
       *(-I*(y-1/2+1/2*I*3^(1/2))*3^(1/2))^(1/2)/(1/(x(y)+1)/(x(y)^2-x(y)+1)*y^3+1/(x(y)+1)
       /(x(y)^2-x(y)+1))^(1/2)*EllipticF(1/3*3^(1/2)*(I*(y-1/2-1/2*I*3^(1/2))*3^(1/2))^(1/2),
       (I*3^(1/2)/(3/2+1/2*I*3^(1/2)))^(1/2)) = _C3:

> ode:=diff(x(y),y) = 1/((y+1)*(y^2-y+1)/(x(y)+1)/(x(y)^2-x(y)+1))^(1/2):

> odetest(sol,ode) assuming integer;
Error, (in type/complex) too many levels of recursion

Hi @nm,

I have a fix ready for the new problem you posted; it will likely appear in a new update very soon.

Also, I agree that the new report was not a duplicate although they are similar and maybe that is the criteria being used? I've asked internally about why these keep getting removed as duplicates.

-Austin

Hi @nm, In principle I agree it would be nice to have a feature like that but I am not sure about the feasbility of it. I will ask about it.

By the way, I know you are already aware, but for anyone else reading here, the recursion error you mentioned in the P.S. is now fixed.

Austin

Hi @nm,

Thanks! I've adjusted the fix mentioned above and hopefully it will be sufficient now. Please use v. 25 of the Customer Support Updates:

Download 240455_2.mw

Cheers,

    Austin

@Christopher2222

Also note this from the assume help page:

• When you make assumptions about a variable, thereafter it prints with an appended tilde (~) to indicate that the variable carries assumptions.  This behavior can be changed, if desired, by updating the showassumed interface setting (see interface).

and from the interface help page:

• showassumed: 0, 1, or 2. Indicates how variables with assumptions are displayed.  A setting of 0 hides assumptions.  A setting of 1 causes variables with assumptions to be displayed with a trailing tilde. A setting of 2 causes a list of assumed variables to be displayed at the end of the expression.

Austin

Hi @nm,

Thanks. Regarding this "new bug", actually the underlying issue existed already in Maple2025:

> A := LinearProp(I,RealRange(Open(0),Open(Im(LambertW(-1)))),0):

> B := ComplexRange(I*Open(0),Open(Re(LambertW(-1)))+I*Open(Im(LambertW(-1)))):
> AndProp(A,B);
Error, (in property/AndProp/+) too many levels of recursion |lib/assume/src/property.mm:363|

but it was exposed by the most recent update and your new example.

Anyway, it's fixed now in a new update. See my post here for details:

https://www.mapleprimes.com/questions/240455-Possible-New-Bug-In-V-22-Of-SupportTools#answer309858

-Austin

Hi @Christopher2222, @emendes,

I tried copying Christopher's input (note I changed the Beta to beta because you had both but Ed's input didn't seem to) and trying solve but I got no solution:

Download 240418_new.mw

Ed, can you provide the exact command you used to get this solution? And the version you are using if it's not Maple 2025?

Thanks!

Hi @Kitonum ,

My suggestion would be to use piecewise instead of `if`. `if` will treat any relation as false if it doesn't evaluate to true, and this occurs before n and m acquire values (evaluation happens from the inside out in this situation):

Download 240403.mw

Cheers,
      Austin

Hi @nm,

I have no comment on the integration result at this point, but I cannot reproduce the recursion errors during simplify that you cite. I tried on Windows and Linux, both with clean Maple 2025, and also with Customer Support Updates v. 13 which I assume you might be using. Can you confirm that you can reproduce these recursion errors? If so, please specify the versions of the updates you are using.

Thanks,
   Austin

Hi @nm ,

My apologies, these two int examples are indeed not fixed yet. When I tested them on my machine, the timelimit was reached (and I even doubled the time allowed) which is why I thought they'd been fixed. However, if I run without a timelimit, indeed I find these recursion errors. As you recall, recursion errors are not trappable, and I don't expect that will change. These errors are due to a problem in the integration code. The person responsible for integration has been notified. I'll edit my reply above to reflect this.

Cheers,
   Austin

Hi @Ronan,

The Maple Customer Support Updates are only meant to work in Maple 2025 and subsequent releases.

Austin Roche
Maplesoft

Hi @nm,

You're absolutely right. Somehow the number was switched. The correct command is this:

PackageTools:-Install(4797495082876928);

I'll correct it in the above announcement as well. Thank you for pointing this out!

Austin

Hi @nm,

The particular solution y = x^(-a) that was missing from the general solution is now included as of a recent update:

This new solution is expected to be available as of Maple2025.

Cheers,
    Austin

Hi @Kitonum,

I agree with @Carl Love . This is not a bug as stated in the original post because the or is evaluating to false before is sees it.

If the input is corrected by using the inert operator Or instead of or, then the result is FAIL, and this is indeed a weakness, as the expected answer should be true.

In any case, thank you for the report. We will investigate.

Austin Roche
Maplesoft