On Wed, Feb 1, 2012 at 12:49 AM, Chad Perrin <code / apotheon.net> wrote:
> On Tue, Jan 31, 2012 at 06:35:29PM +0900, Yong Li wrote:
>> On Tue, Jan 31, 2012 at 4:03 PM, Chad Perrin <code / apotheon.net> wrote:
>> >
>> > 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
>> =A0 a =3D pre_condition() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 # =3D> a is a Float
>> =A0 assert_approx_equal a, expected1 =A0# =3D> ok
>> =A0 a =3D process a =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0# =3D> do the real work
>> =A0 assert_approx_equal =A0a, expected2 =A0# =3D> 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?
>
> Yeah, basically. =A0Of course, "a lot" is relative -- but the upshot is
> that it happens enough to be a problem when offering an additional
> comparison method should yield something much easier to evaluate in one's
> head.
>
> Of course, I don't know how you get a unit test to make use of your
> brain's arithmetic capabilities. . . .
>
Sorry, my bad for confusing you. Second try:

# process(Fixnum i) is supposed to return 100.0 * i
# and I am going to test it
assert_with_approx_equal( process(1.1), 110.0)
# =3D> oops, this fails, but I thought 100.0 * 1.1 =3D=3D 110.0

that '110.0' Float literal is calculated by my brain without using
computer, and I may naively claim that the process method is wrong,
but actual it is this unit test which is wrong.

does unit test qualify your "98% of the problem for 98% of casual use cases=
"?