@Absinthe My solution. This should be a somewhat space-optimized solution in ruby based off the modified concept of a Trie.
https://git.qoto.org/snippets/4
If i made this into a Radix Trie by compressing nodes with single children down I could reduce this further.
But since it does work I thought I'd share it as is. I'll update everyone if i decide to finish optimizing this particular solution.
It does however do a fairly decent job at compressing the tree by making sure no subtree is a duplicate of any other part of the tree (a node of any specific length/id will be the only node with that length.
For clarity I attached a picture from my notes of what the Trie would look like for the encoded string "12345" where the value inside each circle/node is the "length" value of that node, and the value attached to an arrow/vector/edge is the "chunk" associated with that link. The end result is any path from the minimum node (0) to the maximum node (5). This diagram does not include incomplete paths which my program does right now.
Incomplete paths can also be trimmed to further reduce the space. But since incomplete paths each add only a single leaf node to the tree, and might be useful for various use cases I decided to keep it.
lol not efficient if **all** you need is the count, but it does work of course.
@billstclair @Absinthe Time-complexity has nothing to do with raw-speed. If you do the brute force solution and actually list all solutions with a copy approach (the absolute simplest least efficient way) then your dealing with exponential space complexity. Good luck computing large datasets on even the beefiest of machines where a linear solution would attack it with ease.
@billstclair @freemo how does that solve it? Am I missing something?
@billstclair
I don't know about that word "instantly" there but cool solution ;)
@Absinthe
@billstclair @Absinthe @freemo
This solution gives wrong answers in certain cases. E.g. "10" should return one solution, the letter "j', but instead it gives zero. I'm suspicious of the inequalities on line 95 (strictly greater than zero AND strictly less than twenty-six permits the integers 1-25, which looks like a fencepost error given a 26-character alphabet).
Good catch, elm isnt one of the languages i mess with so i didnt run it myself and only got a vague idea of what is going on.
@Absinthe BTW i intentionally chose to list them not count them. I could probably optimize further if I counted only. In fact that would be trivial, so i think ill solve that too.