On Fri, 4 Feb 2005 19:01:44 +0100, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > On Friday 04 February 2005 18:43, Timothy Miller wrote: > > > > One simplification I've already done is to not account for overflow or > > > > underflow. If the exponent goes below 0 or greater than 255, it > > > > wraps. Is it reasonable to just hope that no one uses numbers that > > > > big or that small? > > > > > > Wrapping overflow is probably unproblematic, but I'm worried about > underflow > > > - even more so when you make 0 a really, really small number instead of > > > true 0. What happens when, in the rasterizer, R, dRdY and dRdX are all > 0? > > > Will the adjust code in HorizontalRasterize work correctly? > > > > That would be an interesting scenario. You'd accumulate error in the > > range of less than 2^-120. When converting that directly to integer, > > it wouldn't be a problem, but if you were to multiply by a huge > > number, the result could be problematic. > > > > I think this could be a bigger issue with coordinates at zero. > > Fortunately, zero is smack between two pixel centers, so it would > > never cause a rounding problem. 0.5 would never be affected by this. > > I'm not sure whether my concern got across. When you say the exponent wraps > for underflow and overflow, I assume this means that if the result of an > operation would be 2^-129, it comes out as 2^127 or something like this.
Here's a pathelogical case where it can happen: 1.1111 * 2^-127 minus 1.1110 * 2^-127 Upon normalization, it would detect the need to shift left by 4 and subtract 4 from the exponent, thereby causing an underflow. > > Now you say that you want to represent 0 as a very small number, let's say > 2^-127. What if dRdX is 0, and adj comes out as 0.25 = 2^-2. The result of > the multiplication would be 2^-129, which wraps around to 2^127 - and > *that* is definitely wrong... Yeah, except there's absolutely no escaping under/overflow detection in the multiplier. The multiplier would do the right thing in this case and give us our zero-approximation. There are less pathelogical cases of multiplication that can result in over/underflow that already have to be caught. > > It's that combination of incorrect underflow *and* incorrect 0 that I'm most > worried about. Yes, but only for the adder. Let's keep working at this. If we don't come up with a problem that isn't dealt with in some other way, I'll definitely have to fix it. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
