1
00:00:05,380 --> 00:00:11,160
ok so let's continue on now with our
discussion about time and date time and

2
00:00:11,160 --> 00:00:15,670
just to confirm that the actual program we
used this reaction game again is very

3
00:00:15,670 --> 00:00:19,610
simple it uses the random module to
generate a random number of seconds from

4
00:00:19,610 --> 00:00:23,480
one to six then it slept for that amount
of time and it woke up and of course you

5
00:00:23,480 --> 00:00:28,530
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:28,530 --> 00:00:33,050
last video that there are problems with this program
so first one was of course as you saw me

7
00:00:33,050 --> 00:00:39,220
in the last video do I manage to cheat by pressing enter twice to start with and as a result

8
00:00:39,220 --> 00:00:43,810
it came up with a really really fast time
of .000 of a second which would

9
00:00:43,810 --> 00:00:47,420
ordinarily be impossible for a human more
or less now other problem was that

10
00:00:47,420 --> 00:00:52,420
if your playing around the time the
daylight saving start or ends then

11
00:00:52,420 --> 00:00:57,590
the display time could indicate that it could taken
over an hour to press enter in spring or the

12
00:00:57,590 --> 00:01:01,700
end time could be displayed as an hour
before the start time in autumn so that's

13
00:01:01,700 --> 00:01:05,269
obviously not a problem as well and the
other issues of course the system clock

14
00:01:05,269 --> 00:01:09,600
itself could be changed while waiting
for the player to press enter so many

15
00:01:09,600 --> 00:01:13,160
computers now keep their clocks
synchronized with the time server on the

16
00:01:13,160 --> 00:01:17,270
local network or the Internet and as
the computer's clock drifts its

17
00:01:17,270 --> 00:01:22,930
automatically reset so it is
basically completely on track and showing

18
00:01:22,930 --> 00:01:26,710
the right time or keeping the correct
time and in actual fact the

19
00:01:26,710 --> 00:01:30,500
documentation for the time functions does
mention this so when the function

20
00:01:30,500 --> 00:01:34,480
normally returns non decreasing values
it can return lower value than a

21
00:01:34,480 --> 00:01:41,960
previous call if system clock has been set back
between the two calls

22
00:01:41,960 --> 00:01:46,560
and that's this little bit here now the thing is Python now provides three more

23
00:01:46,560 --> 00:01:50,740
functions that we could use instead of
the time function now if you want to

24
00:01:50,740 --> 00:01:55,230
measure elapsed time as we did in our
code so these three functions we are

25
00:01:55,230 --> 00:01:59,290
about to talk about were introduced in
Python 3.3 and we are going to have a look at

26
00:01:59,290 --> 00:02:04,540
each one of these in turn by changing the
import on line 2 so go back and do that well I

27
00:02:04,540 --> 00:02:09,630
said line 2 I'm talking about line 12 I should say so from time import as my_timer

28
00:02:09,630 --> 00:02:17,440
so we're going to do now is change time to
perf_counter and you can see

29
00:02:17,440 --> 00:02:23,030
the advantage of setting this up
as we've done because we still got the my_timer

30
00:02:23,030 --> 00:02:26,460
functions showing down here so we do not have change any other code other than

31
00:02:26,460 --> 00:02:30,130
the single import now what this does is
this gives an accurate measure of the elapsed

32
00:02:30,130 --> 00:02:36,260
time but the value returned doesn't
represent an actual time so although we can

33
00:02:36,260 --> 00:02:40,160
calculate the difference between the two
times it returns when we try to convert them

34
00:02:40,160 --> 00:02:44,100
to local time the result printed out isn't going to be the current time so we can run that

35
00:02:44,100 --> 00:02:49,750
to see

36
00:02:49,750 --> 00:02:59,110
ok go on here and press enter start now the perf_counter is
the most precise clock and where

37
00:02:59,110 --> 00:03:03,880
it really shines and its very useful is for
bench marking in code as in one example now

38
00:03:03,880 --> 00:03:07,970
it's used by the trace and time modules that we can be looking at later

39
00:03:07,970 --> 00:03:11,970
to get an idea of the performance of
functions that we wrote the next one is

40
00:03:11,970 --> 00:03:17,440
the monotonic function and this behaves very
similarly and in fact it can be very

41
00:03:17,440 --> 00:03:22,690
difficult to see any differences between
monotonic and perf_counter so perf_counter can

42
00:03:22,690 --> 00:03:27,630
have a higher resolution on some systems so
it makes sense to use that

43
00:03:27,630 --> 00:03:32,220
rather than monotonic but will change line 12
again now anyway to see how monotonic or

44
00:03:32,220 --> 00:03:38,710
how the monotonic function works so change perf_counter to....

45
00:03:38,710 --> 00:03:53,190
..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:53,190 --> 00:03:57,810
a clock interesting enough is described
as monotonic what that means is that the

47
00:03:57,810 --> 00:04:02,000
time can't go backwards and it's always
rules out any adjustment as a

48
00:04:02,000 --> 00:04:06,580
result of daylight saving but also means that
adjustments to the computer's clock will

49
00:04:06,580 --> 00:04:11,520
also not affect the times returned
by a monotonic clock now these three

50
00:04:11,520 --> 00:04:16,550
functions the original one we use
the time but also perf_counter and

51
00:04:16,550 --> 00:04:21,410
monotonic have allowed us to calculate
the actual elapsed time so the fourth

52
00:04:21,410 --> 00:04:25,930
function we gonna look at it now is called
process_time now

53
00:04:25,930 --> 00:04:29,850
process_time is not really
appropriate for this little game and

54
00:04:29,850 --> 00:04:33,600
that's because it returns the time that
the CPU spends executing the current

55
00:04:33,600 --> 00:04:39,320
process rather than the actual elapsed
time but we just going to give it a test anyways so you

56
00:04:39,320 --> 00:04:50,580
can see the results so change it to process...so run that

57
00:04:50,580 --> 00:05:00,150
so you can see the reported reaction time is much smaller
than previously and the reason that it's

58
00:05:00,150 --> 00:05:03,980
only the amount of time spent on the
actual CPU is being recorded

59
00:05:03,980 --> 00:05:08,820
not the elapsed time so we're process_time is useful is for things

60
00:05:08,820 --> 00:05:14,840
like profiling code and in actual fact
it's use by the Python profile module a

61
00:05:14,840 --> 00:05:17,790
module which we will also be looking at
later in the course ok so lets

62
00:05:17,790 --> 00:05:22,110
close it down now to summarize here if
you want to measure actual elapse

63
00:05:22,110 --> 00:05:26,540
time then use the perf_counter
function that's really the best way or

64
00:05:26,540 --> 00:05:30,380
the best function if you wanna know how
much time the CPU is spent on a

65
00:05:30,380 --> 00:05:35,840
particular task then used process_time now to deal with real times

66
00:05:35,840 --> 00:05:40,510
rather than just measuring
durations use the time function and

67
00:05:40,510 --> 00:05:44,760
that just leaves the monotonic function
at the moment it doesn't seem to be any

68
00:05:44,760 --> 00:05:48,460
compelling reason to use that against
one of the other options on literally

69
00:05:48,460 --> 00:05:52,970
any operating system so despite its
name is not the only monotonic clock

70
00:05:52,970 --> 00:05:57,450
available in Python because both perf_counter and process_time are also

71
00:05:57,450 --> 00:06:01,260
monotonic if you want more information
on these functions the reasons why they are

72
00:06:01,260 --> 00:06:04,870
implemented and discussed in pep 0418 and that's available

73
00:06:04,870 --> 00:06:15,180
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:15,180 --> 00:06:19,550
enhancement proposal and its proposals
such as this one that resulted in the

75
00:06:19,550 --> 00:06:24,320
language involving so you can see
the original proposal was created on 26

76
00:06:24,320 --> 00:06:28,650
March 2012 to add monotonic time
performance counter and process time

77
00:06:28,650 --> 00:06:32,480
functions now the things is if your reading them
you'll find that they are really quite

78
00:06:32,480 --> 00:06:36,670
technical reading the pep for a
particular language feature can be

79
00:06:36,670 --> 00:06:40,990
really useful if you're struggling to
work out something about the

80
00:06:40,990 --> 00:06:45,490
documentation something out from the
documentation because you can gain really useful insight

81
00:06:45,490 --> 00:06:49,090
into why the feature was provided and
why it was implemented in a particular

82
00:06:49,090 --> 00:06:52,570
way ok so it's time for a challenge so
let's go back and do that i'm gonna

83
00:06:52,570 --> 00:06:58,240
create a new Python file for this
and I'm just gonna call it challenge

84
00:06:58,240 --> 00:07:05,960
and paste in the challenge ok so your
challenge to write a small program to

85
00:07:05,960 --> 00:07:09,860
display information on the 4 clocks
whose functions we just looked at

86
00:07:09,860 --> 00:07:15,410
and of course they are time perf_counter
monotonic and process_time and

87
00:07:15,410 --> 00:07:19,050
use a documentation for the get_clock_info function

88
00:07:19,050 --> 00:07:24,440
to work it how to call it for each of the
clocks so go away and do that now and when

89
00:07:24,440 --> 00:07:29,340
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:29,340 --> 00:07:35,620
so pause the video now...

91
00:07:35,620 --> 00:07:39,750
ok so how did you get on hopefully you
manage to solve it and did you look up

92
00:07:39,750 --> 00:07:43,600
the documentation for get_clock_info so let's have a look at the

93
00:07:43,600 --> 00:07:48,890
documentation first will go back to the browser
and go back to the documentation that

94
00:07:48,890 --> 00:07:53,060
we first opened in the previous
video and it is on that page so if we go away

95
00:07:53,060 --> 00:07:58,640
now and have a look for get_clock_info

96
00:07:58,640 --> 00:08:03,260
...we can see it on the screen there
and that gives us the information we

97
00:08:03,260 --> 00:08:09,250
need to be able to call the various
methods so going back and typing

98
00:08:09,250 --> 00:08:16,690
that code so we need to import our module
first...so let's now go ahead

99
00:08:16,690 --> 00:08:22,950
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:22,950 --> 00:08:26,460
put an indication in the print as to which one we are calling and add a few tabs the

101
00:08:26,460 --> 00:08:36,169
to tab it nicely the first one is time...we saw
that on the web page and the parameters is time

102
00:08:36,169 --> 00:08:45,590
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:45,590 --> 00:08:51,420
...because it's a longer word we're just gonna have one

104
00:08:51,420 --> 00:08:57,330
tab for that... is going
to be the parameter or the argument

105
00:08:57,330 --> 00:09:19,070
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:19,070 --> 00:09:35,090
..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:35,090 --> 00:09:41,660
it because we opened a new file run challenge and there is the 4 examples their now looking at the examples

108
00:09:41,660 --> 00:09:43,280
and you notice the first one time

109
00:09:43,280 --> 00:09:46,890
adjustables is true that means that the
clock can be adjusted with daylight

110
00:09:46,890 --> 00:09:51,680
saving etc so it's not therefore
surprising that monotonic and adjustable

111
00:09:51,680 --> 00:09:56,780
are mutually exclusive so in the case of perf_counter monotonic and process_time

112
00:09:56,780 --> 00:10:01,210
we mentioned that they
are all monotonic so

113
00:10:01,210 --> 00:10:05,070
therefore the adjustable is set to false
because the time cannot be changed and I

114
00:10:05,070 --> 00:10:11,850
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:11,850 --> 00:10:15,680
that in any way now the other thing
to note is that the get_clock_info

116
00:10:15,680 --> 00:10:19,980
function also returns the
resolution of the clock and also the

117
00:10:19,980 --> 00:10:24,090
underlying routine that's used to
implement it so on Linux you get something

118
00:10:24,090 --> 00:10:25,650
completely different

119
00:10:25,650 --> 00:10:28,880
you find that both perf_counter

120
00:10:28,880 --> 00:10:31,960
and monotonic are implemented
in the same way and have the same

121
00:10:31,960 --> 00:10:36,230
resolution in Windows 10 you get a
different result you find that you

122
00:10:36,230 --> 00:10:39,820
should find perf_counter has much
higher resolution than monotonic and you

123
00:10:39,820 --> 00:10:43,690
can see here on the Mac we've got the
perf_counter and monotonic both use

124
00:10:43,690 --> 00:10:48,010
mach_absolute_time and time uses
get time of day the implementation and

125
00:10:48,010 --> 00:10:52,290
process_time uses another one
as well which is get rusage so there you go

126
00:10:52,290 --> 00:10:58,220
that is our discussion or our challenge completed
now for time so in the next video

127
00:10:58,220 --> 00:11:01,400
what we're going to do now is expand
upon and start looking more

128
00:11:01,400 --> 00:11:06,160
at dates and date time rather that times we are just pretty well focused on the last two

129
00:11:06,160 --> 00:11:07,780
videos so I'll see you in the next video

