I recently looked at the “Black Jack” exercise in the x86-64 Assembly track. I like it quite a bit. So, let me share with you some minor problems I found.
In the description of the first problem, “joker” should read “jack”.
In the unit tests of the third exercise, the one labeld as test_value_of_ace_a_q passes an ace and a queen to the value_of_ace function. Because the hand in question is a blackjack, it is impossible for the player to receive a third card in my very limited knowledge. If it is the case, the particular test should be removed. Also, it is probably a good idea to explicitly mention the assumption that the given initial hand is not a blackjack.
The title of the fourth problem is a little confusing. Shouldn’t it be something like “Determine if the hand is a (Natural) Blackjack?”
It may be interesting to include in the unit tests for can_split_pair a test with C10 and a face card such as CK, which can be split (a kind of a edge case, as C10 is not a face card).
This exercise was forked from the Python track, but it looks like the docs diverged. It may be worth syncing changes.
My understand that having a winning hand doesn’t require you play it. It would be silly not to play a winning hand, but you can still receive another card.
This exercise was forked from the Python track and most of the instructions come from there. The changes I’ve made were basically using some constants to keep track of cards (I think in Python they use strings, not sure) and defining constants for TRUE and FALSE, since there are no booleans in assembly.
This is indeed wrong.
In Python they use “J” instead of “jack”. My idea originally was to define constants “two”, “jack” etc. I’ve decided to use “C2”, “CJ” etc., because it is more concise, but I forgot to update the instructions for the tasks to reflect this change, and there is also this typo you’ve found.
Can you please make a PR to change card references from their literal names to their constants? For example, CA for ace and CJ for jack.
My understanding is the same as Isaac’s. I’ve copied this test from the Python track (just inverting (Q, A) to be (A, Q)). So I don’t think this needs to change.
Although I agree with you that someone who knows the rules might find this test odd, since we are only defining “blackjack” in the next task, we would be anticipating things by testing it here. So I think this is best left unchanged.
This was copied from the Python track, but I think your wording is clearer. Can you please add it to the PR?
I’m a bit wary of adding new cases considering that black-jack is a concept exercise and tests don’t need to be thorough. But this here seems fine. Can you please add it to the PR?
You should add the test case to the generator in ./generators/exercises/black_jack.py and then run ./generators/generate black-jack -i -t concept to keep them in sync.
If you are not able to make a PR, it’s fine. Just let me know.
I did a bit more research. Especially, Learn to Play Blackjack was very informative. One thing I leanred is that the value of an ace is not a player’s choice. It is automatically determined to maximize the hand’s value under the constraint that the hand’s value cannot exceed 21 (this is consistent with the problem description of the exercise).
Also, It seems that in most prevailing games with the same name (if not all), the dealer ends the game as soon as a player gets a blackjack hand and pays out to each player. So, there is no opportunity to request another card in such case.
Of course, it’s a game. You can modify it in any way. If you allow a blackjack hand to request another card, however, the player is guaranteed to go bust. I am wondering how you could determine the value of the next ace.
I have been going over the instructions for making the changes you requested. Then I found two sentences that are a little inconsistent with each other. The first sentence in the description of the first problem says,
In Blackjack, it is up to each individual player if a CA is worth 1 or 11 points (more on that later).
while the second sentence in the description of the third problem says,
Players try to get as close as possible to a score of 21, without going over 21 (going “bust” ).
The latter sentence actually asserts that the value of CA is determined by the hand, not by the player (because the player has no choice). I think that we could rewrite both sentences slightly for clarity. For example:
In Blackjack, the value of a CA can be 1 or 11, depending on the hand.
and
The value of CAs are chosen for maximizing the score of the hand but without going over 21 (going “bust”).
@oxe-b I have finished revising the instructions of the exercise and created a PR for the revision. I made some extra changes for clarity and consistency. Please feel free to reject any of them in case it went too far.
I will try to work on addition of a test to the unit tests.
I have just submitted a PR for adding a test of the can_split_pair function with inputs C10 and CK and return value true. Please let me know if you find any problems in it.