## 28130 Reputation

17 years, 245 days

## query...

Does this not mean something relevant to your attempt to solve the 3x3 EqN system?

```newEqN:=eval(EqN,[lambda__1=v1,lambda__2=v2,lambda__3=v3]):

andmap(coulditbe,newEqN=~0) assuming v1>0,v2>0,v3>0;

false```

## LargeExpressions...

@MaPal93 There is also a Veil command in the LargeExpressions package.

That, along with `freeze`, can sometimes be useful. (But hiding dependencies upon variables might matter.)

## for fun...

@MaPal93 To me a tricky part of your Question is the bit about your wanting to find the optimal formulation (of some of t__1,t__2,t__3 in terms of some others, with other mixed terms).

I don't think that the temporary variables I showed is going to provide an avenue for that. At least, I don't see how it'd be any better than manipulations done using the tools algsubs, eliminatesimplify(...,{..}) aka "simplify-with-subrelations", or some basis generator.

But since you asked how it (ie. what I showed above) could be programmed, here is some fun. Some of the following is done a bit crudely. And there are more finesses possible.

 >
 >
 >
 >

 > n := 3; K := [codegen:-optimize([seq(t[i]=t__||i,i=1..n)], 'tryhard')]:

 > # Let's remove unnecessary name=name entries, # and rename them nicely. # (I expect this could be done more nicely.) newK := K: while ormap(ee->type(ee,name=name),newK) do   for i from 1 to nops(newK) do     if type(newK[i],name=name) then       newK := [ seq(newK[j], j=1..i-1),                eval(newK[i+1..-1],newK[i])[]];       i:=nops(newK)+1;     end if;   end do; end do; newK:=eval(newK,[seq(lhs(newK[i])=s||i,i=1..nops(newK)-3)]): (rules,forms) := newK[1..-n-1], newK[-n..-1]:

 > map(print,rules):

 > map(print,forms):

 > ## Let's reduce by the first five rules. eval[recurse](rules[6..-1], rules[1..5]): map(print,%):

 > eval[recurse](forms, rules[1..5]): map(print,%):

 >

## quotes...

@Carl Love The type checks you've used,  suffixed(x) and suffixed(x, nonnegint) , could fail if the name x itself were assigned. Now that I come to think of it, I suppose that the name suffixed is (alas) not protected.

So those type specs could all get wrapped in uneval-quotes, to guard against those cases.

## of course...

@sursumCorda I thought that my wording -- and what I computed, and how -- made it quite clear and obvious that it provided no guarantee that there were no other solutions. I did allude to the larger problem as being fundamentally different.

I showed it primarily because nobody (including you) had yet showed any way to programmatically generate the as-yet known five exact solutions.

## abs? Psi(t)?...

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).

## of course...

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

## ok...

 > restart;
 > RealRange(-infinity,infinity):='RealRange(-infinity,infinity)':

The above assigned to the remember-table of RealRange.
The effect is that this call returns unevaluated, and it can
then get successfully converted to relations (inequalities).

 > RealRange(-infinity,infinity);

 > convert(x::RealRange(-infinity,infinity), relation);

 > func := 2*x: r1 := solve(func < 0);

 > r1r := Or(`::`~(x,[r1])[]);

 > r2 := RealRange(-infinity,infinity);

 > r2r := Or(`::`~(x,[r2])[]);

 > allr := And(r1r,r2r);

 > result := solve(convert(allr, relation));

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.

## lambda=0, or T=0...

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?

## another example...

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

## various...

@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.

 > restart;
 > r1 := solve(x^2-1 > 0);

 > r1r := Or(`::`~(x,[r1])[]);

 > convert(r1r, relation);

 > r2 := solve(x > 10);

 > # For consistency, we could also use this # as   r2r := Or(`::`~(x,[r2])[]); r2r := x::r2;

 > convert(r2r, relation);

 > allr := And(r1r,r2r);

 > convert(allr, relation);

 > solve(convert(allr, relation));

 > Now, another way (some parts trivial, of course). The And@op is not needed for this example, but in general there could be more that one inquality in each of several alternative solutions returned by solve. So group those solutions by And -- even if not necessary here. restart;
 > s1 := solve(x^2-1 > 0, {x});

 > p1 := Or((And@op)~([s1])[]);

 > s2 := solve(x > 10, {x});

 > p2 := Or((And@op)~([s2])[]);

 > solve([p1,p2]);

## for me......

@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...)

## indeed...

@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.

 > restart;
 > kernelopts(version);

 > ee:=[1/(4*a + z^2 + (z^4 + 4*a*z^2)^(1/2)), -1/(z^2 - (z^4 + 4*a*z^2)^(1/2) + 4*a)];

 > factor(ee); int~(%,z);

 > simplify(ee); int~(%, z);

 > evala(ee); int~(%, z);

 > rationalize(ee); int~(%, z);