Author: Ricardo Gibert
Date: 04:49:14 11/01/03
Go up one level in this thread
On November 01, 2003 at 05:57:06, Francesco Di Tolla wrote: > >>Assume the "numbers" in question are unsigned and fall in the range 0 to 255 as >>an example. Now what we want to do is to map the numbers onto 0 to 100: >> >> find largest >> k = (100<<17)/largest >> foreach number >> number = (number*k)>>17 >> >>Where this might fail is if the original range is very much larger than 0 to >>255, so that the last statement would either create an overflow problem or an >>inaccurate result depending on the selected shift value. This can be remedied by >>resorting to 64 bit arithmetic, but I find that inelegant. >> >>With a little tweaking the above should be able to be made exactly equivalent to >>the OP's original algorithm, though perhaps the OP may find that is not >>necessary. > >I don't get the point of using shifts: > It's called fixed point arithmetic. It is a way of avoiding floating point arithmetic. I haven't tested it, so I am assuming it is quicker. Regardless, the point is the "/largest" can be moved out of the loop just like I said. [snip]
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.