WEBVTT

1
00:00:01.920 --> 00:00:07.700
ok so let's continue on now with our
discussion about time and date time and

2
00:00:07.700 --> 00:00:12.210
just to confirm that the actual program we
used this reaction game again is very

3
00:00:12.210 --> 00:00:16.150
simple it uses the random module to
generate a random number of seconds from

4
00:00:16.150 --> 00:00:20.029
one to six then it slept for that amount
of time and it woke up and of course you

5
00:00:20.029 --> 00:00:25.070
have to press enter as soon as you got the prompt
to stop and it measure your time now I did allude to the

6
00:00:25.070 --> 00:00:29.590
last video that there are problems with this program
so first one was of course as you saw me

7
00:00:29.590 --> 00:00:35.760
in the last video do I manage to cheat by pressing enter twice to start with and as a result

8
00:00:35.760 --> 00:00:40.359
it came up with a really really fast time
of .000 of a second which would

9
00:00:40.359 --> 00:00:43.969
ordinarily be impossible for a human more
or less now other problem was that

10
00:00:43.969 --> 00:00:48.969
if your playing around the time the
daylight saving start or ends then

11
00:00:48.969 --> 00:00:54.139
the display time could indicate that it could taken
over an hour to press enter in spring or the

12
00:00:54.139 --> 00:00:58.249
end time could be displayed as an hour
before the start time in autumn so that's

13
00:00:58.249 --> 00:01:01.819
obviously not a problem as well and the
other issues of course the system clock

14
00:01:01.819 --> 00:01:06.149
itself could be changed while waiting
for the player to press enter so many

15
00:01:06.149 --> 00:01:09.700
computers now keep their clocks
synchronized with the time server on the

16
00:01:09.700 --> 00:01:13.810
local network or the Internet and as
the computer's clock drifts its

17
00:01:13.810 --> 00:01:19.479
automatically reset so it is
basically completely on track and showing

18
00:01:19.479 --> 00:01:23.259
the right time or keeping the correct
time and in actual fact the

19
00:01:23.259 --> 00:01:27.049
documentation for the time functions does
mention this so when the function

20
00:01:27.049 --> 00:01:31.020
normally returns non decreasing values
it can return lower value than a

21
00:01:31.020 --> 00:01:38.500
previous call if system clock has been set back
between the two calls

22
00:01:38.500 --> 00:01:43.100
and that's this little bit here now the thing is Python now provides three more

23
00:01:43.100 --> 00:01:47.280
functions that we could use instead of
the time function now if you want to

24
00:01:47.280 --> 00:01:51.770
measure elapsed time as we did in our
code so these three functions we are

25
00:01:51.770 --> 00:01:55.830
about to talk about were introduced in
Python 3.3 and we are going to have a look at

26
00:01:55.830 --> 00:02:01.080
each one of these in turn by changing the
import on line 2 so go back and do that well I

27
00:02:01.080 --> 00:02:06.170
said line 2 I'm talking about line 12 I should say so from time import as my_timer

28
00:02:06.170 --> 00:02:13.989
so we're going to do now is change time to
perf_counter and you can see

29
00:02:13.989 --> 00:02:19.570
the advantage of setting this up
as we've done because we still got the my_timer

30
00:02:19.570 --> 00:02:23.000
functions showing down here so we do not have change any other code other than

31
00:02:23.000 --> 00:02:26.670
the single import now what this does is
this gives an accurate measure of the elapsed

32
00:02:26.670 --> 00:02:32.800
time but the value returned doesn't
represent an actual time so although we can

33
00:02:32.800 --> 00:02:36.709
calculate the difference between the two
times it returns when we try to convert them

34
00:02:36.709 --> 00:02:40.640
to local time the result printed out isn't going to be the current time so we can run that

35
00:02:40.640 --> 00:02:46.290
to see

36
00:02:46.290 --> 00:02:55.650
ok go on here and press enter start now the perf_counter is
the most precise clock and where

37
00:02:55.650 --> 00:03:00.420
it really shines and its very useful is for
bench marking in code as in one example now

38
00:03:00.420 --> 00:03:04.519
it's used by the trace and time modules that we can be looking at later

39
00:03:04.519 --> 00:03:08.510
to get an idea of the performance of
functions that we wrote the next one is

40
00:03:08.510 --> 00:03:13.980
the monotonic function and this behaves very
similarly and in fact it can be very

41
00:03:13.980 --> 00:03:19.230
difficult to see any differences between
monotonic and perf_counter so perf_counter can

42
00:03:19.230 --> 00:03:24.170
have a higher resolution on some systems so
it makes sense to use that

43
00:03:24.170 --> 00:03:28.760
rather than monotonic but will change line 12
again now anyway to see how monotonic or

44
00:03:28.760 --> 00:03:35.250
how the monotonic function works so change perf_counter to....

45
00:03:35.250 --> 00:03:49.730
..and we can run that....ok you can see that its work like the previous example we are getting very similar results now if

46
00:03:49.730 --> 00:03:54.350
a clock interesting enough is described
as monotonic what that means is that the

47
00:03:54.350 --> 00:03:58.540
time can't go backwards and it's always
 rules out any adjustment as a

48
00:03:58.540 --> 00:04:03.120
result of daylight saving but also means that
adjustments to the computer's clock will

49
00:04:03.120 --> 00:04:08.060
also not affect the times returned
by a monotonic clock now these three

50
00:04:08.060 --> 00:04:13.090
functions the original one we use
the time but also perf_counter and

51
00:04:13.090 --> 00:04:17.950
monotonic have allowed us to calculate
the actual elapsed time so the fourth

52
00:04:17.950 --> 00:04:22.470
function we gonna look at it now is called
process_time now

53
00:04:22.470 --> 00:04:26.390
process_time is not really
appropriate for this little game and

54
00:04:26.390 --> 00:04:30.140
that's because it returns the time that
the CPU spends executing the current

55
00:04:30.140 --> 00:04:35.860
process rather than the actual elapsed
time but we just going to give it a test anyways so you

56
00:04:35.860 --> 00:04:47.129
can see the results so change it to process...so run that

57
00:04:47.129 --> 00:04:56.699
so you can see the reported reaction time is much smaller
than previously and the reason that it's

58
00:04:56.699 --> 00:05:00.529
only the amount of time spent on the
actual CPU is being recorded

59
00:05:00.529 --> 00:05:05.360
not the elapsed time so we're process_time is useful is for things

60
00:05:05.360 --> 00:05:11.389
like profiling code and in actual fact
it's use by the Python profile module a

61
00:05:11.389 --> 00:05:14.339
module which we will also be looking at
later in the course ok so lets

62
00:05:14.339 --> 00:05:18.659
close it down now to summarize here if
you want to measure actual elapse

63
00:05:18.659 --> 00:05:23.080
time then use the perf_counter
function that's really the best way or

64
00:05:23.080 --> 00:05:26.929
the best function if you wanna know how
much time the CPU is spent on a

65
00:05:26.929 --> 00:05:32.389
particular task then used process_time now to deal with real times

66
00:05:32.389 --> 00:05:37.059
rather than just measuring
durations use the time function and

67
00:05:37.059 --> 00:05:41.300
that just leaves the monotonic function
at the moment it doesn't seem to be any

68
00:05:41.300 --> 00:05:45.009
compelling reason to use that against
one of the other options on literally

69
00:05:45.009 --> 00:05:49.519
any operating system so despite its
name is not the only monotonic clock

70
00:05:49.519 --> 00:05:53.990
available in Python because both perf_counter and process_time are also

71
00:05:53.990 --> 00:05:57.809
monotonic if you want more information
on these functions the reasons why they are

72
00:05:57.809 --> 00:06:01.419
implemented and discussed in pep 0418 and that's available

73
00:06:01.419 --> 00:06:11.729
online and I'm going copy and open it up we are going to go back to the browser and pep by the way stands for Python

74
00:06:11.729 --> 00:06:16.099
enhancement proposal and its proposals
such as this one that resulted in the

75
00:06:16.099 --> 00:06:20.869
language involving so you can see
the original proposal was created on 26

76
00:06:20.869 --> 00:06:25.199
March 2012 to add monotonic time
performance counter and process time

77
00:06:25.199 --> 00:06:29.029
functions now the things is if your reading them
you'll find that they are really quite

78
00:06:29.029 --> 00:06:33.219
technical reading the pep for a
particular language feature can be

79
00:06:33.219 --> 00:06:37.539
really useful if you're struggling to
work out something about the

80
00:06:37.539 --> 00:06:42.039
documentation something out from the
documentation because you can gain really useful insight

81
00:06:42.039 --> 00:06:45.639
into why the feature was provided and
why it was implemented in a particular

82
00:06:45.639 --> 00:06:49.110
way ok so it's time for a challenge so
let's go back and do that i'm gonna

83
00:06:49.110 --> 00:06:54.780
create a new Python file for this
and I'm just gonna call it challenge

84
00:06:54.780 --> 00:07:02.500
and paste in the challenge ok so your
challenge to write a small program to

85
00:07:02.500 --> 00:07:06.400
display information on the 4 clocks
whose functions we just looked at

86
00:07:06.400 --> 00:07:11.950
and of course they are time perf_counter
monotonic and process_time and

87
00:07:11.950 --> 00:07:15.590
use a documentation for the get_clock_info function

88
00:07:15.590 --> 00:07:20.980
to work it how to call it for each of the
clocks so go away and do that now and when

89
00:07:20.980 --> 00:07:25.889
you're ready to come back and see the
solution start the video again and I'll go through that with you then

90
00:07:25.889 --> 00:07:32.160
so pause the video now...

91
00:07:32.160 --> 00:07:36.290
ok so how did you get on hopefully you
manage to solve it and did you look up

92
00:07:36.290 --> 00:07:40.140
the documentation for get_clock_info so let's have a look at the

93
00:07:40.140 --> 00:07:45.430
documentation first will go back to the browser
and go back to the documentation that

94
00:07:45.430 --> 00:07:49.600
we first opened in the previous
video and it is on that page so if we go away

95
00:07:49.600 --> 00:07:55.180
now and have a look for get_clock_info

96
00:07:55.180 --> 00:07:59.800
...we can see it on the screen there
and that gives us the information we

97
00:07:59.800 --> 00:08:05.790
need to be able to call the various
methods so going back and typing

98
00:08:05.790 --> 00:08:13.230
that code so we need to import our module
first...so let's now go ahead

99
00:08:13.230 --> 00:08:19.490
and do the first one the regular one time and we can do that with filing and what we can is just

100
00:08:19.490 --> 00:08:23.000
put an indication in the print as to which one we are calling and add a few tabs the

101
00:08:23.000 --> 00:08:32.719
to tab it nicely the first one is time...we saw
that on the web page and the parameters is time

102
00:08:32.719 --> 00:08:42.130
and we can do something similar for the other 3 and I'm just going to do that 1 2 3 and the second we are going to call is perf_counter

103
00:08:42.130 --> 00:08:47.960
...because it's a longer word we're just gonna have one

104
00:08:47.960 --> 00:08:53.870
tab for that... is going
to be the parameter or the argument

105
00:08:53.870 --> 00:09:15.610
next one is monotonic... and that is also a longer word so it only needs the 1 tab and the argument is....and last one is process_time...

106
00:09:15.610 --> 00:09:31.630
..that also needs the 1 tab...that should be monotonic but it not really matters because it is just a print out but  we will actually run that now actually we have to right click

107
00:09:31.630 --> 00:09:38.200
it because we opened a new file run challenge and there is the 4 examples their now looking at the examples

108
00:09:38.200 --> 00:09:39.820
and you notice the first one time

109
00:09:39.820 --> 00:09:43.430
adjustables is true that means that the
clock can be adjusted with daylight

110
00:09:43.430 --> 00:09:48.220
saving etc so it's not therefore
surprising that monotonic and adjustable

111
00:09:48.220 --> 00:09:53.320
are mutually exclusive so in the case of perf_counter monotonic and process_time

112
00:09:53.320 --> 00:09:57.750
we mentioned that they
are all monotonic so

113
00:09:57.750 --> 00:10:01.610
therefore the adjustable is set to false
because the time cannot be changed and I

114
00:10:01.610 --> 00:10:08.399
just made a typo their so I should fix that up that should have been tab \t it does not matter too much but will run

115
00:10:08.399 --> 00:10:12.220
that in any way now the other thing
to note is that the get_clock_info

116
00:10:12.220 --> 00:10:16.529
function also returns the
resolution of the clock and also the

117
00:10:16.529 --> 00:10:20.630
underlying routine that's used to
implement it so on Linux you get something

118
00:10:20.630 --> 00:10:22.190
completely different

119
00:10:22.190 --> 00:10:25.420
you find that both perf_counter

120
00:10:25.420 --> 00:10:28.500
and monotonic are implemented
in the same way and have the same

121
00:10:28.500 --> 00:10:32.779
resolution in Windows 10 you get a
different result you find that you

122
00:10:32.779 --> 00:10:36.360
should find perf_counter has much
higher resolution than monotonic and you

123
00:10:36.360 --> 00:10:40.230
can see here on the Mac we've got the
perf_counter and monotonic both use

124
00:10:40.230 --> 00:10:44.550
mach_absolute_time and time uses
get time of day the implementation and

125
00:10:44.550 --> 00:10:48.839
process_time uses another one
as well which is get rusage so there you go

126
00:10:48.839 --> 00:10:54.769
that is our discussion or our challenge completed
now for time so in the next video

127
00:10:54.769 --> 00:10:57.940
what we're going to do now is expand
upon and start looking more

128
00:10:57.940 --> 00:11:02.709
at dates and date time rather that times we are just pretty well focused on the last two

129
00:11:02.709 --> 00:11:04.329
videos so I'll see you in the next video