C22 Phoenix -- Beenish Ali

[beenishali693]

No description provided.

[anselrognlie]

Looks good overall! Please review my comments, and let me know if you have any questions.

[anselrognlie]

Missing semicolon

      });

[anselrognlie]

👀 Avoid running code in global scope.

[anselrognlie]

This calculation is an improvement over your Python version (which didn't reflect the weights in how the letters get picked). However, notice that weightedRandomLetter does not adjust to the lower likelihood of picking a particular letter once it has been picked. In the extreme, once all the available copies of a letter have been picked, there should be a 0% chance of picking it going forward. This is not the same thing as excluding the letter if it gets picked again. Rather, its chance of it being picked would need to be distributed throughout the remaining tiles to match the expected behavior of picking tiles from a pile.

This (albeit minor, but still real) discrepency, along with the fact that we still do need to allocate additional memory to ensure that we don't use more copied of a letter than should be available, point towards an approach that truly builds the pile of tiles (a list with as many copies of a letter as there should be tiles) as the method that will most closely provide the probabilities we want, and does so in a predictable number of iterations.

Alternatively, we could decrement the weights of a tiles as they are picked, but this still would require iterating through the letters for each letter, resulting in O(m * n) where m is the size of the hand and n is the number of letters. By contrast, there is a pool-based approach that would be only O(m + n). Of course, for the size of the inputs, these aren't major considerations, but they're still worth considering.

[anselrognlie]

Rather than tracking a separate variable i which we must update independently, we could make this condition dependent on the actual result we're building.

  while (drawnLetters.length < HAND_SIZE) {

Nit: Leave a space between the while and its condition, and between the end of the condition and the block brace.

[anselrognlie]

While unlikely, we could end up picking the same letter over and over, to the point that this loop never completes. We would prefer an approach that will predictably pick a letter every iteration.

[anselrognlie]

Great job incorporating named constants instead of using magic numbers. This is much more self-documenting.

[anselrognlie]

Restructure this to avoid the empty block. Empty blocks are not a typical pattern we'll see in JS.

  if (possibleWinners.length !== 1) {
    winner = tieBreaker(possibleWinners);
  }

[anselrognlie]

JS Maps do preserve the insertion order of keys. In practice, we don't see Maps used that often unless the keys need to be something that isn't a string. Since Maps require the use of the set and get methods, they're a frequent source of bugs (since developers prefer to use []).

[anselrognlie]

Nice helper to get a collection of all the highest score words.

I might restructure into separate steps that

1. builds a Map of all the words to their scores (removing the need to run scoreWord multiple times for the same word)
2. Finds the max score
3. builds a filtered list of the words that have the max score

We could return this as a two value list, the list of words tied, and the score they have. Something like

  [tiedWordList, highestScore]

Elsewhere, I'd break any tie in the filtered word list, which doesn't depend on the score. Then we don't need to build the final return value until the very end of the function.

[anselrognlie]

Breaking the ties depends only on the words themselves. Consider restructuring this to receive only a list os words (no score info) and leaving it to the caller to build the necessary retrun value.