On Thursday 03 March 2005 22:22, Daniel Phillips wrote: > On Thursday 03 March 2005 13:40, Lourens Veen wrote: > > On Thursday 03 March 2005 16:33, Nicolai Haehnle wrote: > > > --- float25.cpp (revision 14) > > > +++ float25.cpp (working copy) > > > @@ -86,7 +86,8 @@ > > > > > > invfrac = (((mantissa & 0x3F) ^ 0x3F) + 1); > > > mantissa = base + ((difference * invfrac) >> 3); > > > - } > > > + } else > > > + exponent--; > > > > > > exponent = ((~exponent) - 2) & 0xFF; > > > > You're right, it is a bug, and this is the correct solution. > > It works as long as there aren't too many bits of mantissa. In > particular, it works for 6 bits (but not 9). You'll see in my code > that this condition is handled explicitly (look for the !!).
Erm, I'm not sure I follow you here. If the mantissa is 0, then it should remain 0 (because of the perfect-powers-of-two rule) and the exponent should be corrected. What am I missing? And Nicolai's fix does the same as your !! doesn't it? > Explicitly accounting the exponent bias in this code does not make > sense. In hardware, there is no reason to have a bias. The bias is > only there so that packed fp numbers sort properly. The only place > where we _might_ pack fp numbers is in the depth buffer. In hardware, > the exponent should be a signed 8 bit number. Ah, good point. I hadn't thought about the exponent yet to be honest. I figured the mantissa was the hard part and the exponent would be trivial. Any ideas about NaNs and infinities and denormals? > It would be nice to clean things up so it works in the range [1, 2). It doesn't? Lourens _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
