Very nice !

Adding compression should not slow it down much.
Anyway, how do you store the data ? Just a large table ?

Hello cyanophycean !

In TI-Translate, I stored the data in huge strings IN the TI Nspire document. (indeed I couldn't paste all into ONE string because the length of a string on the TI Nspire is limited ! So I had to split my list into small pieces ! (516 words per string if I remember, or 516*84 characters)) That was rather complicated and I had to make a kind of a script to automate "copy/paste"s from notepad to the student software.. %)
Why such a weird and difficult solution ?
Because my strings contained a lot of accentuated characters and the TI Nspire scripting tool made shit.. (just closed the Student Software every time I pasted the code !)
(I also tried with Luna, and the generated file produces an error too..)

About memory problems : my biggest version (english/french) contains 58 959 words from english to french AND 56 252 words from french to english. Moreover, the storage isn't really optimized... Actually each word takes exactly 84 characters and the remaining place is filled with blanks.
An extract :

a b c {m} [abécédaire]         primer {n} [ABC]                                     a latere [REL‚ loc adj]        a latere [adj phr]                                   a latere [REL‚ loc adv]        a latere [adv phr]                                   a priori [loc adj]             a priori [adj]                                       a priori [loc adv]             a priori [adv], guess; at a ~ [adv phr]              a priori {m inv}               apriorism {n}, preconception {n}                     A {m} [alphabet latin]         A {n} [Roman alphabet]                               A {n} [ÉLEC‚ ampère]           amp {n} [ELEC‚ an ampere]                            abaissement {m}                abatement {n}, decay {n}, lowering {n}               abaisser [v tr]                lower [v tr‚ make lower]                             abaisser [v tr‚ raccourcir]    cut up [v tr]                                        abaisser [v tr‚ réduire]       bring down [vt‚ lower a price]                       abaisser; s'~ [v pr]           off; to get ~, demean; to ~ oneself                  abaisser; s'~ vivement [v pr]  duck down [v intr]                                   abaisser; s'~ à faire          stoop; to ~ to doing                                

This was the original format of the data from Freelang dictionnaries. On the other side, this format was convenient to navigate through the list because you just have to make 84 characters steps to get the next word !

So, here is how it works for my TI translate ! ^^

In term of number of characters, it represents for both lists 9 677 724 characters !

So if you want to solve your problem, maybe you could do as I did, but I don't think that's the best solution. Moreover you don't need here the assets of this solution, as I did. (storing in a string to ease the string research, supporting accentuation,...)

So I think that the easier solution is to reduce the amount of word !

PS : have you tried to split your table into smallest ones ? (maybe it's the length of a table wich is limited..)

Anyway, good luck !

EDIT :
Your program must search words in your list actually ? How do you do that with your table ? You scan the whole table to see if it contains the word ?

wow, this is a great game maybe you could just use semicolons ( to split words, and the look for the matching ; so split them up, that would be the most easy way i think..

is it correct if i saw that you don't get extra points if you make a word you already formed, or did i just look bad?

how do you make the grid? because you say 'randomly generate ouzzles', does that mean you now just make them by hand and type them in?

i meant that semicolon thing for your encoding of the library.

if you do for example lib = "can;pie;cake;board;door" etc you can easely split them up to find the words, and you don't need that endlessly long table to store your entries..

If the plan is to have large dictionaries, this might be useful.  

function editDictionary(dictionary, old_dict)
local data = old_dict or {}
for _, word in ipairs(dictionary) do
local curchar = data
for i = 1, #word do
local char = word:sub(i, i)
if not curchar[char] then
curchar[char] = {endof = i == #word and true or nil}
elseif not curchar[char].endof then
curchar[char].endof = i == #word and true or nil
end
curchar = curchar[char]
end
end
data.lookup = function(tbl, str)
local function lookup(str)
local curchar = data
for i = 1, #str do
curchar = curchar[str:sub(i, i)]
end
return curchar.endof
end
err, ret = pcall(lookup, str)
return err and ret or nil
end
return data
end

It takes a table like
list={"carbon","cars","car","cat","cats"}

and creates a table like
dictionary = {
c={
a={
r={
b={
o={
n={endof = true}
}
}
s={endof = true}
endof = true
}
t = {
s={endof = true}
endof = true
}
}
}
lookup = function(tbl, str)
--blah blah blah
end
}



lookup takes a string and rapidly returns a true or nil value based on if the word is in the list of acceptable words.

Here's an example:
dict = {"cat", "cats", "dog", "mouse"}

dictionary = editDictionary(dict)

print("d:", dictionary:lookup("d"))
print("do:", dictionary:lookup("do"))
print("dog:", dictionary:lookup("dog"))
print("dogs:", dictionary:lookup("dogs"))
print("dogz:", dictionary:lookup("dogz"))

amendment = {"dogs"}
dictionary = editDictionary(amendment, dictionary)
print("\nAmendment: dogs added!\n")

print("d:", dictionary:lookup("d"))
print("do:", dictionary:lookup("do"))
print("dog:", dictionary:lookup("dog"))
print("dogs:", dictionary:lookup("dogs"))
print("dogz:", dictionary:lookup("dogz"))

prints

d: nil
do: nil
dog: true
dogs: nil
dogz: nil

Amendment: dogs added!

d: nil
do: nil
dog: true
dogs: true
dogz: nil

What I like about this way is that it narrows the search down for each letter in the string instead of searching for the whole string in a giant table or string. It could be potentially bulky, though.

Worst case scenario, it could end up indexing something like dictionary.p.n.e.u.m.o.n.o.u.l.t.r.a.m.i.c.r.o.s.c.o.p.i.c.s.i.l.i.c.o.v.o.l.c.a.n.o.c.o.n.i.o.s.i.s.endof but most of that searching would be handled by Lua itself.

This is case sensitive, but if it makes a difference it would only take a simple metatable to fix.


EDIT: Reread the first post and testing a few things first

I tested this way on the student software and it took about 3 seconds to load my list of ~100,000 words and convert it to the table. From there it was able to index any word very quickly (including long words like symptomatologically). The overall memory is a tad bulky (but there's only so much you can shrink 100,000 words). Each key, however, only points to a table containing, at most, 27 new keys.

A warning: don't paste tables like this into programs bulky IDEs with syntax highlighting. I pasted a table into the student software, walked away for an hour, came back and it was still trying to highlight everything. I eventually gave up and used the old scripting tools to test out the method.

I'll attach the code I tried with.

EDIT: I just realized that there are two lists in this program. There is still a table with all 100,000 words in it. I haven't sent this code to my calculator, so I'm not 100% sure that there won't be any memory issues.

EDIT2: I just realized, if one wanted definitions included with this structure, the values of the endofs (or _s) would just need to be changed from true to the definition. This wouldn't really apply to Boggle, but it could be used elsewhere.

EDIT3: loadstring is intended to be more for accepting code from the user. oclua is a good example of this. Tables and strings should be able to handle this problem without loadstring.