[sldev] Unit Test Harness: Patch-2
rahul at adroit-inc.com
Mon Mar 5 00:32:39 PST 2007
For the current test case, it would seem that 8-bits are sufficient to pack
44 (decimal portion of 44.44f). However, the fact that 44.44f gets
represented as 44.4399999 is what is causing the problem - 8 bits are not
sufficient to pack 4399999 and is resulting in the test failure. Agreed that
another approximate_equal function that takes precision as input is needed.
Aaron had suggested addition of ensure_approximately_equals for float/double
that takes the precision/epsilon. Will add that and update the test cases
From: sldev-bounces at lists.secondlife.com
[mailto:sldev-bounces at lists.secondlife.com]On Behalf Of John Hurliman
Sent: Saturday, March 03, 2007 2:17 AM
Cc: sldev at lists.secondlife.com
Subject: Re: [sldev] Unit Test Harness: Patch-2
Rahul Agarwal wrote:
> Please look at test case 1 in lldatapacket_tut.cpp in unittest-2.patch.
> orig F32 value = 44.44f (44.439999)
> final F32 value after pack/unpack = 44.437500
> The delta (0.002499) after serialization is greater than the tolerance as
> per is_approx_equal.
Thanks for that, I'm still reviewing the unit test patches. The
immediate problem I see here is that the fixed packing allows you to
specify a variable number of bytes to use for packing the integer
portion and decimal portion of the float, but is_approx_equal isn't
smart enough to realize how tightly packed the float in question is. So
if you specify two bits to be used for the decimal part, obviously
you're not going to get a very accurate decimal and is_approx_equal is
going to fail, but is that expected behavior? Should is_appox_equal()
take more parameters to take in to account the amount of packing done
and adjust the tolerance? That's what I'm contemplating for libsecondlife.
Click here to unsubscribe or manage your list subscription:
More information about the SLDev