#$&*
Phy 202
Your 'timer program' report has been received. Scroll down through the document to see any comments I might have inserted, and my final comment at the end.
** TIMER program_labelMessages **
This is the form-submitted version of the TIMER experiment exercise whose responses I emailed to you back on Saturday, June 16, when the vhcc2.vcc.edu subdomain was down. I completed it before you advised me that my responses didn't need to go into so much detail; hence the length.
** **
Time to complete experiment = approx. 5 to 5.5 hours (Please note that I did this work before you advised that I could be briefer. As I mentioned in my email, the server was down, so I couldn't submit it here, and I submitted it as a .txt email attachment instead. I'm resubmitting it, this time in the preferred format, now that the website is up.)
** **
DO NOT COPY THE LINES ABOVE THIS ONE. JUST FILL THOSE LINES IN WHEN YOU SUBMIT YOUR RESULTS AT THE END OF THIS FORM.
* Follow the instructions, fill in your data and the results of your analysis in the given format.
* Regularly save your document to your computer as you work.
* When you have completed your work:
Highlight the contents of the text editor, and copy and paste those contents into the indicated box at the end of this form.
Click the Submit button and save your form confirmation.
This experiment is self-explanatory. Student report time of completion ranging from 10 minutes to 1 hour, with 30 minutes being the most typical.
Downloading and/or running the TIMER program
If you have a Macintosh computer the preferred timer.exe program might not work (it will if your computer has a Windows emulator), but the alternative Java applet should work just fine.
timer.exe
The program timer.exe should be downloaded to your hard drive and/or flash drive so you have access to it whenever you need it.
There is an alternative Java applet (see the heading timer java applet below) , but the .exe option is preferable. It is worth 15 minutes of effort to get the program working on your hard drive, after which you will have it and won't need Internet access to run it. It will start up instantly, it runs in a small window, and it has the ability to file your data. However if you can't get it working in 15 minutes with the instructions given below, just move on the the Java version.
To use the Windows version:
If you are using a Windows PC, or a Mac with Windows emulator, first take a few seconds to run the program q a prelim. As soon as the form opens on your screen, you can close it. Nothing needs to be submitted. The first thing this program does is to create the c:\vhmthphy folder on your hard drive. As an alternative you can also create a c:\vhmthphy folder.
The timer.exe program opens in a small window and can be run side-by-side with other windows applications on your computer (just size the second window so it leaves room for the Timer program).
Run the program now. If it fails to work then try the following, in order:
* If you got the Run-time Error 76, it can be corrected by the step given earlier. That instruction is repeated below:
Run the program q a prelim. As soon as the form opens on your screen, you can close it. Nothing needs to be submitted. The first thing this program does is to create the c:\vhmthphy folder on your hard drive. As an alternative you can manually create this folder.
* If this doesn't work, follow the link COMDLG32 to access simple instructions for fixing the problem. Then run timer.exe .
To use the Java version:
Windows users:
The Java applet does require that the Java Runtime Environment be installed. Almost every Apple computer, and most Windows computers, will have this environment installed. If your computer will not run the Java applet, the installation is simple and quick. If you search under 'Java Runtime Environment', using any search engine, you will find information on the Java Runtime Environment and on the installation. You should satisfy yourself that you are downloading from a verifiable, trusted source.
Mac users:
Apple supplies their own version of Java. Use the Software Update feature (available on the Apple menu) to check that you have the most up-to-date version of Java for your Mac.
should check the Apple site for the Software Update feature (available on the Apple menu) to check that you have the most up-to-date version of Java for your Mac.
The Java Applet at the link Timer-Java will work fine for the current experiment, and will do just about everything the timer.exe program will do. The Java applet has a few more or less minor inconveniences and one that's not quite as minor:
* You can't put the Java applet on your hard drive or flash drive, so you have to pull it off the Web every time you want to use it.
* The applet won't file your data. However it will let you copy and paste your data into a text editor.
* If your machine doesn't run Java applets, you would have to set it up to do so (just search the web under 'Java Runtime Environment', which is free and installs easily). This software is pretty standard, and is already installed on most machines.
Operating the TIMER program
It is easy to operate the Timer program. All you have to do is click on the button labeled Click to Time Event.
Click that button about 10 times and describe what you see.
I see a table of 10 rows of 3 columns each; the first column is an index number, the second appears to be the number of seconds since the program was opened (or the counter was initialized, perhaps; I haven't tested yet to see whether the Initialize Counter button resets this value), and the third appears to be the amount of time since the previous click, such that Value(RowX, Column2) - Value(RowX, Column3) = Value(Row[X-1], Column2). Replacing white space with the pipe character, we get
1 | 496.1416 | 496.1416
2 | 496.4072 | .265625
3 | 496.6875 | .2802734
4 | 497 | .3125
5 | 497.2656 | .265625
6 | 497.5146 | .2490234
7 | 497.8115 | .296875
8 | 498.0762 | .2646484
9 | 498.373 | .296875
10 | 498.6064 | .2333984
#$&*
Now click on Initialize Counter, which will clear all the data from the timer window. Click the mouse as fast as you can until the TIMER window fills up. Be sure you get at least 20 time intervals.
If you miss a click, try again. Keep trying until you get at least 20 intervals without a missed or delayed click.
Copy your data starting in the next line:
1 2.652344 2.652344
2 2.855469 .203125
3 3.089844 .234375
4 3.261719 .171875
5 3.480469 .21875
6 3.667969 .1875
7 3.851563 .1835938
8 4.039063 .1875
9 4.242188 .203125
10 4.414063 .171875
11 4.632813 .21875
12 4.820313 .1875
13 5.007813 .1875
14 5.195313 .1875
15 5.382813 .1875
16 5.554688 .171875
17 5.773438 .21875
18 5.960938 .1875
19 6.144531 .1835938
20 6.332031 .1875
21 6.503906 .171875
22 6.707031 .203125
23 6.925781 .21875
24 7.097656 .171875
25 7.285156 .1875
(Taking out all the white space got too cumbersome, so I stopped.)
@&
There's no need to do so. A straight copy of the output is all that's requested.
*@
#$&*
You got at least 20 time intervals. Based on your data what was the average of the first 20 time intervals? Note that you could get this average by averaging the first 20 intervals. My first few intervals were .15625, .15625, .1875, .171875, etc; I could just add up the first 20 intervals and divide by 20 to get the average. However there is an easier and quicker way to get the result, so use the easier way if you can.
Give your result, number only, in the first line, and starting in the second line explain how you got it.
RESULT: 0.19303383repeating
EXPLANATION: To calculate the result the quick and easy way, we have to have realized (as we did above) that each of the third column's second and subsequent values is the difference between the Column 2 value in its row and the Column 2 value in the preceding row. Average = Value:Final - Value:Initial / NumberOfValues = Value(Row25, Column2) - Value(Row1, Column2) / 24; note that there are only 24 intervals because the first interval being measured is between index value 1 and index value 2, not from 0 to 1. (7.285156 - 2.652344) / 24 = 4.632812 / 24 = 0.19303383repeating.
#$&*
When I did this activity the first few lines of my data were as follows:
event number clock time time interval
1 11.67188 11.67188
2 11.875 0.203125
3 12.0625 0.1875
4 12.20313 0.140625
5 12.375 0.171875
6 12.54688 0.171875
7 12.73438 0.1875
8 12.92188 0.1875
9 13.10938 0.1875
10 13.28125 0.171875
11 13.4375 0.15625
It looks like the same intervals keep popping up. For example .1875 seconds occurs 5 times out of the first 10 intervals, .171875 seconds occurs three times, and .203125 seconds, .140625 seconds and .15625 seconds each occur once.
A frequency distribution for my time intervals would be as follows:
time interval frequency
,140625 1
.15625 1
.171875 3
.1875 5
.203125 1
What different time intervals did you observe in your first 20 intervals, and how many times did each occur? List below the different time intervals you observed and the number of times each occurred. List from the shortest to the longest interval, and use a comma between the time interval and its frequency. For example my data above would be listed at
.140625, 1
.1565, 1
.171875, 3
.1875, 5
.203125, 1
Your list should be in exactly this format, with no other symbols or characters.
MY LIST:
.171875, 5
.1835938, 2
.1875, 9
.203125, 3
.21875, 4
.234375, 1
#$&*
You may make any comments or ask any question about the process so far in the box below
COMMENTS:
- Although the mode is close to the average (whether defined as the mean or as the median), in other respects this graph doesn't fit a bell curve very well. I'm not sure whether getting a greater sample size would change this, but the fact that the second-best-represented value is at the low tail of the curve suggests that there's something other than what one might call the law of small numbers, or however one would describe the opposite of the law of large numbers, at work.
- The number of times an interval occurs is roughly (if only roughly) inversely related to the number of decimal places that it contains. Arranging the numbers in order of how many decimal places they have, breaking ties by placing lower numbers first:
- - 4: .1875, 9
- - 5: .21875, 4
- - 6: .171875, 5
- - 6: .203125, 3
- - 6: .234375, 1
- - 7: .1835938, 2
- - This relationship looks a bit simpler (explainable by lower-order patterns), so confirming it with additional data (actually, ruling out alternative hypotheses) would likely be easier than would confirming the relationship (if any) between absolute value and frequency, in that a given number of additional samples would do a lot more to clean up this pattern than it would to clean up the one above.
#$&*
On the 10 intervals I've shown you, do you really think I managed to get a time of .1875 seconds, accurate to 4 significant figures, on half of the intervals? If you do, I'm grateful for your confidence but I'm just not that good. No human being has that much neurological and muscular control.
So why do you think the TIMER program reported that time so frequently? Why weren't there times like .1830 seconds, or .1769 seconds? Does this mean that the TIMER program is flawed? Does that mean it's useless?
RESPONSE: The TIMER program reports it so frequently because the last three decimal places (.[rest]875) don't actually represent a decimal rounding; rather, they represent the rounded-off result of an alternative rounding system described below, namely a system whose final rounding algorithm is not capable of generating times like .[rest]830 and .[rest]769 but instead only decimal equivalents or decimal-rounded equivalents of (1 through 7)/8. See the more detailed HYPOTHESIS below, which explains both the presence of answers describable as ((1 through 7)/8) * 10^(-(whole number)) and the absence of answers not fitting that description, perhaps (depending on the error range discussed below) along with the program's clear preference for shorter strings.
- HYPOTHESIS: The patterns in the TIMER program's time reporting suggest that the time measurement a) begins with a more or less standard processor-cycle counting algorithm and then b) uses simple division to convert the processor-cycle count to time in seconds but then c) employs a unique number-rounding algorithm appearing to strike some kind of balance between rounding to the nearest decimal fraction (easier for humans to understand) and rounding to the nearest binary fraction (easier for the computer to understand), namely checking whether rounding to the nearest three-place binary fraction of the previous decimal fraction (binary:.001 = 1/(2^3) = 1/8 of the previous decimal fraction) is close enough for its tastes. The detailed procedure appears to be as follows:
- - 0) When the program starts, begin counting the number of processor cycles (using binary).
- - 1) When the mouse clicks, record the processor-cycle count (again using binary).
- - 2) Divide the whole-number count of processor cycles by the computer's cycles-per-second specification to get a fraction expressed in binary (both the numerator and the denominator will be very large).
- - 3) Convert this fraction to decimal form one step at a time, calculating to all whole-number base-ten places and perhaps an additional decimal place before using the following algorithm to decide whether to calculate to a further place:
- - -- 3a) LET X = the number of binary-fraction places calculated so far (i.e, 1/(2^X) and Y = the number of decimal places counted so far (i.e., 1/(10^Y)). After calculating to the Yth decimal place, calculate the whole-binary-number remainder and round it to the nearest eighth of itself (i.e., to the nearest 1/(2^(X+3)) in base-ten terms or to the nearest 0.001(X) in binary terms); doing so is equivalent to rounding the decimal value to the nearest 0.125/(10^Y) or 0.125(10^-Y). Calculate the difference between the two figures. IF this difference is within a specified range (apparently hard-coded and not user-adjustable), i.e., IF absval(unrounded figure - rounded figure) > or >= a specified value:
- - -- --- 3a1) THEN convert the rounded figure to base ten, divide it by 10^(Y+1) (that is, put Y + 1 zeroes in front of it) and add that number to the Y-decimal-place base-ten result so far. IF Y + 1 > NumberOfDecimalPlacesAvailableForDisplay (here, apparently 7):
- - -- --- ---- 3a1a) THEN round to the nearest .0000001, DISPLAY the rounded result, and STOP.
- - -- --- ---- 3a1b) ELSE DISPLAY the result as is and STOP.
- - -- --- 3a2) ELSE (i.e., IF the difference exceeds that tolerance, THEN) repeat this step 3a for the next decimal place out; that is, increase Y by 1 (count++ Y, LET Y = Y + 1, or however one commands that).
>
- - -- ???? Did the above description of the procedure make any sense at all? Did my tendency to lapse into pseudocode interfere with your ability to understand it ????
@&
Pseudocode is no problem.
Excellent explanation.
However I think a simpler explanation, which you will probably understand in more depth than I do (I program a little but only in service of the mathematics and physics and for that I don't need to go to the level, of, say, machine code). The common interval .015325 seconds is 1/64 second, or 4/256 second (both themselves binary fractions), and it seems very likely that the program utilizes a timer based on that interval.
*@
- - If the range in 3a) is very wide, such that it's very easy for even an imprecise measurement to satisfy it, that fact would explain the program's clear preference for lower numbers of decimal places and the associated shorter numerical strings.
- DATA suggesting that the above procedure is the one used:
- - GENERAL PATTERN: It appears that all these values are some kind of binary fraction of a decimal fraction (subject to rounding to the display's maximum seven decimal places), with the maximum binary denominator being 8 in base-ten or 100 in binary:
- - - .1875 = .x875 = .x plus (7/8)/10
- - - .21875 = .xx875 = .xx + (7/8)/100
- - - .171875 = .xxx875 = .xxx + (7/8)/1000
- - - .203125 = .xxx125 = .xxx + (1/8)/1000
- - - .234375 = .xxx375 = .xxx + (3/8)/1000
- - - .1835938 = RoundToSevenPlaces(.18359375) = RoundToSevenPlaces(.xxxxx375) = RoundToSevenPlaces(.xxxxx + (3/8)/10000)
- EVALUATION: ???? Did I get the algorithm right? ???? If so, the TIMER program's calculation/rounding/display algorithm is decidedly suboptimal but does not render the TIMER program entirely useless:
- - The program tends to trick users, or at least users who don't spend 3 hours figuring out its rounding algorithm and mentally reverse-compiling that algorithm's source code, into thinking that the program offers two or often three more digits of precision than it actually does. If the program purports to give a certain number of digits of precision, as it implicitly does by expressing values out to (that many + 1) decimal places, then it needs to calculate out to (that many + 2) value places and then round to (that many + 1): Rounding an expression to the nearest value place in a given base arithmetic and then converting it at face value into a higher-base arithmetic is like making a shoddy logical argument whose result is a well-formed formula in the barest sense of the term but whose process for reaching that result is not valid, let alone sound.
- - That said, once one rounds at the *fourth*-from-last decimal place, one gets a result that is at least somewhat meaningful; also, when one is dealing with large numbers extending to several whole-number value places, the imprecision in decimal points makes less of a relative difference and is likely acceptable for the purposes of this class.
#$&*
Here are a few more lines of data, with an added column showing the difference between each time interval and the next.
clock time time interval difference from one time interval to next
9 13.10938 0.1875 -0.01563
10 13.28125 0.171875 -0.01563
11 13.4375 0.15625 0.03125
12 13.625 0.1875 -0.01563
13 13.79688 0.171875 0.015625
14 13.98438 0.1875 0.015625
15 14.1875 0.203125 -0.03125
16 14.35938 0.171875 -0.01563
17 14.51563 0.15625 0.03125
Take a good look at that last column and tell us what you see in those numbers, and what this tells you about the TIMER program
RESPONSE:
- OBSERVATIONS:
- - a) The output values in the last column have string lengths that are greater on average but less variable (never truncated below five decimal places and only once extending beyond five) than those of the input values.
- - b) Both the values' minimum-to-maximum range and the apparent set of permissible values within that range are highly restricted.
- - c) These numbers fit the ((1 to 7)/8) * (10^-(whole number)) pattern just as do their input values.
- - d) [Observation of specific numbers, namely i) Value(Row9:Column1), Value(Row10:Column1), and Value(Row10:Column2) as rounded vs. their input and output values; along with (9:2), (10:2), and (10:3)]
- INFERENCES:
- - a) The output values in the last column are generated subtractively rather than additively, further confirming that the computer calculates the time as an absolute matter first and does the math to find the interval (rather than resetting the timer each time the mouse is clicked, counting until the next click, and then adding the value to a previous running total): 13.28125 - 0.171875 = 13.109375, which rounds to 13.10938 as specified. However, 13.10938 + 0.171875 = 13.281255, which rounds to 13.28126 rather than the 13.28125 specified, suggesting that the program does not perform this addition operation.
- - b) The subtraction performed to generate that column's values is performed after the timing values are rounded using the algorithm described above, and that rounding algorithm is not used again, suggesting that it is specific to the time-interval calculation: Otherwise, given that the above algorithm's rounding does not always occur at the same decimal place, we would see a wider variety of trailing-end values, as well as incorrect last-three-places rounding that doesn't appear here.
- - c) 1) The subtraction described in b) occurs pre- rather than post-decimal rounding, and 2) although the time-conversion algorithm has serious problems with digits of precision and significant digits, the base-ten calculating and rounding algorithm seems to work just fine: Although as a matter of pure math (i.e., disregarding significant figures) 0.171875 - 0.1875 = -0.015625, and although the display would permit the value -0.015625 given that it has only six decimal places, the program obeys the four-significant-figure constraint imposed by 0.1875, so it displays only the five-decimal-place, four-significant-figure -0.01563.
#$&*
Now initialize the TIMER once more, and take a series of 10 relaxed breaths. Every time you start to inhale, hit the TIMER button.
My results for the first 7 complete breaths are as follows:
series of relaxed breaths
event number clock time time interval difference between time interval and next
1 1569.734 1569.734
2 1582.75 13.01563 0.32812
3 1596.094 13.34375 3.90625
4 1613.344 17.25 2.70313
5 1633.297 19.95313 1.35937
6 1654.609 21.3125 4.23438
7 1680.156 25.54688 2.15625
8 1707.859 27.70313
I didn't go on because the time between my breaths kept increasing, and I was afraid if I relaxed any more I might stop breathing altogether. It's going to take either more statistical analysis to determine whether that's a real danger, or a little common sense.
Report your results by just entering your time intervals, one to each line, in the box below. If I was entering my results I would enter
13.01563
13.34375
17.25
19.95313
21.3125
etc.
Enter your results in the same format:
1.078125
4.101563
3.589844
3.523438
3.789063
3.886719
3.757813
3.746094
3.710938
3.683594
#$&*
If you have any comments please insert them here
I could definitely use a few deep breaths after the previous two problems!
#$&*
Most likely you did not observe the same exact time interval twice, and if you did it did not happen nearly as often as when you did the fact ??? = fast? Or did I miss a different exercise? ??? clicks.
Why do you think this is exactly what we would expect?
EXPLANATION:
- a) Even when the relative (percent) difference within different sets of multiple measurements is the same, an increase in those measurements' absolute size will correspond to an increase in the absolute size of the differences.
- b) For some reason, with the larger values, the truncation in the time-calculation algorithm occurs only at the last decimal place for these larger values: they would be 1.078125, 4.1015625, 3.58984375, 3.5234375, 3.7890625, 3.88671875, 3.7578125, 3.74609375, 3.7109375, and 3.68359375.
- -- ???? Any idea why this is? Whether the computer 1) counts passively until alerted by the mouse click or instead 2) actively initiates a check every (1/([2 or 10]^N)) seconds to see whether the mouse button is depressed, one would think that the same truncation pattern would occur regardless of interval duration. ????
@&
Like you, I'm not sure this would make a difference in the output.
The fractions 1/64 through 64/64 have the following decimal equivalents:
[0.015625, 0.03125, 0.046875, 0.0625, 0.078125, 0.09375, 0.109375, 0.125, 0.140625, 0.15625, 0.171875, 0.1875, 0.203125, 0.21875, 0.234375, 0.25, 0.265625, 0.28125, 0.296875, 0.3125, 0.328125, 0.34375, 0.359375, 0.375, 0.390625, 0.40625, 0.421875, 0.4375, 0.453125, 0.46875, 0.484375, 0.5, 0.515625, 0.53125, 0.546875, 0.5625, 0.578125, 0.59375, 0.609375, 0.625, 0.640625, 0.65625, 0.671875, 0.6875, 0.703125, 0.71875, 0.734375, 0.75, 0.765625, 0.78125, 0.796875, 0.8125, 0.828125, 0.84375, 0.859375, 0.875, 0.890625, 0.90625, 0.921875, 0.9375, 0.953125, 0.96875, 0.984375, 1]
I don't have time right now to analyze the outputs you report for some of your data and speculate (about 100 documents yet to review in tonight's batch), but clearly they don't all follow this pattern.
I assume you were using the timer.exe program, since the Java version reports only to the thousandth of a second.
*@
#$&*
Which of the following statements do you think is the most accurate?
a. The TIMER program is capable of determining the time between two events accurately to within about .1 second.
b. The TIMER program is capable of determining the time between two events accurately to within about .01 second.
c. The TIMER program is capable of determining the time between two events accurately to within about .001 second.
d. The TIMER program is capable of determining the time between two events accurately to within about .0001 second.
Enter your answer and your reasoning below:
ANSWER: If by most accurate you mean most likely to be true, then statement a) is obviously the most accurate: Not only is it the logically weakest of the statements listed, but it's Pareto-weaker in that it is true whenever any of the statements below it are true (and then some). If by most accurate you mean most precise while still being correct, in a The Price Is Right-style as high as possible without going over sense, my guess is that it's still a) in terms of the data as the program gives them to us: Although it may be able to calculate far more precisely in terms of computing cycles, when it comes to converting to seconds as expressed in base ten, nothing after the first decimal point is fully trustworthy, given that that's when the rounding to the nearest eighth rather than tenth of the next digit problem comes in.
@&
Statistically it won't be under .01 second.
It might be that the timing is accurate to within 1/64 second, and this would be reasonably consistent with the frequency distributions typically obtained on this experiment.
I've got a group of students in another class, with whom I might well be able to pursue this a little further, to everyone's benefit. We're already looking at the nature of the output of this program.
*@
#$&*
Note that the TIMER.exe program can save your data in a format that can be read by a spreadsheet (the TIMER applet cannot do so). This will be very handy in the future, so take a minute and do the following:
1. Click on the button at the lower right of the TIMER form, entitled Click to File Data.
2. A box will pop up allowing you to include an identifying message. You should generally choose to include such a message; for the data presently on your timer that might be 'series of regular breaths time at beginning of inhalation' or something similar. Type in whatever you think would serve as a good identifier for this data and OK that box.
3. A typical Save As window will appear. Decide where to save your data and what to call it, and proceed to save it. The program will save the file as a comma-delimited text file.
4. Open your spreadsheet program (typically Excel) and choose File > Open. Browse to the folder in which you just saved your data. Below the File Name line will be a File Type line; set this either to Text Files or All Files so your file will appear. Open it.
5. A series of windows will typically appear. In the first window make sure the file type chosen is Delimited, the proceed to the next window.
6. In the second window you will see a series of checkboxes; check the one entitled Comma, in order to select the comma-delimited file, then just click on Finish.
If you can't run the .exe program, you can't do Steps 1-3. However all you need to do is copy the contents of the program to a text file, using copy-and-paste. Save that text file, using any filename you wish. Then proceed with steps 4-6 above.
Your data should appear in your spreadsheet, and can be manipulated as in any spreadsheet.
Copy a few lines of the data from your spreadsheet below:
series of regular breaths - time at beginning of inhalation
event number clock time time interval
1 1.078125 1.078125
2 5.179688 4.101563
3 8.769531 3.589844
4 12.29297 3.523438
5 16.08203 3.789063
6 19.96875 3.886719
7 23.72656 3.757813
8 27.47266 3.746094
9 31.18359 3.710938
10 34.86719 3.683594
#$&*
@&
Very well done.
Check my notes. I hope to be able to follow up on this.
*@