On Tue, Jan 31, 2012 at 11:35:10AM +0900, Yong Li wrote:
> On Tue, Jan 31, 2012 at 1:27 AM, Chad Perrin <code / apotheon.net> wrote:
> > On Mon, Jan 30, 2012 at 05:22:47PM +0900, Robert Klemme wrote:
> >> On Mon, Jan 30, 2012 at 6:56 AM, Chad Perrin <code / apotheon.net> wrote:
> >> > On Mon, Jan 30, 2012 at 10:03:04AM +0900, Gary Wright wrote:
> >
> > Can someone please explain to me in clear, direct terms why there is
> > opposition to the simple expedient of adding at least one additional
> > comparison method to Float to address the vast majority of casual use
> > cases without having to resort to reimplementing such comparison methods
> > over and over again or bringing in additional libraries with onerous
> > syntactic verbosity?
> 
> With all due respect to your suggestion, it is good, but we do need
> careful analysis of the precise mathematical properties of such an
> supplement. Consider, for example, how would you define the behavior
> of the following situation:
> 
> // assuming your new Float#approx_equal returns true
> // if two float are equal until the first digit after the decimal point
> // e.g. 1.11.approx_equal(1.10)  # => true
> a = 1.11
> b = 1.1
> a.approx_equal(b) #=> true
> (a * 100).approx_equal(b * 100) #=> false
> 
> I guess, this again breaks the simple math.

What exactly are you arguing here -- that there's no such thing as a
solution that is easier to evaluate in one's head so that the results are
not surprising a lot of the time?

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]