From: Yong Li Date: 2012-01-31T18:35:29+09:00 Subject: Re: Microrant on Ruy's Math Skills On Tue, Jan 31, 2012 at 4:03 PM, Chad Perrin wrote: > On Tue, Jan 31, 2012 at 11:35:10AM +0900, Yong Li wrote: >> On Tue, Jan 31, 2012 at 1:27 AM, Chad Perrin 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 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? > suppose we are writing a unit test method def test_something() do a = pre_condition() # => a is a Float assert_approx_equal a, expected1 # => ok a = process a # => do the real work assert_approx_equal a, expected2 # => the assertion may fail, if expected 2 is evaluated in my head end do you consider this as a surprising result that may happen a lot?