Non-ZipChord Theory With Stats ("Composite Sub-Anagram theory"?)

[Danc2050]

PREFACE
This is probably out of scope for ZipChord, As you have discussed already, ZipChorder has a specific purpose. I am not declaring or suggesting that ZipChord should function in this way, I am merely posting here as it may provoke some thought as my last suggestion did where you took it in a really cool direction.

QUESTION
Can we mash keys on the keyboard, in some formulaic way, and receive the whole word without manually creating chords that lose similarity to the original word?

THEORY
I propose that if one splits a word into groups in a formulaic way (e.g., Greek and Latin Roots) and add in character entry to make up the lack of the grouping (e.g., no roots), then alphabetize/sort the input (chord or character entry (note: result is just itself, so just concatenate)), a more unique "code" of the word appears, which can map to the whole word, outputting what the user wants.

Note: If we merely alphabetized each word, then we would have many anagrams, which would not work. But since we are alphabetizing the chords as they are entered and character entry (again, just itself) and concatenating them, we get something more unique.

ALGORITHM
0) Find a list of words

1. Use a system for breaking up chords, add character entry where system lacks ability to complete the words (My repeated example persists: ["aer", "o", "space"] is one example of using the Greek and Latin Roots + character entry for the word aerospace).
2. Alphabetize the roots + character entries (e.g. ["aer", "o", "space"] becomes ["aer", "o", "aceps"]).
3. Combine the word and add this word to a dictionary that a program looks for (e.g., "aeroaceps" is the (nonsensical) word) and have the value be the word (e.g., aerospace).
4. In a program, we may keep an input buffer that is added to as a user chords + character entries. Each (chorded) entry is alphabetized, which ensures that whatever "mashing" that goes on is mapped to one unique output. The buffer is cleared on a "space", but before it is cleared, we look in our map to see if the generated (nonsensical) string (e.g., aeroaceps in this case) maps to anything in our dictionary.
5. If a match occurs, we delete the line the user typed and replace it with the value in that dictionary (e.g., aerospace). If a match is not found, no replacement occurs and we clear the buffer, ready for the next input to match on.

TESTING
As a part of an ongoing project (horrible code! It probably does no good to anyone to link here, but I am trying to be transparent...see [4] in sources), I first took a list of Greek and Latin Roots from Wikipedia to formulate the chords (see source [1] below).

Then, I took a list of ~1,000 words and ran my Algorithm (minus the program) to generate chords + character entries and the resultant string for the program to look for in the output buffer.

Finally, I took a really large list of words -- 846,863 -- and did the same thing.

RESULTS

• I discovered that there were no collisions among the ~1,000 words.
• I discovered that there were very few collisions among the 846,863. It should be noted that there were very uncommon words (e.g., blitheness) that could have conflicted with other (also uncommon) words that would not affect a user really. The ~percentage of collisions was ~0.65% (~5.5k out of 846,863).

This means, to me anyways, that someone could chord in "roots" and use character entry to make up the difference. There is a caveat (see [2] in Future Intrigue section).

LIMITATIONS
[1] I can't just chord "are" because I could mean "ear". EDIT: I mistakenly said aer was a root of ear, not true. But if one chorded aer and then pressed space, they may produce ear if it was a chord, which was my point...But not related to roots right now. END EDIT. It would also be a conflict. I think for shorter words this system does not work well. Perhaps a workaround would be to restrict this system to chording larger words... but in no way would I think I could get rid of all collisions.
[2] Practically chording this way remains to be seen if it is easy to do. As someone pointed out, it may be nice for people in the medical fields (due to Greek and Latin being heavily used in that space), but the average user may find it difficult to parse the word rather than type the word one at a time or chord a shorter code (i.e., chording) for the word.

FUTURE INTRIGUE

1. Right now my system chooses the largest root to break apart a word. One may want to limit the root size <=4 instead of 5 (e.g., space). Though user preference plays a role here...
2. Because my system chooses the largest root, a user may think of a root that works, and yet it wouldn't be mapped in this imaginary program. It seems to defeat the purpose if a user has to remember just one way of chording in roots rather than just have a knowledge of roots and be able to chord + character entry...I could try to put all the possible root combinations in a word and map it to the dictionary and see how many collisions I would get to see if this detracts from this current method.
3. My system does not truncate the suffixes when developing chords. Interesting results may show up if I did that (as ZipChord can add suffixes really well, which would probably shrink the length of chords used).

SOURCES
[1] Latin and Greek Roots
[2] English Dictionary from Wikipedia - note: I preprocessed this to only include non-hyphenated, non-spaced, and unique words (dataset is not a set).
[3] CharaChorder word set
[4] Ongoing Kotlin Program

[psoukie]

I was dealing with a family health emergency this weekend when I saw this posted so I did not reply. I will come back to read this later this week when I can give it proper attention.

[Danc2050]

No worries, I would not expect a response even if you just wanted to think on it...and I know you have a lot of stuff going on (dayjob, this project, life). I hope everything is okay with you and your family! 🙏

[psoukie]

I appreciate the thought! My son has been in an ICU but he's getting better. Programming is, in a way, a good distraction because it takes a lot of focus.

[Danc2050]

(For anyone, I know psoukie is very busy, so no need to read or respond to this).
I did a variation on my idea, not using roots, but just a program that would sense mashed keys in a sequence of a whole word (no keys elided -- e.g., if about mash may be oba + ut) and know what word was meant to be typed (e.g., about).

I

• took the list of words from the CharaChorder Builder (BETA) spreadsheet (see: https://docs.google.com/spreadsheets/d/1ZiVmLQewM9AFnHXMyyWmq5UpMn3w8RCFe9kPOmYsC4Y/edit#gid=1482914223).
• Created a methodology for finding unique strings by using combinations of compound chords. Methodology is:
  • split word into chunks of minChordLength <= chunkSize >= maxChordLength. So if maxChordLength was 4 (most don't type more than 4 at a time), for a word like the it would be split into ['the'] for chunkSize of 3 (as the max of the chord length can't be achieved on a small word like the) and then for chunkSize=2, the result would be ['th', 'e'].
  • use the permutation of each letter grouping (e.g., above for size 2 becomes [['th', 'ht'], ['e']]) and combine each index with the following index to give a (fairly) unique output (e.g., ['the', 'hte']
• Found out how many duplicate strings this would produce
  • the answer for minChordLength=2 and maxChordLength=4 is 226 duplicate strings for words: [three, recent, thing, centre, names, earth, rated].

The idea behind this was having a program that would, after a space, look up what I typed in a dictionary and then output the word I intended. So if I chorded ht and typed e on the keyboard (hte), then hit the spacebar, my dictionary would know that I meant the and produce that word.

A lazy way of chording; little more closer "type in words" (more like "type in pieces of a word") instead of the "type by letter" concept. Anyways, next step if I will pursue further would be tweaking V1 of this software (less code to read) or implement it myself in AHK to replace the word typed after it registers a space. Pretty neat IMO that I could get that level of efficiency for 1105 words - 7 and just know that some of the words (['three, recent...]) would not work out. I am sure as I added words more conflicts would occur. Just a fun (for me at least) experiment I thought I'd share.