On 7/30/07, Andre Pouliot <[EMAIL PROTECTED]> wrote: > In that case I'm going to modify the program to make the result go to > infinity when we receive an infinite/NAN or force the output at zero when we > receive an denormalized/zero value. So no more denormalized value.
Yeah. Now, the way you did it before wasn't bad. Basically, if the exponent isn't min, then make 1.mantissa the intermediate operand, while if the exponent is min, make it 0.mantissa. That's the simplest way to deal with numbers on the way in. But then if you find that neither of the top two bits of the product is 1, then slam the output all to zero. Cheat as much as you possibly can! > All case > that make the pipeline behave strangely will be covered. The case infinite > multiplied by zero will result in zero unless someone have an objection. No objection. In fact, minimize what you do with infinity. Nowhere do we actually perform a divide. The one place involves a reciprocal and a multiply, and we can cheat there too. Keep in mind that for colors, anything greater than 1.0 gets clamped. For coordinates, larger values are accepted, but they're still much smaller than infinity. Since OGA1 will be implemented first for FPGA, we can actually take a "try it an see" approach. Obviously, we want people taking the analytical approach to determine if there are any places where we would care about an infinity. But we can also experiment with lots of apps and see if anything actually works with really large numbers. Maybe we can not bother to clamp the exponent (let it wrap), maybe we have to clamp it in some places. The question we want to consider is what to do with ill-behaved apps that hand us numbers that are beyond our ability to handle. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
