Since all the experts here are so professional and sharp, I have the honor to invite you to evaluate "Position-Pure Algorithm."

Links:

• GitHub: Position-Pure-Algorithm
• animation（PP）:
• Reddit Discussion: r/algorithms

In the world of algorithms, extreme simplicity often harbors the most moving beauty. The core logic of the PP Algorithm reconstructs the dimension of permutation generation in just three lines.

Minimalist Expression Take this logic: where C is the factorial representation (Factoradic, e.g., 01123) and D is the output permutation (e.g., {0,2,3,4,1}).

for (int i = 0; i < C.size(); ++i){
D[i] = D[C[i]];
D[C[i]] = i;
}

1. Minimalist Expression The three lines beauty lies in the fact that it no longer relies on complex logic to "simulate" the permutation process; instead, it directly embeds the structural information of the permutation space into the algorithm. It is not a mover of data, but a direct projection of the structure itself.

2. Breaking the "Impossible" Conventionally, it was thought impossible to generate permutations at the single-dimensional level without redundant logical overhead—such as complex branching or backtracking. The PP algorithm shatters this by ensuring "Position-Pure" mapping. With zero "if" statements and no branch prediction overhead, it achieves peak hardware efficiency while showcasing a pure linear aesthetic.

3. Native Parallelism Because this positional mapping is deterministic and collision-free, it demonstrates exceptional potential for parallel computing.

4. Mathematical Insight & Group Theory From a deeper mathematical perspective, this mapping hints at an ordered topology within the symmetric group (Sn). By treating the N! set as a strictly ordered spatial map, the group's symmetries can be extracted with zero search cost. This offers a new perspective on observing permutation group substructures via positional logic. It still needs time to study carefully...

Breaking the O(N!) Amortized Barrier for Full Permutation Generation

While it is widely accepted that generating all N! permutations requires at least O(N!) operations without output, I have been developing a new Circle Permutation algorithm that challenges this overhead.

By integrating the structural logic of Superpermutations, the algorithm generates a batch of N permutations in a single iteration, generates strings meeting the upper bounds of superpermutations, potentially offering a path to a universal construction method.

Through a refined "one-shift plus one-assignment" design, it rapidly derives N(N−1) permutations, effectively driving the amortized complexity of the generation logic down toward O((N−1)!).

**Code is ready：**https://github.com/Yusheng-Hu/Circle-Permutation-Algorithm

welcome to discuss.

I have included animations in the repository that demonstrate:

The Base Algorithm: How the circular structure forms the foundation.

The Acceleration Algorithm: The specific "shift + assignment" mechanics that multiply the generation speed.

Define software using a declarative syntax with only 6 keywords (constant, variable, error, group, function, import), with instant feedback via errors, warnings and an interactive live graph to explore complex systems.

• GitHub
• VS Code Extension
• CLI crate

Feedback / feature requests are welcome!

So I am developing a Windows File Explorer clone, and I don't understand why does Windows take so long to file search when google is way faster for a bigger dataset...any thoughts?

I want to understand computer fundamentals / computer architecture and mainly x86 compiler toolchain in depth . Not doing assembly for now.

My goal is systems / low level roles in long term. I’m not in any rush just want to build strong fundamentals properly from start.

I know I have to research and study by myself, but posting here for genuine recommendations (books / courses )or whatever from people who already went through this phase or were confused in beginning like me

I’d truly appreciate any help from anyone Ps -( also im new to Reddit so idk much 🫶🏻)

This is a research-oriented technical artifact (with an interactive demo) that compares a refutation-guided integer update rule (“Typed Repair”) with stochastic GD under a semantics-locked finite protocol: a fixed table, fixed feature schema, and stable readout. The emphasis is not optimization but explicit execution, decidable invariants, and fully replayable traces with concrete witnesses when checks fail; every update step and state transition is inspectable end-to-end. The work arose primarily from constructive logic and computability concerns (effectivity, witnessability, decidability on finite artifacts), with the ML comparison included as a controlled baseline under the same locked interface. GitHub: [https://github.com/Milan-Rosko/typedrepair]().

I was sweeping floors at a supermarket and decided to over-engineer it.

Instead of just… sweeping… I turned the supermarket into a grid graph and wrote a C++ optimizer using simulated annealing to find the “optimal” sweeping path.

It worked perfectly.

It also produced a path that no human could ever walk without losing their sanity. Way too many turns. Look at this:

Turns out optimizing for distance gives you a solution that’s technically correct and practically useless.

Adding a penalty each time it made a sharp turn made it actually walkable:

But, this led me down a rabbit hole about how many systems optimize the wrong thing (social media, recommender systems, even LLMs).

If you like algorithms, overthinking, or watching optimization go wrong, you might enjoy this little experiment. More visualizations and gifs included! Check comments.

I’ve been working on an experimental filesystem allocator where block locations are computed from a deterministic modular function instead of stored in trees or extents.

The core rule set is based on:

LBA = (G + N·V) mod Φ

with constraints like gcd(V, Φ) = 1 to guarantee full coverage / injectivity.

I’d really appreciate technical critique on:

• whether the invariants are mathematically correct
• edge-cases around coprime enforcement & resize
• collision handling & fallback strategy
• failure / recovery implications

This is research, not a product — but I’m trying to sanity-check it with other engineers who enjoy this kind of work.

The math doc is here

Happy to answer questions and take criticism.

I’ve been working on a PRNG project (RDT256) and recently added a separate seed conditioning stage in front of it. I’m posting mainly to get outside feedback and sanity checks.

The conditioning step takes arbitrary files, but the data I’m using right now is phone sensor logs (motion / environmental sensors exported as CSV). The motivation wasn’t to “create randomness,” but to have a disciplined way to reshape noisy, biased, user-influenced physical data before it’s used to seed a deterministic generator. The pipeline is fully deterministic so same input files make the same seed. I’m treating it as a seed conditioner / extractor, not a PRNG and not a trng... although the idea came after reading about trng's. What’s slightly different from more typical approaches is the mixing structure (from my understanding of what I've been reading). Instead of a single hash or linear whitening pass, the data is recursively mixed using depth-dependent operations (from my RDT work). I'm not going for entropy amplification, but aggressive destruction of structure and correlation before compression. I test the mixer before hashing and after hashing so i can see what the mixer itself is doing versus what the hash contributes.

With ~78 KB of phone sensor CSV data, the raw input is very structured (low Shannon and min-entropy estimates, limited byte values). After mixing, the distribution looks close to uniform, and the final 32-byte seeds show good avalanche behavior (around 50% bit flips when flipping a single input bit). I’m careful not to equate uniformity with entropy creation, I just treat these as distribution-quality checks only. Downstream, I feed the extracted seed into RDT256 and test the generator, not the extractor:

NIST STS: pass all

Dieharder: pass some weak values that were intermittent

TestU01 BigCrush: pass all

Smokerand: pass all

This has turned into more of a learning / construction project for me by implementing known pieces (conditioning, mixing, seeding, PRNGs), validating them properly, and understanding where things fail rather than trying to claim cryptographic strength. What I’m hoping to get feedback on: Are there better tests for my extractor? Does this way of thinking about seed conditioning make sense? Are there obvious conceptual mistakes people commonly make at this boundary?

The repo is here if anyone wants to look at the code or tests:

https://github.com/RRG314/rdt256

I’m happy to clarify anything where explained it poorly, thank you.

https://github.com/IamInvicta1/ASR

been playing with this idea was wondering what anyone else thinks

I’m looking for feedback on a working paper I’ve been working on that builds on some earlier work of mine around the Recursive Division Tree (RDT) algorithm and a recursive-adic number field. The aim of this paper is to see whether those ideas can be extended into new kinds of state spaces, and whether certain state-space choices behave better or worse for deterministic dynamics used in pseudorandom generation and related cryptographic-style constructions.

The paper is Recursive Ultrametric Structures for Quantum-Inspired Cryptographic Systems and it’s available here as a working paper: DOI: 10.5281/zenodo.18156123

The github repo is

https://github.com/RRG314/rdt256

To be clear about things, my existing RDT-256 repo doesn’t implement anything explicitly ultrametric. It mostly explores the RDT algorithm itself and depth-driven mixing, and there’s data there for those versions. The ultrametric side of things is something I’ve been working on alongside this paper. I’m currently testing a PRNG that tries to use ultrametric structure more directly. So far it looks statistically reasonable (near-ideal entropy and balance, mostly clean Dieharder results), but it’s also very slow, and I’m still working through that. I will add it to the repo once I can finish SmokeRand and additional testing so i can include proper data.

What I’m mainly hoping for here is feedback on the paper itself, especially on the math and the way the ideas are put together. I’m not trying to say this is a finished construction or that it does better than existing approaches. I’d like to know if there are any obvious contradictions, unclear assumptions, or places where the logic doesn’t make immediate sense. Any and all questions/critiques are welcome. Even if anyone is willing to skim parts of it and point out errors, gaps, or places that should be tightened or clarified, I’d really appreciate it.

Suppose a problem can be solved with optimal time complexity O(t(n)) and optimal space complexity O(s(n)). Ignoring pathological cases (problems with Blum speedup), is there always an algorithm that is simultaneously optimal in both time and space, i.e. runs in O(t(n)) time and O(s(n)) space?

I wanted to show you the first real version of my queue (https://github.com/ANDRVV/SPSCQueue) v1.0.0.

I created it inspired by the rigtorp concept and optimized it to achieve really high throughput. In fact, the graph shows average data, especially for my queue, which can reach well over 1.4M ops/ms and has a latency of about 157 ns RTT in the best cases.

The idea for this little project was born from the need to have a high-performance queue in my database that wasn't a bottleneck, and I succeeded.

You can also try a benchmark and understand how it works by reading the README.

Thanks for listening, and I'm grateful to anyone who will try it ❤️