@Carl Love 

Thanks. I know and I have also used SolveTools:-SemiAlgebraic. Both could be better and faster.

Thank you for this info!
I see that the Risch algorithm works indeed better when the radicals are expressed as RootOfs, and even in older versions (e.g. Maple 2015). So, I wonder why the conversion is not automatic (at least as an option in int).

@nm 

It is a standard parametric plot. plot( [sin(t),sin(t),  t=0..420]); So, x = sin(t), y = sin(t), t in the interval [0,420].
 

Nice, vote-up.
Note that a geometric solution is much simpler:

1. An ellipse is the orthogonal projection of a circle.
2. A triangle inscribed in a circle has maximal area iff it is equilateral.
So, an animation is given by:

a:=4: b:=sqrt(3): B:=plot([a*cos(t),b*sin(t), t=0..2*Pi], scaling=constrained):
plots:-animate(plot,[[seq([a*cos(t+2*k*Pi/3),b*sin(t+2*k*Pi/3)], k=0..3)]],t=0..2*Pi, background=B)

@Carl Love 

I know, but for small x (otherwise ln1 is useless) even series is much better than calling ln.

@Carl Love 

My point is that evalf/ln1 should use a special algorithm for ln(1+x) (e.g. via series) being so much faster. BTW, Digits=64 in ln1 is enough for OP's example.

@Carl Love 

Note that this way in OP's example the procedure evalf/ln1 uses Digits=91 (!). So, what it does is:

evalf[32](evalf[91](ln(1+exp(-64))));

All these symbols are defined here: https://en.wikipedia.org/wiki/List_of_mathematical_symbols

It's a matter of preferences and definitions/notations, rather than ambiguity. Even N could represent {0,1,...} or {1,2,...}, but the exact definition is clear from the context, or reminded in the case of a serious textbook or article.

@Carl Love 

It is unfortunate that they are not documented.

restart;
f := x -> sin(2*x)+3;
g := x -> sin(3*x)+6;
a:=0; b:=5;
plots:-animate(plot3d,
[ [ [a+t*(b-a), f(a+t*(b-a))*cos(u), f(a+t*(b-a))*sin(u)], 
    [a+t*(b-a), g(a+t*(b-a))*cos(u), g(a+t*(b-a))*sin(u)],
    [a, (f(a)+t*(g(a)-f(a)))*cos(u), (f(a)+t*(g(a)-f(a)))*sin(u)],
    [b, (f(b)+t*(g(b)-f(b)))*cos(u), (f(b)+t*(g(b)-f(b)))*sin(u)]
  ], 
t=0..1, u=0..U, transparency=0.3, grid=[40, max(2,floor(7*U))]
],  U = 0..2*Pi, axes=none,  paraminfo=false);

@Carl Love 

Please note that I have mentioned the sfloat->hfloat->sfloat conversion from the beginning. My impression was that the OP obtained the result in a evalhf environment and it was distorted. But now I see that he used a higher precision and wants to save the result as hfloat. For this of course it's enough to save it as float[8] without any evalhf or option hfloat.

@AOdrzywolek 

You are wrong here. It is proved mathematically that a long double can be exactly retrived (each of its 64 bits) using 18 decimal digits (it is irrelevant how it was obtained). [ The fact that to obtain n correct digits with a math function you may need Digits>n is quite another thing: after the computation you save evalf[18](result) ].

@AOdrzywolek 

You can use Digits=18. Then it seems the bug does not occur. But for portability, Carl's advise for ASCII is a better solution (even if the file could be up to 3 times bigger).

@Carl Love 

Sorry, but I cannot agree. I still think that it's a bug; probably even the the 20 digits display for subnormal hfloats is not intended.

Why should we decrease Digits when using evalhf? For "regular" hfloats, everything is OK. 

@Carl Love 

Note that evalhf displays 18 digits. That's because this way the exact hfloat representation can be retrived.

Digits:=10:
evalhf(123456.7890123456789);

        123456.789012345675

I don't see any contradiction using evalhf when Digits is 30. It could be e.g. a partial result, or a first approximation.

@Axel Vogt   Sorry, I don't know.