On 4 June 2012 14:50, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 06/04/2012 01:31 PM, Olivier Galibert wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Jun 04, 2012 at 01:11:13PM -0700, Ian Romanick wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Ian Romanick<<a href="mailto:ian.d.romanick@intel.com" target="_blank">ian.d.romanick@intel.<u></u>com</a>><br>
<br>
In single precision, 1.5707963 becomes <a href="tel:1.5707962513" value="+15707962513" target="_blank">1.5707962513</a> which is too<br>
small. However, 1.5707964 becomes <a href="tel:1.5707963705" value="+15707963705" target="_blank">1.5707963705</a> which is just right.<br>
The value 1.5707964 is already used in <a href="http://asin.ir" target="_blank">asin.ir</a>.<br>
<br>
NOTE: This is a candidate for stable release branches.<br>
</blockquote>
<br>
If piglit stops bitching on that partical problem thanks to such a<br>
small change, it's just beautiful.<br>
</blockquote>
<br></div>
It does fix the acos issue in piglit. The closed-source test suite that we use still isn't happy, but I think that just means we need better approximations for acos and asin.<br>
<br>
asin(vec4(.2, .6, .8, 1.)) has an absolute error of (0.0000105351 0.0001987219 0.0001262426 0.0000003576). The results for .6 and .8 are especially bad, but even the .2 result should be better. The closed-source test suite wants an absolute error of 1e-5 for asin and acos.</blockquote>
<div><br>Do we have any quantitative information about how much accuracy is really needed for asin? Of course, an error of 1.9e-4 would be embarrassingly bad for scientific use, but are you sure that it isn't adequate for graphics purposes? I'd hate to spend a lot of effort implementing a more accurate asin, only to find that the only user-visible effect is for shaders to run slower because we're doing more accurate math. As fun as it is to numerically approximate trig functions (I'm not even kidding--I love this stuff and I'm jealous that I don't have time to work on it right now) I'm not convinced it's worth it yet.<br>
<br>Having said that, I *do* think it's worth making sure the asin function is well-behaved enough near zero that derivatives won't do unexpected things. If you do wind up working on this, I hope you'll keep the improvements I made last july (d4c80f5f85c749df3fc091ff07b60ef4989fa6d9) where I made the first two terms of the approximation pi/2 and pi/4-1. If these terms aren't exact, then asin behaves poorly near zero.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do we need a better precision atan, or should piglit just be told to<br>
shutup? The shutup patch has been sent it ages ago, but I can't do<br>
the "more precision" one if that's what's wanted.<br>
</blockquote>
<br></div>
I think we need a better atan. The result that it produces is not very good. I plan to look into that more tonight.<br>
</blockquote></div><br>FYI, our formulas for atan and acos are exact trig identities in terms of asin, so probably any improvement made to asin will carry over to the others, at least until you reach the realm of rounding errors (which I'm guessing you won't reach if your target is 1e-5).<br>