[sldev] Unit Test Harness: Patch-2

[Thomas Rowland]

What about rounding too. I see there is none in the pack routine.
Although I cannot get the tests to link in vc express, It is easy enough to
do the same math (even with an F32).
44.439999 * 256 yields 11376.640, with rounding 11377.
The unpack of 11377 is then 44.441406.

No doubt though, you will still have a 'wide' delta using an 8:8 fixed point
value.


-----Original Message-----
From: sldev-bounces at lists.secondlife.com
[mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Rahul Agarwal
Sent: 05 March 2007 08:33
To: John Hurliman
Cc: sldev at lists.secondlife.com
Subject: RE: [sldev] Unit Test Harness: Patch-2


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
accordingly.

Thx
Rahul

-----Original Message-----
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:
> John,
>
> 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.
>
> Fail:
> LLDataPackerBinaryBuffer::(un)packFixed
> LLDataPackerAsciiBuffer::(un)packFixed
> LLDataPackerAsciiFile::(un)packFixed
> LLDataPackerAsciiBuffer::(un)packF32
> LLDataPackerAsciiFile::(un)packF32
>
> Pass:
> LLDataPackerBinaryBuffer::(un)packF32
>
> Thx
> Rahul

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:
/index.html



_______________________________________________
Click here to unsubscribe or manage your list subscription:
/index.html