Hi, Sebastian Macke:
following code snippet
cln::cl_F x = cl_float(0.5, cln::float_format(50)); x = cos(x); cout << "\n" << x << "\n"; x = x + cln::cl_F(1.); cout << x << "\n";
gives the output
0.8775825618903727161162815826038296519916451971097440529976L0 1.8775825618903728d0
This is normal, expected, and a feature.
Is there a feature that the float with the highest precision is used as the result precision?
No, as this would be a misfeature. Consider this: cln::cl_F x = cl_float(0.5, cln::float_format(50)); x = cos(x); cout << "\n" << x << "\n"; x = x + cln::cl_F(1./3.); cout << x << "\n"; Currently CLN gives the output 0.8775825618903727161162815826038296519916451971097440529976L0 1.210915895223706d0 With your suggestion, it would give the output 0.8775825618903727161162815826038296519916451971097440529976L0 1.2109158952237060309458978388512206449311173955960721779976L0 <=== but the correct result of cos(0.5) + 1/3 is 1.210915895223706049449614915937162985324978530443077386331L0 So 1) The result marked with "<===" would have way more wrong digits than correct ones, and you have no way to know it just by looking at the result! 2) If you continue to do computations with that result, two third of the computation time will be wasted with treatment of garbage digits. In other words, your proposed result would have an accuracy that is much lower than the precision. However, the expectation for a final result is that the the accuracy is equal or nearly equal to the precision. Bruno