Dear Andreas,

Thanks for checking this! I will commit this fix to the CVS once the
new release is out:

1) remove the superfluous rounding from MeasureClockC
2) change the scale.h header to do the rounding right

Miklos

PS. Hope you are recovering fast! :)

On Wed, Feb 24, 2010 at 10:55 AM, Andreas Weigel
<[email protected]> wrote:
> Miklos Maroti schrieb:
>>
>> Hi David,
>>
>> On Tue, Feb 9, 2010 at 1:41 AM, David Gay <[email protected]> wrote:
>>
>>>
>>> On Mon, Feb 8, 2010 at 11:35 AM, Miklos Maroti <[email protected]>
>>> wrote:
>>>
>>>>
>>>> Janos, Andreas and David,
>>>>
>>>> From scale.h the scale32(x,a,b) call calculates x*a/b with fixed point
>>>> arithmetic without overflow. The offset was added to help rounding,
>>>> but it was not implemented correctly. If you want to calculate x/b,
>>>> then it makes sense to calculate it as (x + b>>1)/b to get the
>>>> rounding effect. However, this is NOT needed here since a/b should be
>>>> close to 1 and in fact the added offset should be a/(2*b). So I think
>>>> this is clearly a bug and should be removed!
>>>>
>>>> Andras, can you please change the code to
>>>>
>>>>  async command uint32_t Atm128Calibrate.calibrateMicro(uint32_t n) {
>>>>    return scale32(n, cycles, MAGIC);
>>>>  }
>>>>
>>>>  async command uint32_t Atm128Calibrate.actualMicro(uint32_t n) {
>>>>    return scale32(n, MAGIC, cycles);
>>>>  }
>>>>
>>>> and rerun your experiments? David, can you confirm that this is indeed a
>>>> bug?
>>>>
>>>
>>> Yes, your summary is correct (except that the ideal offset would be
>>> b/2a, which would be ~1/2).
>>> It might be worth forcing the result to be at least 1 as well - do we
>>> want calibrateMicro(1)/actualMicro(1) to sometimes give 0?
>>>
>>
>> Yes, you are right. Attached is a code that calculates ROUND(x*a/b),
>> and I think we should use this instead of FLOOR(x*a/b). We should
>> change this after the next release.
>>
>> I do not think we should care if something becomes 0, since the Alarms
>> take care of that, or people can check it manually, especially then
>> the input must be close to 0 too.
>>
>> Andreas, did you manage to run some tests?
>>
>> Miklos
>>
>
> Hello everyone,
>
> with the changes Miklos proposed everything behaves as expected
> (multiplication with 0.9216 and round to nearest) and
> actualMicro(calibrateMicro(x)) now also yields x. Thanks a lot anyone!
>
> Andreas
>

_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to