Two places in the documentation gave the wrong path to the example
Alexnet sensitivity pruning schedule.

The latest changes to the logger caused the CI tests to fail,
because test assumes that the logging.conf file is present in the
same directory as the sample application script.
The sample application used cwd() instead, and did not find the
log configuration file.

Soon we will be reusing this function in other sample apps, so let's
move it to app_utils.

The 'master' branch now uses PyTorch 0.4, which has API changes that
are not backward compatible with PyTorch 0.3.

After we've upgraded Distiller's internal implementation to be
compatible with PyTorch 0.4, we've added a check that you are using
the correct PyTorch version.

Note that we only perform this check in the sample image classifier
compression application.

Work on the 'master' branch uses pre-release version numbers.
After releasing v0.1.0 with PyTorch 0.3, we have upgraded 'master'
to support PyTorch 0.4 which contains API changes which are not
backward compatible.

Eventually we will want to use this code in other sample applications,
so let's move the logger configuration code to a separate function.

There's a bit of ugly hacking in this current implementation because
I've added variable members to logging.logger.  These are actaully
config-once variables that convey the logging directory and filename.
I did not want to add more names to the global namespace, so I hacked
a temporary solution in which logging.logger is acts as a conveyor and
private namespace.  We'll get that cleaned up as we do more refactoring.

PyTorch 0.4 now fully supports the ONNX export features that are needed
in order to create a SummaryGraph, which is sort of a "shadow graph" for
PyTorch models.

The big advantage of SummaryGraph is that it gives us information about
the connectivity of nodes.  With connectivity information we can compute
per-node MAC (compute) and BW, and better yet, we can remove channels,
filters, and layers (more on this in future commits).

In this commit we (1) replace the long and overly-verbose ONNX node names,
with PyTorch names; and (2) move MAC and BW attributes from the Jupyter
notebook to the SummaryGraph.

This is a niche feature, which lets you print the names of the modules
in a model, from the command-line.
Non-leaf nodes are excluded from this list.  Other caveats are documented
in the code.

Data parallel models may execute faster on multiple GPUs, but rendering
them creates visually complex and illegible graphs.
Therefore, when creating models for a PNG summary, we opt to use
non-parallel models.

When we are traversing the forward path of a graph, by invoking each
module's forward_hook callback, we sometimes want to know the full
name of the module.
Previously, to infer the module name, we looked up the name of self.weight
parameter and used that to get the module name.
In PyTorch 0.4 we can directly look up the module name using
model_find_module_name.

Various small changes due to the chamnges in the semantics and syntax of the
PyTorch 0.4 API.

Note that currently distiller.model_performance_summary() returns wrong results
on graphs containing torch.nn.DataParallel layers.

Following https://pytorch.org/2018/04/22/0_4_0-migration-guide.html, we
need to be more precise in how we use .type()

Eventually the application will pass a torch.device to the Scheduler.
Now we just create a default device in the constructor, and then use it.

Fix the path to the example schedule for ImageNet baseline training,
and to the ImageNet dataset

fix path to the resnet20 checkpoint in one of the examples

ONNX is not required by the use-cases currently supported.