It sounds like you're seeing this problem.

I suggest that you use the settings as I described in that previous thread's Answer, but also with (the default),

    interface(typesetting=extended):

The Y[i] in the result from convertsys are not the global names Y[i].

You could instead work with convert(sys0,`global`), as one simple way to replace those names.

Download nature_frequency_question_ac.mw

ps. I did a similar thing just a few weeks ago, in order to substitute for such names.

There are lots of ways to get such a construction. Here are a few.

Download grad_f_ex.mw

Another way is to use the n=i for tickmarks along the vertical axis placed at the right.

Here are some ideas along those lines. I wasn't sure how much of the rest of the stylistic elements from your image you wanted to mimic. There is also a version in the attachment with gridlines, but no left-axis. It's your choice of how you want to mix and match such features. (If you have difficulty please just state exactly what look&feel you want.)

S7MAA_Dveloppement_Limit_ac.mw
 

Looking at the structure of the inert integral representation of the PDF (GG in the attachment) then it's not clear (to me) how an elliptic special-function would not appear in the result of symbolic integration.

But, you can reformulate and get rid of the I appearance. (That instance is not the only contributor of imaginary values here, and is countered by other contributors for which the I doesn't appear explicitly.)

And you can also force some simplification and a specific integration method for which the final integration result is much simpler. But, still an elliptic special-function.

Here, I use Maple 2023 (as you did).

Basics_ac1.mw

This site is not letting me inline my attachment right now. But the simpler result is,

    8*EllipticK((-2 + t)/(t + 2))/(Pi^2*(t + 2))

which evaluates to purely real values (for any real t),

and its plot is,

which doesn't have the unfortunate gaps where your plot of your y expression runs into small imaginary float artefacts which are still large enough to disrupt the plot driver.

ps. You also wrote that, "Even a numerical solution would be fine." But you already have a plot. And you complaint is about the formula. So what does "a numeric solution" mean, in that case!? Do you mean that you would be OK with, say, an approximating rational polynomial with float coefficients?

You get so much numeric error that the implicitplot(s) appear empty if the working precision is too small.

You can get noise (and false implicit level-curves) if Digits is increased but still too low.

If you're lucky you can hope that you can find a high enough setting for Digits to that the numeric error is small enough that you get a decently representative implicitplot.

PLOT11_ac0.mw

In the following plot the blue curve is the implicitplot of the imaginary component of your expression, and the red curve is the implicitplot of the real portion. That is using Digits=50.

It might also be possible to rearrange the expression (or terms in it) and so improve the numeric error situation. I didn't try.

You could compare with results in other Answers threads posted so far, but I am not sure that adequate working precision was used throughout. As explained in my worksheet, raising Digits can get you some results rather than your original empty plots, but it might not be enough (in which case spurious zeroes might even be "found").

As dharr noted, the situation might possibly be further improved if you used higher working precision while forming your mixed float/symbolic expression -- though we have been given no clues at all as to how it was formed. Possibly even better might be if you had an earlier purely exact symbolic expression (with no floats at all), which might be manipulated and then evaluated to float numeric with less running error. We cannot know any of that, being quite in the dark.

In your first attempt you forgot to load the inttrans package (like you did in the second attempt).

So the invfourier calls in the first attempt don't resolve to anything -- it's just an unassigned and meaningless name.

If you add the command,
   with(inttrans):
to the first attempt (just like it is for the second attempt) then it works.

nb. You could also apply the assumptions that dharr suggested. But that is not strictly necessary, in order to get actual plots in your problem case. Whether you also do that depends on what specifics you want for your alternative approach(es).

But the missing with(inttrans) was what was preventing it from working altogether.

It looks as if, somehow, your GUI setting for the level of pretty-printing of Output has become 1 (ie. plaintext character notation).

Not only is that unwanted, but for some years now it doesn't even work as it ought to due to some muddle with typesetting level. ie, interface(typesetting).

Anyway, you can check that thee Output setting is wrong by looking in the GUI Options menu, at the
    Display -> Output display
item which normally is
    "2-D Math"
but for you might be wrongly set as, say, "Character Notation".

If you set it to "2-D Math", and then close the menu by clicking on,
   "Apply Globally"
then you ought to be good to go. That should store the option for future GUI sessions.

You can also check that it's wrong by issuing the command,
   interface(prettyprint)
which I suspect would have returned 1 (ie. one) when in that wrong state. You can manually/programmatically set that in a session, but it's unclear how that affects what setting value the GUI saves when you close it.

My guess is that you are using 2D Input mode and that you have the right-panel (aka context-panel open), and that placing the cursor (mouse/pointer focus) in that input causes it to evaluate.

You could collapse the right-panel entirely, using the double-chevron appearing near it stop in the GUI.

Or (even with the right-panel open), you could execute the command,
     _EnvSubexpressionMenu := false:
say at the top of your sheet (or after explicit restart).

Either of those seem to remedy the situation, for me, in Maple 2025.

I will submit a bug report.  There is an internal list of things for which not analyze subexpression menu items (or context-panel suggested actions), and it looks like this belongs in it (because it acts in-place on first argument M; ie. has a side-effect on it).

You can make the conditional test the argument of a procedure.

That gains you the flexibility of being able to make different/arbitrary queries involving multiple variables and conditions.

color_Q.mw

colortf := (ee::boolean) -> nprintf(`#mi(%s, mathcolor=%s)`,
              ifelse(ee,["true","red"],["false","blue"])[]):

x1 := 1: x2 := 4:

colortf( x1 > 1 );
                   false

colortf( x2 > 1 );
                    true

colortf( x1 > 1 or x2 > -5 );
                    true

colortf( x1::odd and x2::even );
                    true

colortf( x1 > -6 and x2 < 3 );
                   false

You could also utilize the is command, rather than evalb, (which `if` and ifelse use by default) to test the conditional. That handles the earlier examples but also allows testing of inferences based on assumptions or involving some symbolic inequality.

coloris := proc(ee::{boolean,`::`}) local p,r;
             r := is(ee);
             if r=true then p := ["true","red"];
             elif r=false then p := ["false","blue"];
             else p := ["FAIL","black"]; end if;
             nprintf(`#mi(%s, mathcolor=%s)`,p[]);
end proc:

coloris( x1 > 1 );
                   false

coloris( x2 > 1 );
                    true

coloris( (2*y+1)::odd ) assuming y::integer;
                    true

coloris( y > 3 ) assuming y > 5;
                    true

assume( w > 6 );
coloris( y + w > 10 ) assuming y > 0;
                   false

coloris( f(y) > 0 ) assuming y::posint;
                   FAIL

You could have a look at the DEtools[convertsys] command.

Download convertsys_ex0.mw

You could also use LinearAlgebra:-GenerateMatrix as one way to express the new equations in Matrix form.

Is the output of such expressions also suboptimal?

Sorry, all I can think of offhand is a way printed results might look better in this regard. Eg, using Maple,

Download conj_pr.mw

Do you have the ability to add an arbitrary Favorites palette entry? (just wondering about an idea...)

The Describe command uses the printf facility, which is not the same as regular print.

Perhaps you could instead get by with,

   op(5,eval(timing))

which programmatically returns the description portion of a procedure.

Or you might explicitly print that, if within some other procedure body, ie.

   print(op(5,eval(timing)))

ps. I haven't double checked where Flow puts print'd or even printf'd display. I replied mostly because you wrote "print".

On my Linux machine a local-disk installation of Maple 2025.0 (running the already downloaded installation file, from a local account, into a local host location) took about 2.5 mins on a somewhat old Intel Core-i5.

The same installation from downloaded file, from&to an nfs mounted location, took about 8.5 mins.

Over the years I've noticed a few items like tensorflow, curated data, and pre-computed large Group Theory data files can take up large amounts of space and slow down the install. But the biggest change seems to be that the maple.help Help database step takes longer (about 45sec).

Some major releases ago I could do a local install in less than a minute. Eg. purely local disk install of Maple2020.2 takes 50sec on the same machine.

Your main problem is that when you call Median(f) or Percentile(f,50) you haven't let it know that you intend on f being interpreted as a Probability Density Function.

Download Median_ac.mw