John's response doesn't seem to be rude or arrogant to me. John makes essentially two helpful points: 1. that one should focus on the difference between "precision" and "accuracy", with some explanation. 2. suggestion of an experiment that can help understand the difference. I fail to see how this is rude. It is indeed helpful. Pretty much every other responder gave essentially the same information (that the poster must learn floating point), but others were even more terse and direct: "<poster> doesn't understand floating point" Anyway, I'll add my own reference to floating point: This months (Feb 2010) Circuit Cellar magazine has an article "Floating Point for DSP" on implementing fast 18 bit floating point in hardware, and I found it very illuminating for the mechanics of floating point, even if you never plan to implement floating point in hardware or software. Years ago, ~1988, I wrote a fixed point code to speed up my MIT computer graphics class homework assignments.* I should try to find that again. It also sheds some light on number representation problems. [* ok, this was a bit more than the problem sets called for, but I took the class with Terry Donahue, the author of Xtank; there may have been some personal competition. Terry also wrote a fixed point code. I believe we both got A's. ;-)] --Dean On Thu, 4 Mar 2010, Steve Teale wrote: > On Wed, 2010-03-03 at 16:52 -0500, John S. Fine wrote: > > Part of your confusion is over the difference between "precision" and > > "accuracy". > > > > A floating point format has a FINITE number of specific values that can > > be stored with infinite accuracy. You happen to have chosen values that > > are in that finite set. > > > > You can set the precision of your output to whatever (finite value) you > > like. It may be much more than the accuracy of your number. It may be > > much less than the accuracy of your number (especially if the accuracy > > of your number is infinite). > > > > Even if the accuracy of a stored floating point number is infinite, it > > may be possible for the algorithm that converts it from binary to > > decimal to introduce some inaccuracy. I'm not sure of those details. > > Your results seem to indicate that translation is done surprisingly well. > > > > To help you understand, instead of outputting just d each time, output > > both d and d+1. At some point d will still be 100% accurate but d+1 > > will not be accurate, in fact it will be exactly equal to d. > > John, > > Congratulations on a helpful answer. Yours was the first one that did > not display the almost conventional GCC guru arrogance. > > GCC would have a lot more participants/helpers if it were not for this > unwritten convention of rudeness in the community. > > To be fair, this isn't just a GCC thing. I've worked in various shops > where the software paid the wages, but if a new employee asked for help > he/she would get a similar response. > > I understand the impatience of the gurus. If they tried to answer every > naive question they'd never get any work done > > But, if you don't have anything helpful to say, then maybe it's better > to bite your tongue! The person you are responding to may be an idiot, > but he/she is not the only recipient of your message. > > Thanks > Steve > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 256 5494
