 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> No, the minimum and maximum values are derived by taking the mean and
>> adding/subtracting the SD. If the SD is sufficiently large, it should
>> be possible to make the minimum value negative. (I.e., if the error
>> ratio is greater than 100%.) Not sure how you'd make the maximum go
>> negative, but it's probably possible somehow...
>
> How are you calculating the maximum BPM? I guess you are calculating
> some minimum beat time using the mean and SD and then inverting it?
> Maybe the minimum beat time is negative if the SD is too big compared to
> the mean?
Minimum = mean - SD
Maximum = mean + SD
(But remember that it takes the mean and SD over the beat period, and
then takes the reciprocol of that to compute the BPM value.)
So, yes, as I asserted, if SD > mean than one of the figures comes out
negative.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I still think recording a few keypresses and doing some statistics on
> them is way, way simpler.
Since when do you take the simpler solution? :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> I still think recording a few keypresses and doing some statistics on
>> them is way, way simpler.
>
> Since when do you take the simpler solution? :-)
What you trying to say? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I still think recording a few keypresses and doing some statistics on
>>> them is way, way simpler.
>>
>> Since when do you take the simpler solution? :-)
>
> What you trying to say? :-P
That you often seem up for a challenge :-D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> What you trying to say? :-P
>
> That you often seem up for a challenge :-D
I enjoy challenges that I have some hope of beating. Trying to do
something impossible isn't a challenge, it's a guaranteed defeat. Losing
isn't fun.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/7/2010 9:50 AM, Darren New wrote:
>
> Hey, at least he didn't say it's obviously impossible. :-)
>
LOL
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/8/2010 1:51 AM, scott wrote:
> Funny how it took me about 30 mins of research and coding to come up
> with a working program, when previously I didn't know a single thing
> about it. It didn't require any skills beyond being able to set up a
> struct and calling windows API functions. In my book ludicrously
> difficult is when I think and work on something for *weeks* or *months*
> and cannot get anywhere close to a working program.
Nah, somewhat difficult is dealing with OLE objects on the clipboard,
but that's mainly because of the special memory allocator requirements,
serialization and marshaling requirements.
Rather difficult is writing an Dispatch interface with no framework.
Ludicrously difficult is programming in machine code for a processor
that doesn't yet exist's micro-ops. ;)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/8/2010 3:03 AM, Invisible wrote:
> Oh, wait - you'd need a hex editor to do that...
I hear there's a nice one coming out ... some time. Written by a member
of this newsgroup, too!
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Oh, wait - you'd need a hex editor to do that...
>
> I hear there's a nice one coming out ... some time. Written by a member
> of this newsgroup, too!
Yeah, there is. Just as soon as I finish writing it. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Ludicrously difficult is programming in machine code for a processor
> that doesn't yet exist's micro-ops. ;)
That depends on how complex the processor is, now doesn't it? ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
