Nice, but not reproducible for me (with modified color option)

a := 5;
b := 1;
h := 7;
alpha := Pi/2 + 1/tan(3/2);
plot3d([(a + b*cos(u))*cos(v) - b*cos(alpha)*sin(v)*sin(v), a + b*cos(u)*sin(v) + b*cos(alpha)*sin(v)*cos(v), b*sin(alpha)*sin(u) + h*v], u = -2*Pi .. 2*Pi, v = -2*Pi .. 2*Pi, numpoints = 2000, style = surface, color = "DarkRed");

Could you share the plot command you used?

As vv and sand15 indicated in an earlier post it would be nice to get a little more background.

@Nicole Sharp 

I agree, renaming (and hiding labels) would clean up documents without the need of unnecessary temporary variables.

What might interest you: Hiding is hiden but possible.

@Thomas Richard 

It's a specific file. I will send it.

The freeze looks like that (with a Windows hourglas not visible on the screen shot):

The taks has to be killed.

Thank you

@Thomas Richard 

One reason it is less popular may be the description. I am one of those users for whom "evaluate in an algebraic number (or function) field" does not indicate that this command is useful for simplification tasks of expressions.
I will experiment with it.

@QM I could not resist to ask the new kid on the block

I skip the intermediate steps

I am not sure if this "simplification" is correct. At least I could not simplify it with Maple

;-)

@acer did mean that in your first code snippet?

cot(Pi/2 - alpha/2);
                             /1      \
                          tan|- alpha|
                             \2      /

@Thiago_Rangel7 
Convert comes with new options for trig functions. In this case

convert(1/cot(a), tan);
                             tan(a)

does the "simplification". There is also sincos and more.

@Kitonum 

Both ways are of value for me. I will use the way of @ecterrab for old code where I solved for sin and cos to get the arguments for arctan(y, x).

For new code, convert is better if the code is shared between platforms.

Thank you both

Can you say for which images? I could imagine that such a function would be useful for background images of plots and image outputs of imagetools routines.

@acer 

I see the complication. I have to go back to cases where I retrospectively realized that a warning would have helped. Maybe I can come up with something better than “always working” (which I definitely do not want).

What still surprises me is the dependence on the input mode and the way the restart is performed. I have made more observations on that.

@Scot Gould 

Warnings in Maple 2023 can help with guessing.

(int,allsolutions does not work in this case).

Thank you

@Carl Love 

Using execution with
the warning only appears when restart is within the input region with the int command in

Download int_warning_2D_doc_blocks.mw

Using the warming also appears when a restart is executed in a separate document block.

If an interface command is added to the worksheet, the warning appreas also without a restart when using in

Download int_warning_2D_doc_blocks_with_interface.mw

@acer

Thank you for your detailed answer. I appreciate it very much.

Comparing the two elliptic integrals of the previous and this question reveals important differences. With delayed evaluation using ‘ ’ fsolve immediately evaluates numerically (which is the purpose of fsolve). What amazes me is the difference in computation time that changing the integration variable makes from the previous integral to the integral of this question. I did not realize this when you first demonstrated this.

Without delayed evaluation fsolve throws an error in one case and in the other it attempts to solve the integral symbolically, which is unsuccessful without key assumptions. This case “runs forever”, finally returning after 15 minutes the following unevaluated:

Concerning operator calling sequence in a call to plot:
In ranges_as_assumptions.mw f(x__0) in a plot call worked as well.  Plot seems to be smart enough not to evaluate x__0 as a name which is not the case for fsolve (without delayed evaluation).

Unapply vs assuming inside fsolve:
The approaches are equivalent in the sense that they both use successfully the method ftoc for symbolic integration to provide an expression that fsolve can process very efficiently. Therefore, I believe that these approaches are preferable to a delayed evaluation (at least for the cases we have discussed here).

However, I don’t know how exotic the cases are and if they would justify an enhancement of fsolve. That’s why my question was about whether fsolve could try to use ranges (or intervals) as assumptions for symbolic evaluation before applying numerical methods. This could be done implicitly (fsolve gets smarter as plot did in the past years) or explicitly with an option.

What I do not understand: Why does fsolve not treat f(x__0) as plot does (i.e. delay evaluation and avoid x__0 being evaluated to a name)? This could be an additional enhancement of fsolve.

@Scot Gould 
Yes, fsolve was updated according to fsolve,details and efficiency must have been one of them.

By the way, solve can solve the integral with an appropriate upper bound

((2*sqrt(alpha) = int(1/sqrt(sin(x__0) - sin(x)), x = 0 .. x__0)) assuming (0 < x__0 and x__0 < Pi/2))

@Scot Gould 
Thank you. This is inline with my "discovery" above. I have tried this unsuccessfully in the past.

Do you have any idea why delayed evaluation

g := alpha -> fsolve('f(x__0) = 2*sqrt(alpha)', x__0 = 0 .. Pi*1/2*0.9);
g(2);

does not work in the original problem inverse_function_with_fsolve.mw