Choosing your non-constant alpha and beta non-arbitrarilyEdit
It seems that the accuracy of the estimate depends both on your choice of alpha and beta, and also on the magnitude relationship between a and b in the sqrt(a^2+b^2). Im just wondering how we might take a look at a and b beforehand, and choose a more optimal alpha and beta for the situation.
Is there a way to polish the solution?Edit
Is there one wrong parameter set?Edit
The parameter set alpha=7/8 and beta=15/16 can't be right. I tried to plot that and the graph looks completely different. My guess is that this should have been something like beta=15/32. Most beta values are close to 1/2.
Examples don't seem practicalEdit
This formula is extremely useful, but I have a question: Why are the examples not very good approximations of the ideal alpha and beta? For example, alpha = 31/32 and beta = 13/32 outperforms all of the other examples, and (similarly to most of the others) only requires 2 multiplies and one shift to apply those constants, with similar bit-depth requirements.
It might also be worth showing how well 16-bit approximations do (i.e. alpha = 62941/65536 and beta = 26070/65536). Many archetectures have extremely efficient and/or SIMD-able 16-bit multiplies, and those values do an excellent job.
- Well just as an example (7/8, 7/16) can be done just using 2 shifts, 1 add and 1 sub:
len = mx + (mn >> 1); len -= (len >> 3);
- I agree that it would not hurt to add the 16bit approximation as well --184.108.40.206 (talk) 22:26, 13 June 2011 (UTC)
Wouldn't it be better to add a polar plot with the results of this function? as it more intuitively shows how this formula works. (a polar plot will show an octagon)220.127.116.11 (talk) 10:19, 12 August 2013 (UTC)
- It wouldn't be a polygon: here is the plot for close to optimal values: Plot on wolfram alpha — Preceding unsigned comment added by 18.104.22.168 (talk) 13:59, 24 April 2014 (UTC)