but not yet clear to me:
- should 'trig.xls' be subject to a test, or do we have enough testing for trigonometric functions in other tests, e.g. that for complex numbers?
- how to deal with - construct tests for functions / ranges where 'long' and 'double' version have justified different results?
( how to build tests which allow / demand improved results, but accept 'double accuracy results' when using double datatype? )
( O.T. but to show that answers are read:
@John Denker, think you wanted to write 70742377520284**40**.275766 / 2^52 for the zero-point of cot(),
yes, I'm aware that π is irrational and even most rational values can only be approximated by bin-FP figures. My idea wasn't to blame the FPU for not being member of the mission impossible team, but to apply another understanding of the argument. If it's just a numerical value ... calculate the trig functions as good as we can, evtl. we can do a little better using long precision ( mean to have seen a 60 significant decimal digit value assigned to a **double** variable 'y' in code ), and evtl. we can do a little better accounting the periodicity of or mathematical substitutions between the trig functions ... not yet evaluated.
But if the argument obviously contains symbols for values which can't be represented, or functions like pi() which pretend to calculate a irrational or irrepresentable value 'as good as possible', then it's justified to achieve an 'as good as possible' result by taking the approximation error off the table ... if we can. wouldn't mind to open an issue 'can trig function calculations be improved?', but I'm not far enough in evaluating, and at the moment I'm busy with other issues. )
:-)
