On Sun, 6 Feb 2005 17:42:59 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Sunday 06 February 2005 17:16, Lourens Veen wrote: > > On Sunday 06 February 2005 18:13, Daniel Phillips wrote: > > > I'm glad to hear it turned out to be only a theoretical problem. > > > However, a floating point interpolation step is for sure a > > > multi-cycle operation, so this problem rears its head again, does > > > it not? Here are a couple of suggestions: > > > > > > - Don't bother with counting zeroes and left-shifting in the > > > normalize stage - denormalized arithmetic should be ok here > > > > Well, if you're going to feed the result into my approximate > > reciprocal then this _might_ give problems. > > I'd upgrade that to "probably" because restricting the input range of > the lookup to [.5, 1] is a Good Thing, I seem to recall from various > numerical screeds. However, the normalization can be done _outside_ > the interpolation iteration, because then it doesn't really matter how > many clocks it takes, it's just a straight pipeline. > > My reason for thinking the interpolation loop itself can run > denormalized is, by normalizing it continuously you effectively invent > accuracy that isn't there. (Maybe allowing for a one-bit left shift on > each iteration would be a good thing, or maybe it would just be a waste > of gates.)
I was never planning on continuously normalizing the iterator values. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
