These comments explain how each 'section' works with the data. There
mostly here for when I come back to this months/years from now and
I've forgotten how this code works. The other scenarios this is for --
although very unlikely -- is other people new to the project and need
a helping hand.
Having filtered down the list to readings which suppass the Hertz
threshold (4+ per-second at time of writing), the code here filters it
down even more. This bit of code searches for readings within this
already filtered list for any readings which activate the light in the
gallery (with the threshold matching that of 'gallery1' which in
anything over 39). It then proceeds to save the results.
This functions goes through the list of readings and forms a
dictionary of time-stamps, with light readings beyond a specified
readings-per-second threshold, and the reading for said time-stamp.
The results are then saved to the specified file, using
'save_rps_totals' function.
This replaces the original way of doing it with a dictionary. The
change was brought about because the previous data loading function
was omitting duplicate entries (I.E. multiple readings from the same
second in time).
I, also, removed the load_data function. This is part of the gradual
move to transfer 'service' based functions out of flicker.py. The aim
here is to reduce the need for duplicating code or make it easier to
make function calls when needing a particular piece of data (or
transformation of data).
I've began getting into a mess with trying to use duplicated code and
data. I've began to move functions to their own services folder and
files to help reduce the duplication.
The code in this file is mostly to get the ball moving in this
repository. This file opens the
'light-meter-sample-readings-23-04-2021-ritherdon.csv' file and
tallies-up the number of requests per second groups. After that, it
writes the results to 23-04-2021-readings-per-sec.csv.
As an example (to help explain), it counts and stores how many times
the light meter (factory1) took a reading at the rate of two times per
second. In this instance, there were 2955 instances of the light meter
taking two readings per second. This roughly equates to 10% of the
days readings was at a rate of two requests per second. 28% of the
time the light meter was recording at four requests per second, 18%
for one and 44% for three.
Craig Oates