Author: Francesco Di Tolla
Date: 08:53:26 11/03/03
Go up one level in this thread
On November 01, 2003 at 07:49:14, Ricardo Gibert wrote: >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] I know what fixed point arithmetic is. I don't see the point to write an algorithm that is faster but does not work.
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.