@Greenwaldian 

I'm not sure that I understand the comment about admin access. IIRC the file in question exists per user, and even on a network install. It might be accessible by the user himself/herself.

You might submit a bug report, here. There's even a chance that a fix might make it into a "point-release".

@mmcdara The relative performance of these might well change if done for (a modest) number of much longer individual lists, or even for a much larger number of modestly sized lists.

So, just as one data point: ListTools_Search_tim.mw

@Greenwaldian That,

ScrollableMathTableOutput=false

is not a Maple command. It is line for the user's GUI preferences files. I don't mean the .ini file that can act as an initialization file. Rather, I mean the (similarly named, but differently located) GUI preferences file. Again, it's not a Maple command.

This file is where the GUI options and preferences are stored. But this particular preference does not appear as an option in the GUI's own popup menu (Options dialogue).

The line might already exist in one's file, but with true instead of false. The GUI would need to be altogether closed, then the file edited and the existing line changed, then the file saved&closed, and then the GUI relaunched.

It's conceivable that disabling the (new to M2024) scrollable Matrix display in the GUI might also revert the PDF export mechanism aspect that produces your ellipsis example. If you haven't yet been able to disable this new rtable/Matrix scrollable display mechanism then you haven't as yet been able to test it as potential workaround.

Which operating system are you using, btw? Perhaps someone else might be able to reproduce the problem.

Does this behavior get affected/improved if you change the interface(rtablesize) setting?

Does this behaviour get affected/improved if you manage to disable the (new in M2024) so-called scrollable rtable/Matrix/Vector display?

ps. I have changed your Post into a Question.

@Paras31 Please don't spawn wholly separate, new Question threads for other attempts you make at porting this code to Maple.

(Duplicate Question threads get flagged as such and may even be deleted by some moderator.)

@Carl Love If you make the transformed result be something like H(["x"=x,"y"=y]) and run the applyrule under trace then the cause partially reveals itself. It accepts too much for the pattern, in particular the dreaded unit.

Sometimes this can be avoided. One variant:

applyrule((x::nonunit(anything))^(1/2)*(y::nonunit(fraction)) = `%*`(y,x^(1/2)),eq);

The OP didn't provide other examples and expectations, so it's not clear whether (and how) things like 3/(2*p)*sqrt(-2*lambda) might be preferably handled. Variants can be had.

@Thomas Richard Sometimes inconsistencies are not terrible; I'd rather not read code that contained esu or yrt.

The right-hand side of your expression does not exceed a value close to 4, so there is no value of t which would make it equal to the left-hand side which you have as 45.86294900.

Download comment.mw

"Man is the measure of all things: of those that are, that they are; and of those that are not, that they are not."

@Ronan 

Download evat_at.mw

@MAXR A duplicate of this has been deleted.

@Paras31 In order for beta to be workable as an Explore parameter here it also needs to be one of the dsolve,numeric parameters.

Here's a run at using odeplot (which can produce a decent curve more efficiently here than the plot command) inside Explore.

In order to get nice smooth, continuous behavior for, say, the beta Slider then overhead time cost of each PlotProc call must be kept low. I suspect that odeplot is the best bet here, especially if a decent curve is also wanted. You might experiment with its options.

I put the continous=false option on the Explore Sliders for x0,y0,z0 since when more than one of them is high (>10, or whatever) then odeplot can run amok and freeze everything. This option makes the exploration update -- and produce a single new frame -- only when the x0|y0|z0 Sliders stop sliding.

math_model_eco-epidemiology_v2_ac.mw

nb. Using odeplot instead of plot makes this variant of PlotProc much faster. When you use odeplot then it knows how to effectively&efficiently utilize the sols numeric solver returned by dsolve,numeric. In contrast, when you just utilize the plot command then it doesn't know how best to use that sols numeric solver returned by dsolve. All the plot command knows is that it's been passed some black-box proc(s) to use.

@Paras31 The odeplot command is not advanced Maple. It's a step above the basics. Actually, as a single command using odeplot might even be more basic that what you showed as extracting from the dsolve return.

(It just happens that odeplot serve both basic needs as well as provide some sophisticated options, etc.)

Sometimes it can serve well to show people two or three ways of doing something: the basic and naive way, the next step up, and the best way that both they and you understand.

Now that you have shown your students the most basic of approaches, why not show them some better methodology, some of which you have been shown (a few times) in other threads in the forum?

You could odeplot, which can be more versatile and efficient. That is not very advanced usage.

You could use the parameters option for dsolve, to better vary the value of beta (and efficiently construct an animation, say).

It seems as if your attached .mw file might actually be just a saved instance of that start-up worksheet.