bug-gtypist
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gtypist] Suspicious Raw speed [update]


From: Tim Marston
Subject: Re: [bug-gtypist] Suspicious Raw speed [update]
Date: Sun, 22 Jun 2014 18:38:31 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

Hi Chris,

Sorry for the very, very delayed response to your email!  I'm afraid it
completely slipped off the radar!  Fortunately, Felix Natter's prompted
me to reply (thanks Felix!).

On Thu, Apr 24, 2014 at 04:26:13PM -0400, Chris Jones wrote:
> I have noticed that I repeatedly reach the exact same raw speeds on
> a number of drills... stuff like.. 111.43 wpm, 96.80 wpm, 150.00 wpm..
> etc. I had suspected this for some time but now I can ask gtypist to
> keep track of my personal best... I know for sure.

Yes, that sounds very suspicious.

> It would be rather silly  sending in a bug report on a hunch but perhaps
> someone familiar with the code could take a quick look...?

I had a look.  The problem was that the CPM/WPM calculations were based
on the time taken to complete the lesson, which we measured in whole
seconds, rounded down!  So, displaying CPM/WPM to two decimal places of
accuracy was a bit over-enthusiastic!  :o)

I have committed a fix for this[1], which will be included in the next
2.9 point release.  Elapsed lesson times are now measured in
milliseconds, which is much more reasonable.

[1] 
http://git.savannah.gnu.org/cgit/gtypist.git/commit/?h=branch-2.9&id=752f25d8b9a01dded4ba5bd4d2ac82e765d482d2

On Fri, Apr 25, 2014 at 12:37:19AM -0400, Chris Jones wrote:
> Something else I forgot to mention: 
> 
> In lesson T1 (which consists in typing four f's in succession and
> hitting the enter key) my personal best is... 2000 wpm. No idea if it's
> in any way related to what I describe in my initial post but that's
> another hint that something is perhaps not quite right.

This was related, yes.  When calculating CPM, we divide by the elapsed
lesson time.  For the "ffff" lesson, this could easily be 0 seconds
(after rounding down).  So, instead of dividing by zero, we just set
CPM to 9999.99 (which works out as 2000 WPM).  Fortunately, given the
above fix, this will be practically impossible to achieve now.

Thanks very much for reporting this!  Sorry again that it's taken me
almost two months to get round to looking at!

Kind regards,

-- 
Tim Marston
ed.am



reply via email to

[Prev in Thread] Current Thread [Next in Thread]