# C-inf soft sparsity engine maths and code from 1972 **URL:** \ **Category:** Show and Tell\ **Created:** [June 18, 2026, 6:29pm UTC](https://discuss.huggingface.co/t/c-inf-soft-sparsity-engine-maths-and-code-from-1972/176964 "2026-06-18T18:29:27Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![drkatzmaths](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@drkatzmaths](https://discuss.huggingface.co/u/drkatzmaths)\ **Post date:** [June 18, 2026, 6:29pm UTC](https://discuss.huggingface.co/t/c-inf-soft-sparsity-engine-maths-and-code-from-1972/176964/1 "2026-06-18T18:29:27Z")
**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.** ---
**Author:** ![drkatzmaths](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@drkatzmaths](https://discuss.huggingface.co/u/drkatzmaths)\ **Post date:** [June 19, 2026, 8:17pm UTC](https://discuss.huggingface.co/t/c-inf-soft-sparsity-engine-maths-and-code-from-1972/176964/2 "2026-06-19T20:17:47Z")
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? ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [June 20, 2026, 1:23am UTC](https://discuss.huggingface.co/t/c-inf-soft-sparsity-engine-maths-and-code-from-1972/176964/3 "2026-06-20T01:23:02Z")
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: 1. **GitHub first** 2. Add **CITATION.cff** , license, examples, and release notes 3. Archive a release with **Zenodo** or another DOI path 4. Optionally add an **HF Dataset repo** for reproducibility files 5. Optionally add an **HF Space** if there is a small runnable demo 6. 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: > > - [Hugging Face Model Cards](https://huggingface.co/docs/hub/model-cards) > - [Hugging Face Dataset Cards](https://huggingface.co/docs/hub/datasets-cards) > - [Hugging Face Spaces](https://huggingface.co/docs/hub/spaces) > - [Hugging Face Storage Buckets](https://huggingface.co/docs/hub/storage-buckets) > - [Hugging Face DOI docs](https://huggingface.co/docs/hub/doi) > - [GitHub: About CITATION files](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files) > - [Zenodo: CITATION.cff file](https://help.zenodo.org/docs/github/describe-software/citation-file/) > **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: > > ```plaintext > 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 it > - `LICENSE` — code license > - `CITATION.cff` — how to cite it > - `docs/math.md` — mathematical explanation > - `docs/historical-notes.md` — historical context and original use case > - `src/fortran/` — original Fortran code > - `src/python/` — optional modern port > - `examples/` — tiny reproducible examples > - `notebooks/` — optional interactive walkthroughs > **Possible README sections** > > For this kind of historical/research-code release, these sections would make the project much easier to understand: > > ```markdown > # 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: > > ```plaintext > 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: > > ```plaintext > 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: > > ```plaintext > This dataset repository contains sample inputs, reference outputs, and reproducibility files for the accompanying code release. > > ``` > > If it is mainly a Space: > > ```plaintext > 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: > > 1. Put the original Fortran and explanatory notes on GitHub. > 2. Add `LICENSE`, `README.md`, and `CITATION.cff`. > 3. Create one tiny reproducible example. > 4. Archive a release with Zenodo or another DOI path. > 5. If there are sample files/results, mirror those as an HF Dataset repo. > 6. If there is a simple visual demo, make an HF Space. > 7. 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. ---
**Author:** ![masonreed11](https://avatars.discourse-cdn.com/v4/letter/m/ccd318/32.png) [@masonreed11](https://discuss.huggingface.co/u/masonreed11)\ **Post date:** [June 20, 2026, 4:34am UTC](https://discuss.huggingface.co/t/c-inf-soft-sparsity-engine-maths-and-code-from-1972/176964/4 "2026-06-20T04:34:04Z")
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. ---
**Author:** ![drkatzmaths](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@drkatzmaths](https://discuss.huggingface.co/u/drkatzmaths)\ **Post date:** [June 20, 2026, 5:24pm UTC](https://discuss.huggingface.co/t/c-inf-soft-sparsity-engine-maths-and-code-from-1972/176964/5 "2026-06-20T17:24:04Z")
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. ---
**Author:** ![drkatzmaths](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@drkatzmaths](https://discuss.huggingface.co/u/drkatzmaths)\ **Post date:** [June 20, 2026, 5:29pm UTC](https://discuss.huggingface.co/t/c-inf-soft-sparsity-engine-maths-and-code-from-1972/176964/6 "2026-06-20T17:29:15Z")
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. ---
**Author:** ![drkatzmaths](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@drkatzmaths](https://discuss.huggingface.co/u/drkatzmaths)\ **Post date:** [June 20, 2026, 5:34pm UTC](https://discuss.huggingface.co/t/c-inf-soft-sparsity-engine-maths-and-code-from-1972/176964/7 "2026-06-20T17:34:35Z")
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. ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [June 21, 2026, 1:15am UTC](https://discuss.huggingface.co/t/c-inf-soft-sparsity-engine-maths-and-code-from-1972/176964/8 "2026-06-21T01:15:20Z")
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. ---
**Author:** ![drkatzmaths](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@drkatzmaths](https://discuss.huggingface.co/u/drkatzmaths)\ **Post date:** [June 21, 2026, 7:45pm UTC](https://discuss.huggingface.co/t/c-inf-soft-sparsity-engine-maths-and-code-from-1972/176964/9 "2026-06-21T19:45:46Z")
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.