GetCharTest

1
dear dan

i enhanced your GetCharTest.m and polished GetChar.mex slightly. I
think that it's now self explanatory.

help getchartest now says this:

GetCharTest evaluates the accuracy of the timing information returned by
GetChar. GetChar returns two values: when.ticks and when.secs.
when.ticks is passed on directly from the Mac OS. when.secs is an
estimate, based on when.ticks, of what GetSecs would have returned.
There are three issues that limit the accuracy of the timing:

1. The time, in ticks, of the keypress returned by the Mac OS is
inaccurate, with errors of more than one tick. This may reflect
coarse quantization of time in the the hardware interface to the
keyboard. Different kinds of keyboard interface (built-in laptop
keyboard, ADB, USB) may have different quantizations.

2. A tick is an integer, with a unit of 1/60.15 s.

3. The value of when.secs necessarily inherits all the inaccuracies of
when.ticks, and has a further problem. If you know the rates of two
clocks, it's easy to convert times from one kind of time to the other.
We do that by estimating Tick0Secs, the value of GetSecs at the moment
when GetTicks was zero.
tick0Secs=GetSecs-GetTicks/60.15;
We can then convert any value of ticks to secs by the formula:
secs=ticks/60.15+tick0Secs;
However, it turns out that the Mac OS tick counter often misses ticks
when the computer is very busy. I.e. the ticks clock may be slow. Thus,
the value of tick0Secs, which tracks the slippage, will keep changing.
It's fine to measure it once and use it for a few minutes, but not for
hours. It should be remeasured. GetCharTest begins by asking SCREEN to
remeasure Tick0Secs.

best

denis

p.s.
i'm enclosing all the relevant new files: GetChar.mex, GetChar.m,
GetCharTest.m, SCREEN.mex,
2
dear dan

thanks for the report on how it worked out. i prefer to do support
strictly on the forum. as a lurker, i think it's always interesting
to find out how well the proposed solution worked.

incidentally i think it may be significant that you're using Mac OS
9.0 whereas i'm using 9.2.2. It used to be that GetSecs ran at a rate
that was about 1% fast or slow (i've forgotten). i even wrote a
routine (getsecstest) to compensate for it. but one of the more
recent releases of the Mac OS has eliminated the error. if you run
TimingTest, it will test all the clocks against each other. here's a
printout for mac os 9.2.2:

timingtest
WaitSecs and GetSecs are based on the VideoToolbox Seconds.c, which uses the
UpTime timebase (a counter in your PowerPC chip), if available. WaitTicks and
CPUTIME are based on the Mac OS Time Manager.
WaitTicks : GetSecs says it took 1.0001 of nominal.
WaitSecs : GetSecs says it took 1.0001 of nominal.
WaitTicks : cputime says it took 1.0000 of nominal.
WaitSecs : cputime says it took 1.0001 of nominal.

TimingTest is enclosed. (it's probably unchanged from the version you
already have.)

best

denis

>Dear Denis,
>
>Thank you very much for all your efforts this weekend. I certainly read your
>posts, and I have been working with your GetCharTest.m and making
>adjustment to
>my own experimental program.
>
>The key to valid response times definitely seems to be including the line:
>screen('Preference','Tick0Secs',nan);
>before each stimulus/response period. I tried putting that line in
>the program
>just once at the top, but that resulted in inaccuracies that were
>similar to the
>ones I encountered before, but less severe. But the returned value of
>when.ticks was always good.
>
>I know that it vague. I am still trying to understand and quantify that
>when.secs error. But at least adding that SCREEN command before each
>stimulus/response period seems to fix things.
>
>By the way, my machine is a PowerMac G3, OS 9.0, 333 MHz running
>Matlab 5.2.1.
>I don't suppose that might explain why I would have to reset Tick0Secs before
>each stimulus/response period (each being just a few seconds) instead of
>restting it just once per run (less than a minute total)?
>
>Finally, to address your question below, I would leave when.secs in GetChar.
>It is a convenient convenience (for me at least) and you clearly inform the
>user about the Tick0Secs issue in the current help for it. Caveat emptor, or
>something like that.
>
>I will continue to look more closely at it all, the C-code for the MEX
>as well. I'll let you know if I have any new ideas. Thanks again.
>
>- Dan
>
>P.S. Would you prefer that I posted this to the forum? I didn't
>have anything
>particulary new to add, just a little feedback to you, so I figured not this
>time.
>
>
>On Fri, 31 May 2002 22:18:15 -0400 Denis Pelli <denis.pelli@...> wrote:
>
>> i wouldn't have expected the time difference to be negative. it's
>> possible that my algorithm to do the conversion from ticks to secs
>> could be enhanced.
>>
>> i'm not sure what to do at this point. there isn't any extra
>> information in when.secs; it's merely a convenience. should i delete
>> it, to avoid confusing users? or should i leave it?
>>
>> i haven't tried to think through the implications of the integer
>> quantization of ticks. if you can suggest an improved formula for
>> conversion i'd be happy to use it to enhance GetChar.mex.