What you have to do with my last answer is

Extract the coordinates and combine them in a way that they can be plotted with pointplot. Here are two ways

Solusi5(2.979);
pointlist := [[op([1, 2], %), op([2, 2], %)], [op([1, 2], %), op([3, 2], %)], [op([1, 2], %), op([4, 2], %)]];
rhs~(`%%`);
pointlist := [seq([%[1], %[i]], i = 2 .. 4)];
plots:-pointplot(pointlist);

Since you are already using some advanced commands it would be advisable to study also basic commands to manipulate expressions . I hope this helps

@Carl Love 

I get still the old box

@MaPal93

Solve without assumptions, as I understand it, returns solutions in the complex domain. Such solutions are of course valid for your assumptions since they only restrict the complex domain.
I would plug in some numbers to see

• if the solution becomes complex valued (I don't think so)
• and if there any souspicious names left

You can also use anames and unames to check for typos in names. 

About index subscripts: Theoretically it should work what you are doing. I simply have no experience and here are many questions that are related to the wrong use of indexes as subscripts. To stay away from those problems you could remove the brackets and the colon in rho__v[1, 2].

Personally, I use assumptions at the latest possible state to keep the solutoins as general as possible, which sometimes is not the best strategy since it can complicate expressions at an intermediate state to the point the a later simplification  does not work. It depends on the problem.

(The realdoaim package might be an option for you which avoids explicitly typing all assumptions.)

I am still not sure if assumptions are needed in your case since

• you got a general solution
• simplify with your assumptions does not simplify the solutions
• and the assumptions are independ from each other. It would be a different story if the assumptions would add  new algebraic constraints

Assumptions are beneficial for transcendental functions or non elementray functions. I Your case I do not see those. In what way you expect the general solution to change with your assumptions (shorter, simpler, piecwise with ranges,…).

@ Try

Solusi5(2.979);
 [t = 2.979, A(t) = 7490.84882618914, S(t) = 1594.24943917620, 

   l(t) = 4045.84836636772]

@Anthrazit 

Looks like a database comparision. Maybe the antivirus flags all software components that are outdated as high risk without any further evidence. Outdated software is a risk but also new versions can come with new risks. The key question is: Is there evidence of a security risk (this is not excluded: see below).

I have experience with 4 antivirus packages. Only one reminds me of outdated software but never mentionned Maple - so far.

That is something to bring to the attention to the IT responsible who introcued the new antivirus. He will most likely tell you not to use Maple anymore. :-(

Or if you are lucky he investigates the potential risk.

On the other hand only Mapelsoft can tell wheter the below is possible

I only find two files on my system which do not look threatfull.

What exacly does the Anitvirus list?

A server itself can be a threat. Are servers listed?

@acarchau 

Labels uniquely identify plot output. Is that what you are looking for?

from
https://www.maplesoft.com/support/help/maple/view.aspx?path=plot%2foptions

Otherwise you can use plots,textplot to place tags on your own.

@vv

This explains another behavior (attached) I could not find an explanation for... I should have tried 2022 earlier.

By the way: is(w = conjugate(w)) is on all my installations falsely true. So no regression as in your other example

Thank you.

 Simplify_elliptic_in_real_domain.mw

@Roy Hughes 

All what you see on the screen goes through a quite complex rendering process with many hard and software components involved. A good part of these components are third party (i.e. not under the control of Maplesoft, like OS components or graphic card drivers). What is saved in a Maple file and its representation in the Maple server is not what you see on screen. The Maple GUI (a separate software written in Java) is reponsible for rendering your input and the output from the Maple server.

I your case at a certain point the character sets get mixed up. On two windows 10 installations I have noticed (sometimes) a difference in rendering depending on the graphic card and the mode the graphic card operates. Depending on the system settings the graphic card in use for rendering can change (example: switiching between internal Intel graphics and a graphic card). 

In your case, it would be interesting to know which operating system is involved and whether input and output are affected in a similar way.

The fact that the rendering is as expected after a restart (of Maple or the whole system?) indicates that the system starts Maple in a correct way with all involved software and hardware components are configured correctly. Then (probably after some time running Maple) something changes the configuration. Maybe you remember something that happend before the occurence of the character change. This could give a hint of the cause.

@Thomas Richard 

Of course. It's a while ago that I used it and now I was searching under support

I found it finally. No crash any more with the attached. Maple 2023 requires right single quotes.

The GUI crash is another matter. Should not happen with incorrect input (IMO).

plot3d_in_2023_not_working_solved.mw

On a different PC:

No freeze before installing the lastest Physics package. Conversion to 1d works.

Preview in context pannel indicates ndash

After installation: Expected preview but freeze when doing right clikc convert to 1d input

@Christopher2222 

I was wondering if the type of graphic card could be retrieved as well. Is that possible?

@vv 

That is a nice debugging trick. (Copy paste in a startup code region works as well.) I will use it to track down at which point my original worksheet changed or changes.

What I know so far is that the ndash originates from Maple output (i.e. I never entered it). It might be related to the use of equation labels and it only manifest in Maple 2023. It can be that Maple 2023 generates a ndash when executing a document. I will send an update if I find something.

It's the first time I could not debug with lprint or convert to 1d (and the Maple GUI crashes). Thank you for your help!

All outputs removed and Maple GUI frozen.

(I am experiencing upload and editing problems. So I have to reply to myself to update the post)