Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add a default PruningPolicy that filters out any layers not supported by the API

Open
  • Is something wrong?
#1,098 1 comment 0 reactions 1 assignee View on GitHub

@lenscloth is already working on this.

Since Oct 4, 2023.

Assessment

This issue has not been assessed yet.

Description

feature request

Hi TFMOT team! I have created a workaround for an edge-case in my project, and in my head it should be possible to have it be the default behavior in the API. Creating this feature request as a suggestion - let me know what you think!

System information

Running on TF 2.11. Unfortunately, I currently don't have the bandwidth to contribute the feature request.

Motivation

This feature request is for an implementation of the PruningPolicy that allows pruning for layers that are supported by the PruningRegistry.

Short background. When calling the prune_low_magnitude or similar functions, it's possible to ignore certain layers according to a pruning policy. By implementing the abstract class PruningPolicy, you can check that the model and layers fulfill certain requirements. One built-in implementation of this already exists, namely the PruneForLatencyOnXNNPack. A call can look like this:

model = prune_low_magnitude(
      keras.Sequential([
          layers.Dense(10, activation='relu', input_shape=(100,)),
          layers.Dense(2, activation='sigmoid')
      ]),
      pruning_policy=PruneForLatencyOnXNNPack(),
      **pruning_params)

Currently, since no pruning policy is default, the API will try and prune layers that are not compatible. In one of our use-cases, we had to implement a policy that checks if the layer is supported (to avoid trying to prune a TFOpLambda layer, as an example). Explicitly, we are safeguarding the API by skipping data that itself knows that it doesn't support. I'm suggesting to add another implementation to the API, which simply calls the supports function linked above. If possible, I'd also use it as a default value for the pruning_policy parameter (this part may come with additional issues for some use-cases, so that would be an optional part of this feature request).

I think it would help people using the API to avoid confusing bugs in edge-cases. If there's an existing way to do this that we have overlooked, I'm happy to get that feedback. Let me know if the suggestion needs elaboration.

Thank you for your time!
Annie

Dominant language
Python
Stars
1.6k
Forks
349
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from tensorflow/model-optimization

All issues in tensorflow/model-optimization

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.