I'd like to report a bug/suggest a feature/say "hi". How do I reach the author of Elise?
Send e-mail to . Please include the text "[ELISE]" in the subject line of your e-mail, so I can filter it out from the spam.
How strong a player is Elise?
The short answer is "very, very strong".
Elise's "quick move" in Scrabble® play is stronger than all but a small number of human tournament players. (It'll give them a run for their money, too.) Elise's simulation (at least 3 ply) will win against even them a solid majority of the time.
When comparing against other computer engines, there is the question of hardware and performance to consider. At 3 ply simulation over hundreds of games using the TWL06 list, Elise 0.0.1 wins just over 60% of Scrabble® games against Quackle 0.97's Championship Player. On my Elise development machine (a several years old Dell Optiplex 755 4 × 2.4 GHz with 2 GB RAM), Elise is also slightly faster than Quackle at this setting, using from 10-20% less time in most games to make its moves. Some cases, like close late game positions with blanks unseen, are noticeably slower however.
On a similar machine with only one or two cores, Elise at these settings might be slower. On newer, faster multi-processor machines, though, Elise could be substantially stronger per minute of "think time" than this. Elise's simulation is stronger the deeper you look -- Elise can quite feasibly simulate to the end of the game on every move if that's what you want to do -- and as Elise's simulation is parallelized, any improvement in hardware strengthens Elise much more than it strengthens a single-threaded engine.
To summarize: on most reasonably fast multi-core machines, Elise will be as strong or stronger than other current computer engines at most time controls, and can do accurate deep-ply analyses faster (or much faster) than other engines can. On older and especially single-core machines Elise may or may not be stronger than other existing engines.
Can I use custom word lists with Elise?
Yes, you can. To add new word lists, simply place your word list (as a plain ASCII text file, with one word per line -- case does not matter) in your Elise install path. Make sure your word list has the .LST file extension. Then the next time you start Elise, your list will appear in the lexicon select drop-down.
Be aware that, without some language-specific information in the game definitions, Elise will only support word lists containing letters of the Latin alphabet, A to Z, without accents or other diacritical marks. If your word list is in a language that uses other letters, it may still be possible to analyse games with Elise -- see the next question.
Also note that without calculated rack leave data for your word list, Elise may not play as strongly with the custom word list as it would otherwise. If your word list is in a language Elise knows about, Elise will use the closest existing rack data it has.
Can Elise be adapted for crossword games in my language?
Elise, as of version 0.1.8, can play or analyze games in English, Spanish, German, Danish, French, Catalan, Swedish, and Italian. Other languages may be supported in future versions. If you would like Elise to work in your language, please send me mail at the e-mail address above. I will need a good word list in order to create rack statistics, board simulation, and tile guess data for your language.
Is there a version of Elise for *nix/Mac systems?
The main Elise engine is written in portable C++ (just a single source file, in fact), although the GUI is all Windows code. A console application compatible with *nix systems could be readily built from the engine source; a fancy pants GUI using XWindows or similar is doable with a little more effort.
Elise does run under WINE (at some cost to performance, of course.)
If you are interested in writing a port of Elise, please let me know!
Why isn't Elise's end-game search greedy, in the usual sense?
Given Elise's design, it isn't the objective. In practical terms, the best endgame move, especially in a lost position, is not the greedy move (the one that minimizes the losing margin, assuming perfect play by the opponent). In a lost position, a move that leads the opponent to a state with one winning move and a hundred losing moves is a lot better than a move that leads the opponent to a state with thirty winning moves. The greedy play very often leads to a painless endgame for the opponent in a lost state.
Elise is interested primarily in winning the game, not in maximizing its score, and when Elise knows the game is lost to perfect play, it admits the possibility of imperfect play and attempts to capitalize on that. If an endgame line is tricky it prefers to play it and force its opponent to prove it can win the game. It does not always succeed in finding a complicating move -- if it is far behind in a lost game, or it doesn't see a difficult endgame emerging, it will throw in the towel -- but if it can make things difficult, it will. It may turn out to play the greedy move anyway, but it often will not.
Against strong computer players, highly unlikely to miss a winning endgame move, the greedy move could always be considered best. In that case, strictly greedy play would be nice as an option (it is not currently in version 0.0.1). It is not, however, a high priority given Elise's "win, always!" philosophy. I'm actually more inclined to have Elise deliberately play phoneys in this case than to play a conventional greedy endgame.
Elise uses a pretty good chunk of RAM, over 500 MB. Why is that?
Elise is designed primarily to be fast and strong. It is also designed to be general-purpose, allowing analysis of various different crossword games. It makes RAM requirement tradeoffs for additional performance and strength when appropriate, and some of the features that allow Elise to be used as a general crossword puzzle or anagram tool also require additional RAM. For example, the lexicon is stored internally several different ways in different data structures, each best-suited for a specific task or a specific game state. There is a separate algorithm for move generation in games with more than 7 tiles, for move generation with racks containing blanks, for hook or pattern-match searches, etc. Elise caches results that can be re-used in move generation. Additionally, Elise keeps a variety of rack and board statistics (mostly pre-calculated) in memory to improve the strength of its move evaluator.
Not all performance or strength improvements carry a big RAM cost -- generally you want RAM usage low to improve memory locality, so many of the important data structures in Elise are designed to be compact. However, the memory-hungry features in Elise are more than worth their RAM cost in terms of performance.
Can you use Elise in games like solitaire Scrabble®? How about 3-player or 4-player games?
Yes, in fact Elise is strong in solitaire games -- set the simulation ply to a high number (or give it sufficient time on its clock) and watch it set up crazy moves for itself. The late game play is especially impressive, as it will make excellent spots for the most difficult remaining tiles and play moves out over several turns to acheive a higher score. At 5 ply or higher, without exchanges, Elise almost always reaches 1,000 points in a solitaire game of standard Scrabble®, and often scores considerably higher.
Elise plays well in three and four player games, though generally its strength at a given number of simulation ply will be weaker than the corresponding ply simulation in one or two player games. Elise does not have exhaustive end game search in these games, either (it's on the list of features for future versions, though.)
In simulation, Elise causes my CPU usage to go to 100%. How do I get Elise to use less CPU resources?
By default, Elise will kick off one simulation thread for every CPU core on your machine. Each simulation thread will run on a different core. Since every core is busy with simulation, this will push your CPU usage up towards 100%.
If you want Elise to use less CPU resources, lower the number of threads in the simulation dialog. For example, if you have a quadcore machine, running 3 threads in simulation will keep 1 CPU free for other tasks, 2 threads will keep 2 CPUs free, etc. Keep in mind the simulation will take longer to finish as Elise has less computing power to work with.
(Technically, the decision to run each thread on a different CPU is left to the operating system, not to Elise, but in most cases, unless there is an application given higher-than-normal priority by Windows, Elise will get each thread running on a separate CPU.)
Wow, why do I suddenly have over 100 candidate moves in simulation?
One possibility is that it's late in the game and there are only a few tiles left in the bag. When that happens, Elise becomes very careful about endgame timing (when it will allow the bag to empty.) It will often look at "little moves" that play one or two tiles, among other additional moves it deems sufficiently interesting in terms of possible end-game impact (for example, moves that play or block the play of a high-value tile.) There are usually dozens of such moves. Elise's late-game play is sharpened substantially by its ability to simulate all of these additional moves.
Another possibility is that Elise is far behind in score and has increased the pool of candidate moves, in hopes of finding an unusually powerful play among the weeds.
Why is this win-probability simulation taking seemingly forever?
If you are in a game state where you have very close to 0% or very close to 100% probability of winning, win probability simulation may take a long time to converge to the optimal move. This is simply because almost all moves, in such a state, are basically equivalent in terms of win probability: if the game is truly won or lost, the choice of move doesn't matter and Elise will be hard-pressed to find a difference between any moves. If, instead, it turns out one move has a 99.992% win probability, and another has a 99.994% win probability, since the difference is so slight, it would take many tens of thousands of simulations for Elise to be able to distinguish the better play.
The solution is to do as "clock move" does and use point spread simulation in such a situation. Alternately, you can terminate the win probability simulation using the ESC key after you think it's run long enough.
How does Elise determine which moves to simulate?
Elise will always simulate the moves that its "best fast" evaluator thinks are the best -- usually there are thirty to sixty of these moves. In addition to these, in some important game states, Elise may consider additional moves for simulation. For example, in the late game Elise may look at moves that play few tiles, or that block its opponent from playing a tile, or, if Elise is falling behind, it may look at moves that open the board up. There have been game situations where Elise simulates two hundred or more different moves.
I sometimes see different results when I run simulation multiple times on the same game situation. Why is that?
Normally, Elise's fast simulation will converge on the best move (maximal spread or win probability) for the given lookahead depth. However there are circumstances where Elise's fast simulation may by chance converge on a slightly suboptimal move.
In particular, Elise's fast simulation is most unstable on the first move: the variance in possible outcomes is much higher than even the second move of the game. Also, on the first move, for any reasonable candidate move there are usually two or three similar moves that are about as valuable -- even though Elise, when playing on a symmetrical board, only considers the "across" moves and not the rotated "down" moves. Without doing tens of thousands of simulations, these moves may be impossible to distinguish from each other.
Due to the underlying randomness involved in tile draw, it's impossible to create a perfectly stable algorithm based on simulation. Late-game simulation and deep simulation beyond the first move, though, are normally very stable. Most frequently, when Elise's fast simulation converges on different moves on repeated runs, the moves are so close in value to be practically identical.
Elise does have a few tricks to reduce the impact of potential unstable states, and to help ensure that when a game state lends itself to unstable simulation, that it is able to ferret out a best move-equivalent anyway. (For example, Elise considers the median of game outcomes as well as the arithmetic mean in simulation, and is careful to ensure that simulation uses a representative distribution for opponent racks. Though this is not normally exposed to the user, you can see more information about the simulation calculations by right-clicking on a simulation move.)
Note that simulation only attempts to find the best move. It does not try to establish which move is second-best, third-best, etc. Once Elise is positive that a move is not the best move, it stops simulating that move (unless, in simulating other moves, something happens that makes it appear more attractive.) Therefore, on repeated simulation runs you may see the order of sub-optimal moves change.
Ultimately, this "imperfectly stable" behavior is part of Elise's design. Stability in all game states is not the primary goal of Elise's fast simulation; its primary goal is to converge on the optimal move (or something practically equivalent) quickly in as many game states as possible. In a timed mixed game, play strength can actually be improved by having a fast move evaluation algorithm with slight instabilities rather than a slower, more stable algorithm.
Why does simulation in a game of Clabbers take eons?
Elise has a lot more possiblilities to consider in Clabbers -- both for its moves and its opponents' responses -- and many of the alternate tile placements for a move in Clabbers are basically identical in terms of value. Improving simulation so it actually converges at better than a glacial pace in Clabbers games is on the "to do" list. In the meantime, you can console yourself with the fact that Elise's "quick move" in Clabbers is quite strong.
Elise has a "fast lookahead", is there a slow lookahead too?
Yes and no. It exists, but more as a debugging tool than anything else. It is not built in the release version of the program.