Not quite sure if you could classify the following as a bug, but I've noticed how the average rate for a piece doesn't get rounded up to provide a more realistic figure.
Example, I recently looked at the generated CSV data for a piece where I rate 20 for 45 minutes. When I looked at the data the workout was split into the usual 5 segments 9 minutes each. My rate was reported as 20 for all except one of the 9 minute segments which showed 19.
However, the average rate shown for the entire piece was output as 19.
Calculating the average the total rate would be 99 and this would then be divided by the number of workout segments - 5 in this case. The answer is 19.8. Using rounding, a sensible answer would be in fact 20 as this represents the majority of the workout.
It appears no rounding is done and only calculations at integer level are done. I understand that ratings over a piece may only be recorded as integer values, but the Concept 2 Utility - I would have thought - would do an internal average calculation at the floating point level in order to produce a floating point result which could then have rounding applied to output an integer figure.
Thoughts?
Regards
Steve
Rounding Issue with C2 Utility 6.53
- Citroen
- SpamTeam
- Posts: 8059
- Joined: March 16th, 2006, 3:28 pm
- Location: A small cave in deepest darkest Basingstoke, UK
Re: Rounding Issue with C2 Utility 6.53
Working as designed. It's always done it that way.
When the PM3 or PM4 does rounding it always rounds down to the nearest integer or nearest tenth (for some values like pace).
It also does simple averages (sum and divide by number of elements). It also only collects some data (HR, stroke rate) at the end of a split (the numbers are never a rolling average).
When the PM3 or PM4 does rounding it always rounds down to the nearest integer or nearest tenth (for some values like pace).
It also does simple averages (sum and divide by number of elements). It also only collects some data (HR, stroke rate) at the end of a split (the numbers are never a rolling average).
Re: Rounding Issue with C2 Utility 6.53
Hmmmm ... as far as the rate average is concerned it sounds as it could do with being "designed" a little better me thinks.Citroen wrote:Working as designed. It's always done it that way.
- Citroen
- SpamTeam
- Posts: 8059
- Joined: March 16th, 2006, 3:28 pm
- Location: A small cave in deepest darkest Basingstoke, UK
Re: Rounding Issue with C2 Utility 6.53
It's been like that since the PM2 was first introduced. The PM3 & PM4 simply emulate the PM2's funky maths.
- Carl Watts
- Marathon Poster
- Posts: 4717
- Joined: January 8th, 2010, 4:35 pm
- Location: NEW ZEALAND
Re: Rounding Issue with C2 Utility 6.53
It's worse than a 1spm rounding figure sometimes depending on your row.
I built a stroke counter with a photoreflective Omron sensor driving a counter that picks up the seat at the end of the drive to get the SPM to hundreths of an SPM if I wanted it.
The PM3 really gets bad at low ratings like 18-19 SPM. This is on the wish list for a fix in the next version of PM monitor and is really simple math to get an accurate SPM to tenths for a row.
I built a stroke counter with a photoreflective Omron sensor driving a counter that picks up the seat at the end of the drive to get the SPM to hundreths of an SPM if I wanted it.
The PM3 really gets bad at low ratings like 18-19 SPM. This is on the wish list for a fix in the next version of PM monitor and is really simple math to get an accurate SPM to tenths for a row.
Carl Watts.
Age:56 Weight: 108kg Height:183cm
Concept 2 Monitor Service Technician & indoor rower.
http://log.concept2.com/profile/863525/log
Age:56 Weight: 108kg Height:183cm
Concept 2 Monitor Service Technician & indoor rower.
http://log.concept2.com/profile/863525/log