| T O P I C R E V I E W |
| SnailsAttack |
Posted - 01/11/2023 : 14:53:21
My counter is computing 12981 counts in 12 hours as "18.2" CPM when it's supposed to read 18.03 CPM, rounding to the hundredths place.
12981 / (12 * 60) = 18.02917 ...
I think it somehow dropped the tenths place because it's a zero, and didn't factor in the thousandths place (although to be fair the difference is negligible).
Is this a known bug? It usually gives correct CPM estimates from the duration and number of counts (aside from not considering the thousandths place when rounding).
|
| 7 L A T E S T R E P L I E S (Newest First) |
| EmfDev |
Posted - 01/26/2023 : 17:48:34
Damien68 is right and has appeared before in the forum. Not sure if it was from 500/600+ but I thought this bug was fixed on all devices but actually not for 300/320 series. Now it has been fixed and will be released in the next firmware update together with alarm volume addition.
|
| ullix |
Posted - 01/20/2023 : 01:50:09
:-))
It would be hilarious if Damien's suspicion became true, because the C language - in which the firmware is coded - has a well established function for formatting numbers since eons. |
| SnailsAttack |
Posted - 01/19/2023 : 06:33:44
Here's another instance of the bug occurring. |
| SnailsAttack |
Posted - 01/12/2023 : 17:09:42
quote:
Originally posted by ullix
In this case it does not matter much, but it makes you wonder where else the calculation is done incorrectly ...
Yes. It's not a big error in this case, but it has the potential to be, particularly for low CPM measurements that happen to have a large number in the hundredths place (e.g. 10.09 CPM misread as 10.90).
quote:
Originally posted by EmfDev
Hi SnailsAttack, yes it may be a bug, I will send it to our devs so they can check it.
Okay. Thank you.
|
| EmfDev |
Posted - 01/12/2023 : 15:02:53
Hi SnailsAttack, yes it may be a bug, I will send it to our devs so they can check it. |
| Damien68 |
Posted - 01/12/2023 : 04:56:19
I already saw a bug like that somewhere I don't remember where, it was a bug when displaying:
maybe it should display:
- the integer part: 18 is OK
- followed by a dot '.' is OK
- followed by the fractional part 02 displayed as an integer i.e. like a 2 . is NOK.
I think it looks like :) |
| ullix |
Posted - 01/12/2023 : 00:10:01
Strange, indeed.
I tried it the other way: producing 12981 counts with CPM=18.2 would take 405.5 sec or 6.76 min LESS than 12h. That is a lot.
In this case it does not matter much, but it makes you wonder where else the calculation is done incorrectly ...
|
