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 haven't really thought > about it though, so far I've only done the mantissa part of the game. > > Anyway, I have a simple float25 class, I just need to debug it and > put in the reciprocal stuff. I'll probably mail it to the list > tomorrow, and I'll try and figure this out as well. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
