The small imaginary components of your result can be seen to be an artefect of solving a cubic in terms of radicals, and then computing as a floating-point approximation (in which case the small imaginary artefacts don't vanish due to floating-point concerns -- roundoff error, loss or precision, etc).

You can read about the notion that the purely real roots of some cubics may not be expressible in terms of radicals without the "I" (ie. sqrt(-1)) being present. But a reformulation in terms of trig expressions can get a form in which "I" does not appear, and for which floating-point evaluation produces no such small imarginary artefacts.

Download concentrations_ac.mw

I marked your Question to be Product=Maple 2022, since that's the version in which your attachment was last saved. It'd be more helpful if you could mark the Product version yourself, for future Questions.

In Maple 2022 your examples are running into issues with the (then new) adaptive=geometric default, and/or the default smartview=true option. Some improvement might be had automatically in the newer Maple 2025.

Each of your examples can be forced to comply (in versions M2022 to M2025) by adjusting those options:

Download plotatzero_ac.mw

You asked how to set the Output display to "Maple Output". But that's not the right value for the setting.

From the menubar, you can set it as,

    Tools -> Options -> Display -> Output display -> 2-D Math

where the drop-menu item would be "2-D Math" instead of "Maple Notation".

Then close the popup dialogue with the "Apply Globally" button.

ps. I too have seen this setting get undone, in rare cases. I sometimes wonder whether it can go awry because there is also a programmatic interface(prettyprint) access to it.

Does your code function as you expect if instead you have that as,

   Object('A':-foo_type)

In Maple 2024, under Tools->Options from the menubar, you could do the following:

1) Choose the tab "Interface", and inside that toggle the drop-menu for,
      Default format for new worksheets
to Worksheet (ie. not Document).

2) Choose the "Display" tab, and inside that toggle the drop-menu for,
      Input display
to Maple Notation (ie. not 2-D Math)

Then close the pop-up Options window by clicking on the button "Apply Globally". That should then make this the default, ie. even if you fully close and relaunch the Maple GUI.

The effect of these, together, is that your inputs will be in red plaintext, ie. Maple Notation mode -- with the red chevron -- in Execution Groups (just like Maple 8 and earlier). It won't be black, marked up 2-D Input math mode in Document Blocks.

This is the prescribed way to get such changes. You don't need any special Style Set or such, to get the red color for plaintext Maple Notation input code.

You could also look at the Help page for topic documentsvsworksheets

Hopefully I haven't guessed wrongly about what you're trying to accomplish.

I can think of a few ways to accomplish this.

The first way involves using a different sort call on each of the inner sums (coefficients of the lambda__ij(t) terms). This happens to work for these examples, although in a more general case it could run into difficulties or need even more special handling. This is what I did in the attachment below; it's not completely general code, though it does contain some generic stuff rather than being all ad hoc op stuff.

I could have made considerably shorter code to get this, at the expense of being more ad hoc (eg. leveraging the fact that the problematic sums are the coefficients of the lambda__ij(t) and thus acted on more easily via collect, or using the simple common structure of those sums, etc, etc). I deliberately avoided such here. I find chipping away at the more general problem far more interesting and worthwhile.

NB. Due how sort acts on the uniquified structure stored in kernel memory, invoking the code can actually change part of the original odes, in-place. (Assigning all results to a new variable may not always be strictly necessary, though I do it here.)

Download Format_odes_acc.mw

A second way involves using a single kind of sort call (which is more resistant to some weaknesses of the first way) and produces a uniform ordering with the inner sums (coefficients of lambda__ij(t) terms). The uniformity advantage is balanced by some extra leading minus signs in from of said coefficients. I haven't bothered to attach that right now.

It's a little tricky to code some of this because type(...,polynom) can catch too much in its net. And there are some wonderfully Maple-ish quirks of automatic simplification of coefficients when using collect, and fancy handling. Also fun because sign doesn't accept an order=plex(...) option akin to how sort does.

ps. I changes your original to assign a list to name odes, rather than a bare expression sequence (which I find to be error-prone for some people).

You were using the subscripted name T[S] as well as assigning a value to name T. That's a collision, and assigning to the latter clobbers your assignment to the former. You could use the name T__S instead of T[S], since it also renders subscripted in 2D Input, but is distinct from T.

If you want to use a subscripted name as the parameter of your operator then use x__2 instead of x[2]. (In 2D Input mode, that is x followed by two underscores, followed by the 2.)

Also, you were incorrectly using square brackets as if they delimited subexpressions. They don't. In Maple square brackets construct a list. Use round brackets to delimit to subexpressions (ie. term grouping, etc).

You don't have to construct T as an operator. You could also use just an expression. (See the two variants, below.)

Download TSL_bung_9_ac.mw

I was able to find it here, as a Post.

You can find your own postings from your profile page. (See also the Questions,Posts,Answers,Replies tabbed links).

You seem to be asking for sets, rather than lists.

I can't tell whether you mean M, or Sol. So I've done both in the attachment. You can change either back.

Systmes_Idea_ac.mw

If you're asking for something else then please explain in detail, thanks.

You write "RGB", but you only have a single Matrix. Usually RGB means three layers, for Red, Green, and Blue.

So I'll use your single Matrix for a HUE layer.

I'll do it in two ways:
1) replacing the COLOR Array, after a plot3d construction
2) using the image option of the plot3d command

Plot1_ac.mw

Here is one way to do that.

It's quite straightforward, and is terser still without the various beautifying options for plotting.

I'll use it a few times below, to get some slightly different effects,

>  restart; >  with(plots): with(plottools,transform): >  setcolors("Spring"): setoptions(size=[400,400], axes=boxed, axesfont=["Times",9],            labeldirections=[horizontal,vertical], thickness=3);   >  F := unapply([Re,Im](exp(x+I*y)),[x,y]);   >  PR := plot([seq([x,y,y=-Pi..Pi], x=-2..2, numelems=11)],            labels=[Re(z),Im(z)], gridlines=false):   >  PC := display(transform(F)(PR), gridlines):   >  display(Array([display(PR, tickmarks=[decimalticks,piticks],                        axis[2]=[tickmarks=spacing(Pi/4)]),                display(PC, labels=[Re,Im](exp(z)))]));   >  Did you want to make use of this? Perhaps in the labels on the right? evalc(F(x,y)); You could also show just the left-side (x<0), since it gives a more clear presentation for the circles mapped to [0..1,0..1]. Let's take just that portion of the above lines (keeping the same colors). >  PR2 := transform((x,y)->[ifelse(x>0,undefined,x),y])(PR):   >  PC2 := display(transform(F)(PR2), gridlines):   >  display(Array([display(PR2, labels=[Re(z)=x,Im(z)=y],                        tickmarks=[decimalticks,piticks],                        axis[2]=[tickmarks=spacing(Pi/4)]),                display(PC2, labels=Equate([Re,Im](exp(z)),evalc(F(x,y))))]));       >  setcolors(ColorTools:-Gradient("Red".."Blue",'best')):   >  PR3 := plot([seq([x,y,y=-Pi..Pi],x=-2..2,numelems=11)],             gridlines=false):   >  PC3 := display(transform(F)(PR3), gridlines):   >  display(Array([display(PR3, labels=[Re(z)=x,Im(z)=y],                        tickmarks=[decimalticks,piticks],                        axis[2]=[tickmarks=spacing(Pi/4)]),                display(PC3, labels=Equate([Re,Im](exp(z)), evalc(F(x,y))))]));

Download conf01.mw

The problem in your code is that your solve call returns two answers (both being sets) and you are passing the expression sequence of both of those as arguments to the simplify command.

That makes simplify interpret its arguments like a request for simplify-with-side-relations, which is the cause of your error message.

If you intend on trying to simplify both results from solve in a single call to simplify then you could pass them inside a list. That automatically maps simplify across the elements of the list. Note however that for this example there is no change in the results.

Here it is, using Maple 2019 (like you),

Download Q3_ac.mw

You can construct this kind of thing using nprintf.

Yes, the current convention makes it easier to visually distinguish between the 2D Math typeset output of the two forms, t__1 versus t[1].

For reference on that mn numeric element, perhaps see here.

The Fractals:-EscapeTime routines work with images, rather than plots. That allows for rendering which is much lighter on using GUI resources. Computationally, they attempt to use the Compiler (successful in the Julia or Mandelbrot cases), which is faster than even the evalhf mode fallback. Their computation is also parallelized.

In contrast the plotting schemes (basically, 2D densityplot, or a carefully oriented plot3d 3D surface plot) induce use of much more GUI resources (time and memory) for the rendering. And computationally, they attempt to use fast evalhf mode by default, but are neither compiled nor parallelized. The densityplot result looks a bit better, IMO, with less unnecessary whitespace around the plot than what plot3d plots have. But the rendering of densityplot results is often harder on the GUI than is that of plot3d, at a common higher resolution.

An advantage of doing it with actual plots is that one can easily see the code and formula being used for the iterative scheme. But if grid resolution is too high then the rendering may be too intensive, and the GUI can "go away".

The attachment shows your example (remove/adjust the sin(z) term if not wanted) using 2D densityplot. Various different grid resolutions are used, according to whether it's doing a single frame plot, a "traditional" animation, or an Explore. It doesn't call evalf explicitly (unlike the linked code you have) because the Julia01 procedure calls will get run under evalhf mode by the densityplot command.

julia01.mw

In your GUI Options menus, what does it say for the item:
   Interface -> "Open worksheets in"
?  Is it set to "New Tab", or to "New Window".

AFAIK, that setting is stored in the GUI preferences file in the field,
   MDIOnOpenAndNew
where "false" means open in a new tab rather than a new/separate GUI window.

Note that when you change the GUI Option via menus then you have to fully close and re-launch, to get a changed effect. Similarly, if you edit the preferences file with an external editor -- while the Maple GUI is open -- then fully closing the GUI will clobber the edits.

Note that this is not that shared-kernel stuff. That's about the Maple kernel mserver engines Those are separate processes (and non-Java, besides). This is about the Java GUI windowing.

I always have the option set to "New Tab", ie. MDIOnOpenAndNew=false in the preferences file.

I don't know whether you tried to import your preferences from M2024 (and that it failed to import your M2024 setting for this option), or whether your started from scratch with GUI preferences and perhaps overlooked setting this one.

ps. It's possible that this is not your underlying problem (or that it's not all working as intended). Apart from clicking the desktop launcher, the aspect I've described also controls whether File->New results in a new tab or a new/separate window. Is that File->New already behaving OK, while the launcher is not? If they are different then my first guess about this being a simple option setting issue may be wrong. (...and then I'd ask whether you can concurrently Open the same exact .mw file twice, or whether the exec line in your launch icon passes any special options to the executable, etc...).