@MaPal93 Please don't start another separate Question thread for this.

The degree call fails because of the presence in its numerator of abs(Psi(t)) and other abs calls containing Psi(t).

That is the significant problem with your question.

Also, the numerator of your expression contains the capitalized term Psi(t). Is that deliberate?

Also the denominator of your expression eq contains the term psi(t). Is that deliberate?

Once you sort out these usage mistakes and syntax muddles, note also that Psi has a predefined and special meaning in Maple. Eg, Psi(0.3) produces the value of approximately -3.503. If you want to use the name Psi as if it were not predefined then you could put the declaration,
   local Psi;
at the start of your worksheet (after any restart).

@sursumCorda There will always be plenty of scope for improvement in any significant piece of software.

@Carlos36r 

Download ineq_rel_Carlos_real.mw

I don't really understand why you're taking this approach altogether. It's a very roundabout way of calling solve, that could be done directly, otherwise. I only showed it originally as example of conversions either way -- not as an ideal way to utilize solve.

How do you feel about the solution 
   lambda=0, h=T, T<>0
?

What about the following (where h is real for lambda<0),
   T=0, h=-(6*14^(2/3))/(7*(-lambda)^(1/3))
?

Do you need purely real solutions? Do you have any restrictions on the variables?

Here's another example, with irregular spacing in the x-values. I'll take it as given that the x- and y-values are already suitable sorted.

It's a little tricky to get the forced tickmarks to be just right. For one thing, the GUI refuses to add an x-tick if it's too close to a default-generated y-tick. So some compromise is needed.

But here are some variants. I don't want to get bogged down in a really complicated procedure to figure out nice, evenly spaced, rational forced/faked x-tick values, etc.

plot_2_ac.mw

@Carlos36r Hopefully this capture all the flavours in which you're interested...

Hopefully all readers of this will realize that this is an exercise in post-processing of solve results, and reformulating as equivalents. Naturally we could more easily pass the original arguments into one solve call, directly.

I duplicated a few steps, just for clarity's sake.

Download ineq_rel_Carlos.mw

@DEE_Engineering It's a preference.

Sometimes when I'm doing things similar to this I also want some additional effects, and when customizing & debugging I sometimes find aliases get in my way. I have a very low tolerance for any need for extra typing when probing, etc.

Here's a difference that may (or may not) matter for your tasks related to this: If you line-print (lprint) or convert to a string then the way I used will produce something with the actual words sin and cos. I often prefer that; you might not, here. Using that alias(s=sin,c=cos) then the line-printing will contain s and c.

note: this is not the reason that I don't use alias. But it's a possible reason that you might want it here, if you want the s/c effect in exported 1D formulas.

So, do you need to export your outputs as 1D plaintext formulas? (If you do, it would have been more useful to have mentioned that requirement at the outset...)

@sursumCorda Indeed, using evala, radnormal, or even rationalize to get the radical in the numerator will work here.

Surprisingly, even factoring the expression inside the radical (while keeping it in the denominator) works too.

I'll add all this to the bug report.

Download gosh.mw

@NurinFYP As you've already been told (by two other people), actual code is key to diagnosing your difficulties.

That is especially true of 2D Input mode (which you are using) since there are some cases where different code renders very similarly, eg. beta__i versus beta[i] .

It's inconsiderate and unhelpful of you to continue showing only images of your followup difficulties, without actual code that can be used without having to retype it all based on an image.

You should upload and attach a link to your worksheet, using the green up-arrow in the Mapleprimes editor. You should do this each time you ask a followup query for some new difficulty.

@Christopher2222 My example -x^3-x^2+x-1 was not posed as a mere presentation challenge.

There are other ways that can handle mere presentation for both it and other flavours, in a more automatic and flexible manner, IMO.

But that was not my point. I mentioned it specifically because it's another class that cannot be transformed via sort into something that gets pretty-printed without a leading negative because of the way it's stored internally.

@Christopher2222 No, you are mistaken. Your suggestion to use subs would not work on the example I posed.

The most important thing about my example (which your response overlooks) is that if the original form has already been created in a session then the target form gets uniquified to that by the kernel's fundamental behavior of storing in memory only a single instance of a sum of terms. There are only a few mechanisms that can prevent that -- sort is one of them, and subs is not.

It doesn't make any difference what usual mechanism you use (subs, or whatever) to create
   b*(a - Q - a*sqrt(f)) - b*(a - K - a*sqrt(f)) - b^2 - 1
because if the earlier form has already occupied the kernel's internal uniquification table for that session then this new reformed instance will merely get represented in the earlier manner (and not that desired manner).

So, for my more general example, you cannot reform the original (as an actual expression) unless you can replace it as the uniquified version stored in memory in that session. The sort command has that memory-in-place replacement power, but I don't see how sort can be used to make the whole reformulation in question.

That's a big reason why I chose that particular more general example -- because I suspect that sort (as outer call) cannot be used to do the required replacement. My point was that there are some examples which cannot be handled as easily as the OP's originals.

Here's another difficult flavour of example:
    - x^3 - x^2 + x - 1
Do you think that you could get that reformulated with the +x term as the leading summand?

And such examples are why I also hinted at merely printing the target form as a possible general alternative, using typesetting or other kludges.

@achreftabet 

You can use this list of eqautions to perform the reverse operation.

  invrepl := map(u -> u = u(t), [r, Z, U, V, W, S]);

  eval([seq(eq || i, i = 1 .. 6)], invrepl);

See attached document,

problem_1_ac.mw

You could change t to theta, if that's what you'd prefer.

problem_1_ac_theta.mw

Please don't put a followup query about doing the reverse of this in a wholly new and separate Question thread. Just mention it here, instead, if you need that.

@Anthrazit Yes, that's exactly what I meant, merging like,

   display(F, draw(B))

ps. Naturally, you don't have to use an embedded component