@sursumCorda I don't think that you've misunderstood. It seems more a weakness in simplify/constant.

ps. As an aside, this seems mere luck here:
    simplify(convert(f,compose,arcsin,ln));

@nm How's this:

Download ode_solution_remembered_11022026.mw

note: The symmetry methods attempt `odsolve/sym_pat/[F(x),G(y)]` calls `ODEtools/play`, which seems to work with substitutions for x,y by names (`ODEtools/x`, `ODEtools/y`) which lack the assumptions. Then a check for a remembered result in `ODEtools/remember` for `odeadv/high_oder/lin_sym` utilizes the expression with the substituted names, finds details from the earlier call, and it fails out.

@Mac Dude This is just a side comment related to what you've written (as opposed to the OP's issue).

If the GUI (front-end interface) itself locks up while dealing with a particular worksheet then it can be frustrating if killing it would result in lost changes in other open sheets.

The GUI runs in a Java virtual machine (jvm), and by default opening multiple sheets via the desktop icon will result in their all being under that single jvm. Forced closure of that jvm+GUI can then result in all its related open worksheets being closed.

But there is an alternate way to operate. If the GUI is launched with a command option
   -standalone
then the GUI instance will be separate from other instances. When one of the GUI front-end instances crashes hard (without Save offerings) then other sheets in such separate GUI instances won't also get forcibly closed.

On MS-Windows I have two desktop icons for launching the Maple GUI. One is a copy of the other, except that I edit the launching command within it (right-click Properties, IIRC), and add that option (and then rename it something helpful as visual reminder).

So this give me a choice of how to launch. In practice I find that the memory cost of multiple jvms is not prohibitive. (Many years ago the resident memory in the OS was a significant portion of the total available on my machine. These days it's not...)

On Linux I don't use a desktop icon, but launch from a terminal shell with a command (aliased to a single word), eg.
    /usr/local/maple/maple2024.2/bin/maple -s -x -standalone &

There are other variants to this. Eg, I also use the -s option when I want to exclude reading of a personal init file's Maple commands.)

ps. IIRC you might be a Max OSX person. I don't know where the underlying executable call is located under any OSX icon launcher.
pps. Another (slightly odd) thing one can do with separate GUI/jvm is open the very same .mw file more than once (without renaming), separately. Of course, you need to be careful when saving such.
ppps. edit with care

You've asked about this in at least two earlier and separate Question threads.

This is one of them, and plots:-display(seq(...),insequence=true) worked there as well as here.

@sand15 I shall log a full bug report, including a link to your notes (and possibly your .mw files). Thanks.

ps. I didn't write more commentary before about the behaviour (other than only an observation of when the runtime error appeared) because I'm busy these days. But thanks again.

@JoyDivisionMan You could submit a bug report using this form.

That error appears to have started some time between Maple 2023.2 and Maple2024.2, ie. with some release of Maple 2024.

@nm I'd agree that is undesirable. I'd like to track down what's being remembered.

@Kitonum Those are the same reasons why I used the assumptions 0<x<1 in my Answer from yesterday.

And with x>0 I had already gotten the very same 4sec performance and the very same target result. (Only a part of those assumptions turned out necessary to get that.)

You have (importantly) added a programmatic aspect to such deduction. It might be difficult to take all that same approach in general, but it could be nice if there were somewhat easier ways to convey such detail and have the system figure more of such details as it went.

I thought that I'd checked this when I first Answered, but apparently I didn't.

Using the assumption x>0 (which is the same as the OP was willing to use in hist odetest call) in the dsolve attempt can also work pretty quickly and without undue memory use.

Download de_hard04.mw

I guess I started trying the expln form before I started leveraging that assumption.

note: The above worked directly, if the same assumption was used. But it's not as lightning fast and lean as was the (also) successful trick of doing the temporary change: Y(x)=y(x)/arcsech(x)

The following runs very quickly, with low memory use.

Download de_hard03.mw

Another note on variables, since the OP mentioned "names": the declared globals,
the declared locals, and the lexicals are (the) symbols and not, say, indexed
names as might appear and be used.

Download proc_lcl_ex1.mw

And another note: names used as globals in the procedure, but which are not declared as global, are not "global variables" of the procedure, per se.

Download proc_lcl_ex2.mw

@janhardo No, a local variable of a procedure may be used in a practical and useful manner even if it's never assigned any value.

Here's an example in which the local variable x gets (usefully) utilized as a symbolic name, even though it does not get assigned a value.

Download proc_lcl_ex0.mw

That message from maplemint clearly indicates both that x is a local variable and that x is not getting assigned.

It follows from that, logically and directly, that being assigned is not a condition for being a local variable.

That maplemint message directly and completely contradicts janhardo's claim -- as does the runtime behavior of the example above.

janhardo's statement, "A name is  a variable when there is a valued assigned to it" is not true, and it does not convey important aspects of the question.

A variable of a procedure (whether local, global, lexical, etc) has that nature regardless of whether it has been or ever gets assigned a value.

@JoyDivisionMan It also produces the value zero 0 if assuming t<=0.

It would be nice if int(..., allsolutions) were able to handle this example directly.

So (while using supports of RVs might be one way, especially in this simple arithmetic combination), one can also split at the problematic value t=0.

But t::real can be handled as well, (if stepping in to deal with t=0), eg.

Download MultiplyPDFFunctions_acc.mw

ps. I don't see why this might be considered any more ad hoc than using conversion via ln (which doesn't alone work for all examples...). Problematic t-values might possibly be found programmatically, though as mentioned it'd be nice if int handled it directly via allsolutions.

Sometimes I prefer workarounds like applying ln (since it's terse and easy to try), and sometimes I prefer ones which (I suspect) might give me additional insight into how things might get improved directly/automatically.