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?
>
> --
> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
>

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.