In 1972, I developed (and published!) an infinitely differentiable soft sparsity engine based on metrics and tensors that avoided basis collapse and generated an approximate MLE solution, which apparently (according to multiple AIs) is being independently rediscovered today in ML/AI. The paper became a “sleeping beauty”. I have posted some of the Fortran code on GitHub and Zenodo and will be posting the underlying mathematics in markdown on these sites as well. I would like to contribute this material to the community. The model can be extended to large NNs using metric fields through which the BP gradients can somehow be passed. Originally, I applied the mathematics to solving the oblique simple structure problem in factor analysis, but the math is general, and easily extended. I would like to hear from anyone interested in this.
I would like to post the maths and the olde Forran code for a the metric-based sparsity engine from circa 1973. It uses C-inf loss functions, a metric and its inverse for endogenous adaptation and avoidance of singularity (no need for user set parameters), and more. I think it would be useful for the modern ML community. One AI said post the material to a “Model Card”. Is this the right approach?
Hmm… I’m not the right person to judge the math, but if the question is where to publish what in and around Hugging Face, my rough map would be something like this:
Very short version: for historical maths + Fortran code, I would probably use GitHub as the primary home.
Then:
- GitHub — code, notes, examples, license, citation file, releases
- Zenodo / DOI — stable citable archive
- HF Dataset repo — sample inputs/outputs, reproduced results, benchmark files, toy matrices, reproducibility package
- HF Space — interactive demo people can try in the browser
- HF Model repo + Model Card — only if there is a model-like artifact, such as weights, adapter weights, tokenizer/config files, or a reusable ML component
- HF Storage Bucket — large mutable files, logs, checkpoints, intermediate artifacts, not the main explanation page
So for this case, my default route would be:
- GitHub first
- Add CITATION.cff, license, examples, and release notes
- Archive a release with Zenodo or another DOI path
- Optionally add an HF Dataset repo for reproducibility files
- Optionally add an HF Space if there is a small runnable demo
- Use an HF Model repo only if the work becomes something model-like or loadable in an ML workflow
Optional extra notes below, only in case they help.
More detailed map
| What you have | Best fit | Why |
|---|---|---|
| Old Fortran code, Python/JAX/PyTorch ports, source files, docs, examples | GitHub repo | Best place for code, README, issues, releases, license, citation files, and versioned development |
| A runnable browser demo | Hugging Face Space | Best place if people should try the method interactively |
| Model weights, adapter weights, tokenizer/config files, or a reusable ML component | Hugging Face Model repo + Model Card | Best fit when there is something model-like that users can load or reuse |
| Sample inputs/outputs, reproduced tables, benchmark files, toy matrices, archival data, reproducibility files | Hugging Face Dataset repo + Dataset Card | Better fit when the artifact is mainly examples, outputs, data, or reproducibility material |
| Large mutable artifacts, logs, checkpoints, temporary/intermediate files | Hugging Face Storage Bucket | Better fit for non-versioned object storage, not for the main public explanation |
| Something people should cite | Zenodo DOI or Hugging Face DOI | Better for stable citation and archival reference |
Useful links:
Why I would separate the homes
A useful distinction is reader expectation.
A Model repo makes many readers expect something model-like:
- weights
- adapter weights
- tokenizer/config files
- inference code
- a reusable layer/module/regularizer
- something that can be loaded or used in a model workflow
A Dataset repo makes readers expect material such as:
- sample inputs
- sample outputs
- reproduced tables
- evaluation files
- benchmark data
- toy matrices
- reference results
- archival/reproducibility files
A Space makes readers expect something runnable in the browser.
A Bucket makes readers expect storage, not documentation.
A GitHub repo makes readers expect source code, docs, issues, releases, and development history.
So I would not think of this as “one correct Hugging Face page”. I would split the project by artifact type:
- code and docs → GitHub
- citable release → Zenodo / DOI
- reproducibility files → HF Dataset repo
- interactive demo → HF Space
- model-like component → HF Model repo
- large mutable objects → HF Bucket
Possible GitHub layout
One possible minimal layout:
c-inf-soft-sparsity-engine/
├── README.md
├── LICENSE
├── CITATION.cff
├── docs/
│ ├── math.md
│ ├── historical-notes.md
│ └── references.bib
├── src/
│ ├── fortran/
│ └── python/
├── examples/
│ ├── toy-factor-analysis/
│ └── sample-inputs-outputs/
└── notebooks/
└── demo.ipynb
The most useful top-level files would probably be:
README.md— what this is, what problem it addresses, how to run itLICENSE— code licenseCITATION.cff— how to cite itdocs/math.md— mathematical explanationdocs/historical-notes.md— historical context and original use casesrc/fortran/— original Fortran codesrc/python/— optional modern portexamples/— tiny reproducible examplesnotebooks/— optional interactive walkthroughs
Possible README sections
For this kind of historical/research-code release, these sections would make the project much easier to understand:
# C∞ Soft Sparsity / Simple-Structure Engine
## What this is
Short description of the method and its historical context.
## What this is not
Clarify whether this is not a pretrained model, not a modern pruning library yet, not a production-ready package, etc.
## Historical context
When and why the method was developed, what problem it originally targeted, and how it relates to factor analysis, simple structure, or oblique rotation.
## Mathematical summary
Definitions, objective functions, smoothness claims, metric/inverse-metric notes, and assumptions.
## Code
Where the original Fortran code lives, how it is organized, and whether it has been modified.
## Minimal example
How to run one small example and what output to expect.
## Reproducibility
Input files, expected outputs, reference results, and known limitations.
## Modern ML notes
Careful notes about possible connections to differentiable sparsity, pruning, regularization, or metric-based optimization, without overclaiming.
## Citation
How to cite the code, archive, paper, or DOI.
## License
Code license and documentation/data license.
## References
Original papers and related work.
The “What this is / What this is not” section may be especially useful, because it prevents readers from expecting model weights or an immediately usable deep-learning package.
Possible one-line notes to prevent confusion
If the Hugging Face repo is not a model checkpoint:
This repository is not a pretrained model checkpoint.
It is an archival/reproducibility package for historical maths, Fortran code, and examples related to a differentiable sparsity/simple-structure criterion.
If it later becomes a reusable ML component:
This repository does not contain a pretrained model checkpoint.
It provides a reusable differentiable sparsity component / regularizer inspired by historical factor-analysis rotation criteria.
If it is mainly sample data and reference outputs:
This dataset repository contains sample inputs, reference outputs, and reproducibility files for the accompanying code release.
If it is mainly a Space:
This Space is a small interactive demo. The main code and archival notes are maintained in the linked GitHub repository.
Possible low-friction roadmap
A simple publishing path could be:
- Put the original Fortran and explanatory notes on GitHub.
- Add
LICENSE,README.md, andCITATION.cff. - Create one tiny reproducible example.
- Archive a release with Zenodo or another DOI path.
- If there are sample files/results, mirror those as an HF Dataset repo.
- If there is a simple visual demo, make an HF Space.
- If someone later ports the method into a reusable PyTorch/JAX component, then consider an HF Model repo or package-style release.
That keeps each artifact in the place where readers are most likely to understand it.
Interesting contribution. Making the math, original paper, and code easy to reproduce will be the key. A few modern examples showing how it connects to today’s sparsity and optimization methods would help the community evaluate and build on it.
Thanks. The Fortran code (subroutines) for inducing sparsity with infinitely differentiable loss functions (not kludges for L0 or L1) and using a metric and its inverse to endogenously prevent basis collapse (no hyperparameters) would probably qualify as a model. Several AIs indicated that it may be, among other things, representational learning engine. The maths definitely has applications to ML and AI.
The code is standard Fortran subroutines, updated from 1973, that compile perfectly using gfortran on any modern Linux. There is also a wrapper than makes it easy to call directly from gnu Octave. I had several AIs go over the code and math, and they all indicate that it is extremely relevant for modern ML and AI. I posted the code on Zenodo and GitHub, and will be posting the math there too. By the way, the Hugging Chat did the best job analyzing the maths and code of all the AIs tried (Claude, Bing, Gemini): it did an impressive job.
One AI suggested it should be posted as a Model Card. It also connected the math to modern sparsity, so I should probably post the AI chat, prompts and all. The Octave wrapper makes it easy to run on test datasets.
Ah, I see. In that case, I think a Model repo is fine.
More generally, my impression is that if the files are AI/ML-related, putting them somewhere on the Hub is usually reasonable. The difference between repo types is mostly about convenience and tooling, not strict correctness.
For example, a Dataset repo may give you dataset-related features, a Space is better for a demo, and a Bucket may be better for fast / temporary / mutable storage.
For this case, a Model repo sounds reasonable if you want to present it as an ML-facing computational artifact.
The main thing I would suggest is making the README.md clear. The YAML block at the top can handle repo metadata / categorization, and after that it is just normal Markdown explanation. If the README explains what the repo contains and how to use it, users will have a much easier time understanding and reusing it.
Of course, many useful Hub repos have minimal README files too, so this is not a hard requirement. It would just be helpful for this kind of historical / mathematical code.
Good idea. I will post the code, and the octave wrapper, as well as a small dataset. I will give compilation instructions (very easy using gfortran) and a gnu Octave example of using the software. This should make it clear how the software can be tested on the user’s data.