On Monday 07 February 2005 08:22, Daniel Phillips wrote: > Hi all, <snip> > > how much it differs from the average of 1/.999 and 1. So: > >>> 1/.9995 - (1/.999 + 1)/2 > > -2.5037543815997765e-07 > > So there we have it, it's out by about one part in 4 million, or roughly > 22 bits of accuracy. That should do. The error will be dominated by > the limited precision of the sample point, not by the interpolation. > > Note that this excellent behavior relies on the fact that the input is > normalized.
Good call. I've just been trying out the model with my new and shiny float25 class, and I actually got it to work. It appears that going from float32 to float25 does in fact cost some precision (1-2%) but my approximate reciprocal does not reduce quality any further (ie yields the exact same output on the textured image). I've attached a patch. Using both gcc and g++ got a bit clumsy, since gcc doesn't know what a class is, and geometry.c includes render.hpp, which includes float25.hpp, which defines a class. There must be a better way to do this, so please fix this someone :-). Getting the operator overloading to work proved rather tricky, but it does work now. I've added a lot of explicit casts to render.cpp, but that just makes it easier to see what is really happening so I don't see that as a problem. Timothy, is there anything in float25::approx_recp() that seems problematic to you to implement in hardware? Anything that when removed would make the hardware much simpler? Incidentally, the patch changes render.cpp:720 to use the approximate, if you want to compare, you should change it back to float25 W = (float25)1/M; Lourens
float25.patch.gz
Description: GNU Zip compressed data
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
