Jump to content

Talk:Alpha max plus beta min algorithm

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 92.76.235.178 (talk) at 22:26, 13 June 2011 (Examples don't seem practical). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Is there a way to polish the solution?

Is there a way to compute a new estimate of hypot from this starting condition like is done with typical sqrt algorithms? --Jaded-view (talk) 03:29, 5 June 2008 (UTC)[reply]


Is there one wrong parameter set?

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.

TomF —Preceding unsigned comment added by 77.191.238.62 (talk) 22:56, 26 December 2008 (UTC)[reply]

This has now been corrected to alpha = 7/8 and beta = 7/16. Gaius Cornelius (talk) 12:06, 2 September 2009 (UTC)[reply]

Examples don't seem practical

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.

Nathaniel bogan (talk) 18:52, 27 January 2011 (UTC)[reply]

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 --92.76.235.178 (talk) 22:26, 13 June 2011 (UTC)[reply]