Remove out-dated examples using mx.module

[eric-haibin-lin]

Description

After https://github.com/apache/incubator-mxnet/pull/18394/files, we have removed the mx.model.Feedforward API and related examples. Following #17676, there will be a series of PRs that enhances Gluon execution & removing mx.module API for mxnet 2.0. In this PR, I am removing most of the examples that

1. use mxnet.module.Module APIs for model training, and
2. are not actively maintained for the past few releases

Checklist

Essentials

Please feel free to remove inapplicable items for your PR.

• The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
• Changes are complete (i.e. I finished coding on this PR)
• All changes have test coverage:
• Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
• Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
• Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
• Code is well-documented:
• For user-facing API changes, API doc string has been updated.
• For new C++ functions in header files, their functionalities and arguments are documented.
• For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
• Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
• To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

• Feature1, tests, (and when applicable, API doc)
• Feature2, tests, (and when applicable, API doc)

Comments

• If this change is a backward incompatible change, why must this change be made.
• Interesting edge cases to note here

[mxnet-bot]

Hey @eric-haibin-lin , Thanks for submitting the PR
All tests are already queued to run once. If tests fail, you can trigger one or more tests again with the following commands:

• To trigger all jobs: @mxnet-bot run ci [all]
• To trigger specific jobs: @mxnet-bot run ci [job1, job2]

---

CI supported jobs: [centos-gpu, clang, miscellaneous, unix-gpu, website, windows-cpu, windows-gpu, unix-cpu, sanity, edge, centos-cpu]

---

Note:
Only following 3 categories can trigger CI :PR Author, MXNet Committer, Jenkins Admin.
All CI tests must pass before the PR can be merged.

[ChaiBapchya]

While we remove the outdated examples [as module api is no longer supported], would it be a good idea to update these examples to use the correct API [replacement of module] instead of removing these examples altogether?

[eric-haibin-lin]

@ChaiBapchya as you can see the number of examples affected is large and it requires lots of efforts to rewrite all of them. While I am happy to create a github issue listing them and welcome contribution from the community, one problem is that these examples are not really tested in the CI pipeline, which makes it hard to maintain

[ChaiBapchya]

Right. One issue MXNet users face is the lack of examples & documentation around it.
Removing existing examples without substituting with working equivalent code would only exacerbate. I'm not sure if MXNet users come to Github repo for these examples & what was the purpose of pushing examples in this repository.

Makes sense to create a Github Issue to call for contributions from the community.

[eric-haibin-lin]

created an issue #18458

[leezu]

@ChaiBapchya I think another issue is the prevalence of outdated examples. As developers can always access the outdated examples via the git history and the list of examples is tracked in #18458, let's merge this PR

[yifeim]

The factorization machine module is quite useful. Is it possible to bring back under Gluon? Thanks.

[yifeim]

@ChaiBapchya as you can see the number of examples affected is large and it requires lots of efforts to rewrite all of them. While I am happy to create a github issue listing them and welcome contribution from the community, one problem is that these examples are not really tested in the CI pipeline, which makes it hard to maintain

Isn't this the problem to solve?

[ChaiBapchya]

Testing all these examples in CI is

• big task in itself
• quite expensive [as currently we don't have a smart way of testing in CI [selective testing based on code coverage for starters]. We can't expect to test every example for every single PR sent to the repository.

Having said that, if someone in the community is willing to volunteer to
a. Add the working version of the dropped examples to repository
b. Add corresponding tests in CI
c. [Preferably] Find a way to only test these examples when corresponding code is changed
Then that's a silver bullet!

[yifeim]

Testing all these examples in CI is

• big task in itself
• quite expensive [as currently we don't have a smart way of testing in CI [selective testing based on code coverage for starters]. We can't expect to test every example for every single PR sent to the repository.

Having said that, if someone in the community is willing to volunteer to
a. Add the working version of the dropped examples to repository
b. Add corresponding tests in CI
c. [Preferably] Find a way to only test these examples when corresponding code is changed
Then that's a silver bullet!

• run all examples once and index the code blocks that are executed.
• build a reverse index for new codes submitted.
• update the reverse index after the codes are merged.
• rinse and repeat as a general library.

If people haven't built it, it seems to be a useful tool to have.