On Friday 04 February 2005 20:47, Lourens Veen wrote: > I haven't really found out what the best way of defining > precision is. If 90% of your values are correct to 15 bits but you > have a few outliers that are only correct to 13 bits, what is your > precision? 15 bits? 13 bits? Somewhere in between? Or in other words, > do you use maximum error, or RMS, or what?
Or average error. I think we use all of those measures, the most important being the maximum error. Expressing in "bits" is somewhat crude to the actual error which is best expressed as a real number. > I guess in the end what really matters is whether it looks good or > not. Yes, and then when it looks good you analyze the error and write a paper about why it looks good ;-) > We need to calculate W1 = 1/M and W2 = 1/(M + dMdX) The problem is > that we know nothing about dMdX. Sure you do, it's linear. dMdX is in a register. I think you must have expressed that incorrectly or I forgot what M means. I'll stop here until I've got this straightened out. > > just to be kind to old C hacks like me, please don't > > overload the math operators, just make it a function so it's > > readable out of context. > > Will you change the model around to replace all the + signs with a > .add() call then? No, replace all a + b with, e.g., fpadd18(a, b), so the operations are just functions and not class methods. The expressions are quite short, so there's no problem with readability, and the reader won't get tangled up in a mess of context. Operator overloading is too clever by half for this application. > I was thinking to overload the operators with ones that give full > 16-bit precision, and have functions for approximations like this. We're going to end up with a whole bunch of wild and wooly precision hacks for both fixed point and floating point, and these will be all mixed together. Trying to decipher exactly what's happening by referring back to class definitions is just a an error-prone makework project. My humble opinion of course. 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)
