On 5/27/22 9:26 PM, newbie nullzwei via gnumeric-list wrote:
In my double version tan(pi()/2) fails with 16331239353195370 instead of the reference 16324552277619072, tan(3/2*pi()) and the negative values fail too, exotic processor? messed up system? updated libraries??? how reliable are the references?
The issue has very little to do with tan() and everything to do with the representation of pi()/2. In any serious application it would be better to use tanpi(0.5) which produces #NUM! which is IMHO the right answer. Note that cospi(0.5) is exactly zero, as it should be. OTOH if for some reason we can't do that, the value of pi()/2 is 1.5707963267948966192313217 (to high accuracy). However an IEEE double cannot represent that; the closest it can come is 1.5707963267948965579989817 If you take the tangent of that (to high accuracy) you get 16331239353195369.755 for which the closest IEEE double is 16331239353195370. So I don't consider that a failure. I don't know where the claim of 16324552277619072 is coming from. I would also suggest that tan() is not the best way to frame the question. It would be better to look at cos(float(π/2)) or equivalently cot(float(π/2)), which are not quite zero. You can then use the nexttoward(,) function to step through the representable argument values. That produces a nice linear output, whereas tan() produces an output that is grossly nonlinear (indeed wildly non-monotonic). I suggest there's no point in worrying about tan() until you have figured out what you want to do with cot() and cos(). Note: The 'maxima' language has bigfloats which I find to be convenient for examining such issues. _______________________________________________ gnumeric-list mailing list gnumeric-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnumeric-list