I referred to the accuracy of result *acceptable to one*, if there are cases that 0.00002 and 0.000029 may occur, and u still want to go with a 1.0e-5 value as a zero equality check, its your code, screw it up. If one knows that such corner cases might come and he decides to discard them, fine, else raise the bar. The problem is always to decide the thresholds and then sticking to them. Also, I chose the value of 1.0e-5 to check equality with 0.0000... and when I say so, I stand by the point that 0.0000019999999 *is* 0.000000000000000000000 for me, *whatever* may be the %age difference, because values lesser than *1.0e-3* do *not* interest me hence I chose the bar as 1.0e-5 and *not* 1.0e-3. Its an engineering decision, not a programming contest solution to get through an online judge.
Programmers should realize their critical importance and responsibility in a world gone digital. They are in many ways similar to the priests and monks of Europe's Dark Ages; they are the only ones with the training and insight to read and interpret the "scripture" of this age. On Sat, Jan 8, 2011 at 1:35 AM, Dave <[email protected]> wrote: > @Avi: Whether this is a safe implementation depends in part on whether > you want to say that 0.00002 == 0.000029 because they differ by less > than 1.0e-5, even though they differ by 45%. Applying your > philosophical boilerplate, you have to use some intelligence even in > this type of thing. > > Dave > > On Jan 7, 12:51 pm, Avi Dullu <[email protected]> wrote: > > Thanx for the precise information. > > > > I was coming from a perspective of safe implementation, when dealing with > > variables, you might not always know whether the values to be compared > will > > fall under the exact floating point representation, so the safe way to go > > might always be to use the < 1.0e-5 method or go with library functions. > You > > see any problem with this too ? > > > > Programmers should realize their critical importance and responsibility > in a > > world gone digital. They are in many ways similar to the priests and > monks > > of Europe's Dark Ages; they are the only ones with the training and > insight > > to read and interpret the "scripture" of this age. > > > > > > > > On Fri, Jan 7, 2011 at 4:15 AM, Dave <[email protected]> wrote: > > > I don't think your example with == would ever fail. According to the > > > IEEE floating point standard, integers within the dynamic range of the > > > number type must be represented exactly and must compare as equal. > > > > > Furthermore, the four basic operations on integers within the dynamic > > > range of the floating point number type that have integer results > > > within that dynamic range must be exact. Thus, 25.0 - 5.0, 13.0 + 7.0, > > > 4.0 * 5.0, and 60.0 / 3.0 all must equal 20.0 exactly. > > > > > Where you run into trouble is when the numbers in question cannot be > > > represented exactly in the finite precision floating point format -- > > > something like this: > > > > > double d1 = 6.1; > > > double d2 = 11.6; > > > double d3 = 17.7; > > > > > assert(d1 + d2 == d3); // might fail, and Wrong way to do it !! > > > > > And your "correct and recommended way" is missing an absolute value: > > > > > assert(abs(d1 + d2 - d3) < 1.0e-5); // given you assume precision of > > > 1e-5 is the correct and recommended way. > > > > > Dave > > > > > On Jan 6, 4:19 pm, Avi Dullu <[email protected]> wrote: > > > > Just to mention, floating point numbers r always compared *for > equality* > > > > like > > > > > > double d1 = 90.0; > > > > double d2 = 90.0; > > > > > > assert(d1 == d2); // might fail, and Wrong way to do !! > > > > > > assert(d1 - d2 < 1e-5); // given u assume precision of 1e-5, is the > > > correct > > > > and recommended way. > > > > > > Programmers should realize their critical importance and > responsibility > > > in a > > > > world gone digital. They are in many ways similar to the priests and > > > monks > > > > of Europe's Dark Ages; they are the only ones with the training and > > > insight > > > > to read and interpret the "scripture" of this age. > > > > > > On Fri, Jan 7, 2011 at 1:47 AM, juver++ <[email protected]> > wrote: > > > > > Numbers without fractional parts are represented exactly (in a > range > > > > > supported by double). > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > "Algorithm Geeks" group. > > > > > To post to this group, send email to [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<algogeeks%[email protected]> > <algogeeks%2bunsubscr...@googlegroups.com> > > > <algogeeks%2bunsubscr...@googlegroups.com> > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/algogeeks?hl=en.-Hide quoted text - > > > > > > - Show quoted text - > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Algorithm Geeks" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<algogeeks%[email protected]> > <algogeeks%2bunsubscr...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/algogeeks?hl=en.- Hide quoted text - > > > > - Show quoted text - > > -- > You received this message because you are subscribed to the Google Groups > "Algorithm Geeks" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<algogeeks%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/algogeeks?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Algorithm Geeks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/algogeeks?hl=en.
