However, I got to thinking about that lyric a bit, and me being me I also merged those thoughts with a couple of other thoughts I’ve had. See, I enjoy foreign languages even though I would never claim to be fluent in anything other than English (and sometimes, not even that!). Most recently I’ve been brushing up on my Latin and Koine Greek. One of the things that finally “clicked” in my head about languages is how you need to think conceptually instead of trying to map phrases one-to-one. That’s not to say I didn’t know that already, but rather that it finally fully set in my mind that meaning transcends individual words.

In fact, when I recently read through Gödel, Escher, Bach by Douglas Hofstadter, he made a comment about how originally people thought we could make great progress toward mechanical interpretations of texts using computers. Then, as we tried to do that and failed spectacularly, it became obvious that interpretation is more than just a substitution of words.

Just for fun, and to demonstrate my point, I ran the above paragraph through Google’s translate feature, translating it from English to Latin and then back to English again and it gave me this:

For when he recently read through Gödel, Escher, Bach by Douglas Hofstadter made to the mechanical devices of the people who first how we could make great progress of computers and using the interpretation of the texts. Then, as he could and the efforts of is to do spectacularly, so be it is a clear correlation of interpretation of speeches.

Not only is that mostly gibberish on par with the emails I get from those generous Nigerian princes, but if I try to piece together the meaning from the words presented it seems to me that it actually reverses my original meaning in the last sentence!

Now, some people are very strict with how they define and interpret words. Word X means concepts A, B, or C, period. If I were to make an analogy, I’d imagine these people as viewing the meaning of words similar to islands in the ocean. There is the water of chaos that swirls around, but when you get to the word itself, the definition stands strong and immobile. It is fixed, no matter what the ocean does.

However, I have become more and more convinced, over time, that words are more like clouds in the sky. That is, they are still distinct units, but their edges are a bit fuzzier and a little malleable. Note that I do not maintain that postmodern concepts of deconstructionism are sound, or that words have no actual meaning at all—anymore than I would say that a cloud has no shape or that a cloud could also be a fox. Rather, it’s just that the definitions of words are “fuzzy” at times, as opposed to fixed islands of meaning.

Thus, I realize more and more that translation is at the conceptual level rather than the word level. Some of the most difficult aspects of learning a foreign language is beginning to think like the native speaker. Take just the simple example of word order. In English, word order is critical; but in Latin, it is not important at all. However, Latin does still have some preference for word order, such as having the verb come at the end of the sentence (English is typically subject-verb-object; Latin tends to subject-object-verb).

To give an example of that in English, examine: “Susan goes to the bank.” Here, “Susan” is the subject, “goes” is the verb, and “the bank” is the object (here, a prepositional phrase). Latin word order would typically render it as “Susan, to the bank, goes.” That makes sense in English, but it is awkward. If every sentence was written that way, it would make English difficult to comprehend.

Since the structure of sentences helps to convey the meaning of the sentences in some languages (such as English), and falls into patterns of use in other languages, you can actually look at the structure of languages to see what information cultures think are most relevant. In English, we want to know first who or what is doing the action of the sentence, then we want to know what they are doing, and finally we want to know what they are doing that action to. In Latin, they wanted to know who or what was doing the action, then they wanted to know who or what the action was being done to, and only then did they want to know what action was being done.

Now, of course, this happens very quickly in speech. Nevertheless, there is a preference for the order of information, and adjusting how information comes can cause some amount of mental stress when one is learning a foreign language.

So what does this have to do with Breaking Benjamin then and the line “only the strongest will survive” that I talked about clear at the beginning of this piece? I’m glad you asked! Consider these two sentences side-by-side:

Only the strongest will survive.
Only the strongest will survives.

There is only one letter different between the two sentences, yet that one letter also determines whether or not the word “will” is a noun or a verb. And the best part? The letter that makes the determination is the absolute last letter in the sentence, and it’s not even part of the word that is changed! In the first sentence, “will survive” is the verb, but in the second, “strongest will” is the noun.

Now the question that I find interesting is this. If you were given those two sentences at different times in a conversation, at what point do you know whether “will” is a noun or a verb? Granted, you would typically have a lot more context than just one of those two sentences. Example: “You have to have a strong will to make it in the world. Weak-willed people just cannot cut it. Only the strongest will survives.” Here, the surrounding context would most likely make you think “will” is a noun the instant it comes up.

Nevertheless, I would wager that if I started an essay with “Only the strongest will survives” and another one with “Only the strongest will survive”, you would read both of those essays and automatically adjust the meaning in your mind, most likely without even noticing you’d done so. Indeed, I suspect that your brain provisionally holds a definition for the word “will” when it first encounters it, and then later on when it gains the rest of the knowledge needed, it “settles” on the grammatically correct interpretation. All without you consciously wondering whether “will” is a noun or verb.

Ultimately, the word “will” as used above must be a fuzzy word as it is being used. Your brain has to hold two potential meanings at the same time, and those meanings are in two different categories of words (noun and verb).

This brings to mind the dictionary argument too. When we are asked, “What does such-and-so word mean?” we go the dictionary. But dictionaries do not create meaning, rather they tell us how words are already being used. And the danger someone can fall into is thinking that the primary definition of a word is how the word must be used in every instance. (This is especially dangerous for first year Greek students who find Strongs’ Concordance.)

I thought of an illustration of the “dictionary fallacy.” Suppose someone pulls up an English text—let’s use Stephen King’s The Stand since it’s got significant length. This person randomly searches through the book and selects, again at random, one letter from one word. This person says, “I will give you $1,000,000 if you guess what letter was randomly selected.” In order to have the best shot at gaining the million dollars, what letter should you select?

By far, the most common letter in English is the letter “e.” Hands down, your choice should be “e.” But what are the odds that you would win the million dollars? According to a study done at Cornell, you would have only a 12.02% chance of winning the million dollars. That means that even though the letter “e” is most frequent, if you pick “e” you will be wrong nearly 88% of the time.

The same thing most certainly happens with definitions too, especially with words like “will.” For instance, look at the use of the word will here: “I will, of my own free will, that the will will be executed by Will.” Indeed, this reminds me of the famous grammatically-correct sentence involving the word “buffalo”: Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo (you can click the link to read the article about how it works out).

Translation, therefore, isn’t simply a substitution of the most commonly used definitions. Words have their meaning by use, and people use words very loosely. In the end, while it may serve to set analytical minds at ease if words were islands in the sea, conventionally words will always remain clouds in the sky.

Today it was 29.

That’s enough for me to declare “correlation”!

Speaking of correlation, along a similar thread, it’s been a couple of months since school started, and I have to ride by one on the way in to work. And my conclusion, having been past it nearly every school morning for two months, is that people who drop their kids off at school couldn’t drive to save their life. Like, there’s a 2-way stop sign there that magically becomes a 4-way stop because people just decide to not drive through it and block traffic, and then everyone else stops–even though there is clearly no stop sign at the intersection.

But this brings a dilemma too. What do I correlate that to? Is it that parents dropping off kids are poor drivers, or is it more general, since roughly 80% of the drivers there are female. So maybe it’s women make poor drivers. But then, I have to acknowledge that every single person I’ve seen there has been white, so maybe white people just make poor drivers. Finally, there was an over-representation of SUVs and minivans, so the correlation clearly is that drivers of said vehicles are poor drivers.

Clearly, all of these things are correlated. And therefore, Global Warming is true. Proof of Global Warming is found in the fact that it was 29 degrees this morning when yesterday it was 36. Clearly such a wild swing in temperatures can only be caused by massive global climate shifts….

To help combat this, I wrote a short script that will search for the appropriate line and display a message box quoting it. Obviously, it could potentially be improved a bit, but for a Q&D (i.e., “Quick and Dirty”) approach, this serves me well:

' line finder

Const ForReading = 1

strFileName = InputBox("File name: ")
LineNum = Inputbox("Line number: ")
LineNum = cInt(LineNum)

set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile(strFileName, ForReading)

i = 0

Do until objFile.AtEndOfStream
	i = i + 1
	LineText = objFile.ReadLine
	if i = LineNum then
		KeepText = LineText
	end if
Loop

Wscript.Echo KeepText

So have fun coding. :-)

Except it comes to mind that really Darwinism only works in computer theory, when you can boil everything down to one or two essential factors and create an arms race out of it. In biological systems, there are more factors involved (something that Darwinists continually forget) meaning that an increase in one aspect does not necessarily translate into an increase in fitness across the board.

But with computer programs and spam bots, the theory works just fine.

 n = rnd

wscript.echo(n)

When I ran this script, it popped up 0.7055475 for the value. That’s good, because there’s “no way” you could have predicted that in advance! So obviously, this is true randomness, right?

Well, what happens if I run it a second time? I get the value 0.7055475.

I run it a third time and, you guessed it, the value is 0.7055475.

This explains why I put “no way” in quotes above, because in reality you can predict what it’ll be. That sort of defeats the whole purpose of adding randomness into your computer program! It would be nice if we could somehow make it where we’ll get a different number each time we run the script.

And VBScript has a way of doing that. It’s the Randomize keyword. Simply add that to the top of your script like this:

 Randomize

n = rnd

wscript.echo(n)

What happens when I run it this time? I get 0.4127008. I run it a second time and I get 0.2001459.

The reason this occurs is because random numbers on computer programs are never truly random at all. Instead, the computer has an algorithm it goes through to make pseudo-random results, but the algorithm is determined by a starting “seed” number. This seed number is the same each time you run it, normally.

But what happens when we add the Randomize keyword? It changes it so that the seed number that’s used is based on the system time instead. Since time is represented by a number, and the system time goes to tiny fractions of seconds, then putting that in as the seed virtually guarantees that running the script multiple times will have a different seed in the algorithm each time through. And the algorithm is specifically designed so that seeds of close numbers can still yield wildly different results.

It must be made clear that these results given are not truly random. They are pseudo-random, however, in that despite the fact that they are deterministically generated by seed values, it is virtually impossible for any human to be able to determine beforehand what the results will be, and therefore this process mimics randomness for all intents and purposes. For that reason, I will use the word “random” or “randomly” throughout this post, despite the fact that I should really use the word “pseudo-random” or “pseudo-randomly” instead.

So now we have a way to pick a random number between 0 and 1. But how does that help us when we’re trying to choose random numbers between 1 and 11? Or between 3 and 7? (Both are requirements for the game 21.)

To solve this, we’re going to have to do a little math, but we’re also going to have to understand how VBScript converts numbers with decimals to integers. This is because we need the final answer to be in integer format, but the rnd function returns a decimal number. To convert to an integer in VBScript, you use the int() function, where you put the number you’re going to convert to an integer in the parentheses.

The first thing to know is that VBScript converts decimals to integers by just chopping off everything at the decimal point. The key point to understand is that VBScript does not round! That is, converting 1.1, 1.5, and 1.9 to integers in VBScript will yield answers of 1, 1, and 1:

n1 = 1.1
n2 = 1.5
n3 = 1.9

n1 = int(n1)
n2 = int(n2)
n3 = int(n3)

wscript.echo(n1 & ", " & n2 & ", " & n3)

Before we look at the more complex problems in 21, let’s look at a simpler version. If we want to pick a number between 1 and 10, then we know that we have to get the number on the left-hand side of the decimal to become a number between 1 and 10, because the int() function will chop off the rest. So how do we do that?

Well, let’s look at what happens if we multiply a decimal number. Suppose we start with 0.91. Multiply it by 10, and we get 9.1. Find int(9.1) and we get 9.

So this is very good. If we want to find a number between 0 and 9, we can multiply the fraction by 10. But, if you notice, we want to find a value between 1 and 10, not 0 and 9. How do we do that? Simple! We can just add 1 to the end result. 0.91 becomes 9.1; int(9.1) = 9. And finally 9 + 1 = 10. Consider the other end. 0.00 becomes 0.0; int (0.0) = 0. And finally 0 + 1 = 1. So this will find numbers between 1 and 10, just like we wanted!

But what happens when we’re looking for numbers between 1 and 11, like in the first problem in 21? Well, we can just multiply by 11 instead. 0.91 x 11 = 10.01, for instance. Adding 1 to the end result will bring us back to 11. Similarly, 0.00 x 11 = 0, and adding 1 will bring us to 1. So it works out.

This shows us the basic gist of what goes on, and we may think we know the key already. Just multiply the random number by the maximum value possible, then add the minimum value possible. But this is actually only accurate when we’re finding a value between 1 and some maximum value. Suppose we were looking for a value between 0 and 10. If we multiply by the maximum value possible—10—then add the minimum value possible—0—we will never be able to have a result that is 10. If, on the other hand, we add 1 to the end result, we’ll never be able to have 0 as a result. Instead, what we need to do is multiply by one more than the maximum number in order to make this work for the range between 0 and 10.

Now we’ve got a bit of a problem, because one function works when 1 is the lowest number (i.e., MaximumNumber x RandomNumber, then add MinimumNumber) but when 0 is the lowest number we have to use a completely different one ((MaximumNumber + 1) x RandomNumber, then add MinimumNumber). And we haven’t even gotten to consider what happens when we’re trying to find a number between 3 and 7.

Thankfully, if we find a way to merge the two functions above into one, we’ll actually have found the rule for all of them. When we merge them, we get this:

(MaximumNumber – MinimumNumber + 1) x RandomNumber + MinimumNumber

To see how this works, when the MinimumNumber = 0, then the first part is MaximumNumber + 1. When MinimumNumber = 1, then the first part is just MaximumNumber (because 1 – 1 = 0). So we see these two functions do combine into the one.

And now consider when we try to find a number between 3 and 7. Plug that in and we get:

(7 – 3 + 1) x RandomNumber + 3.

Or, 5 x RandomNumber + 3.

Obviously, if the RandomNumber is 0.0, then 5 x 0 = 0, and we add 3 to that. This means the lowest possible number is, indeed, 3. And if the Random number is 0.9, then 5 x 0.9 = 4.5. Add 3 to that, and it’s 7.5; int(7.5) = 7. So the highest number we can get is, indeed, 7. This likewise works out, and that’s the format we use in 21 to yield our random numbers.

21 is a game which relies on user input as well as automated, behind-the-scenes processes. When we look at the structure of 21, as seen in part 1, we see that this input is required in two areas: 1) in deciding whether to pick a card (and if so, which one) or to hold; 2) in deciding whether to exit the game or play another round. Both instances can be controlled by use of a menu-driven input box. In other words, a menu is presented with numbered options that the user can select for by inputting the desired number.

It is relatively easy to make an input box in VBScript that allows information to be gleaned from the user. The command uses the keyword InputBox. I won’t go over all the attributes of InputBox here, but the bare bones version is some variable = InputBox(the message you want to display on the input box). This assigns the value that the user types into the box to whatever variable you choose.

Let’s give a quick demonstration. Open Notepad and type in the following:

Name = InputBox("What is your name?")

wscript.echo(Name)

Save the file as something that ends with the .vbs extension (say, “Inputbox.vbs”), then run your script. When you run it, a box will pop up asking you for your name. Type in anything, and whatever you type in will be displayed back to you in another message box (the second box is created by the wscript.echo command).

This shows both the strength and weakness of InputBox. It’s strength is that the data can be of any type. This is made possible because VBScript is not strongly typed, but instead makes its best “guess” as to what type of data is entered while it’s processing the script. Most of the time, this is fine. But when it comes to a menu-driven interface, that can be problematic because the menu interface requires the data input by the user to be integers.

Let’s see how this is a problem. Open your Notepad again and change the code to the following:

Number = InputBox("Type a number:")

IF (Number < 10) THEN
     wscript.echo ("The number you typed in is less than 10")
ELSE
     wscript.echo ("The number you typed in is greater than or equal to 10")
END IF

Run this script now and type in a number. For example, if you type in 110 it will output “The number you typed in is greater than or equal to 10.” Type in 1 and it will output “The number you typed in is less than 10.” So it’s working like it’s supposed to, right?

Well, try this. Instead of typing a number, type in the letter “a” and hit enter. What happens? You get an error (“Type mismatch: ‘Number’”) and the program crashes. The last thing that we want is to crash a program. This is especially true with scripting programs, because when it crashes there’s no way to recover from where you were. You have to start the program all over again.

All good programmers need to be able to anticipate user errors and write code that will make it as close to error-proof as possible. As a result, we need to check if the data that is typed into the program is an integer or not, and if it is not we should display an error message and allow the user to try again. Thankfully, VBScript has a command that allows us to check if the data is a number, and it’s helpfully called IsNumeric. Here’s how to use it.

Number = InputBox("Type a number:")

IF IsNumeric(Number) THEN

     IF (Number < 10) THEN
          wscript.echo ("The number you typed in is less than 10")
     ELSE
          wscript.echo ("The number you typed in is greater than or equal to 10")
     END IF
ELSE
     wscript.echo ("You did not type in a number")
END IF

Now if you type in a letter, you get a helpful “You did not type in a number” instead of a program crash. However, it would still be nice if we could prompt the user to try again, rather than just exiting the program. To that end, we can put the entire thing in a DO…LOOP WHILE loop.

In order to do it well, however, we need to alter the InputBox command a little by replacing the literal statement (i.e., that which is in quotes) with a variable. That way, we don’t have to try to fit a lot of text into the command, and furthermore we can add an error message and things of that nature to it too. So, here we go:

strMessage = "Type a number:"
strError = "" 

Valid = FALSE

DO
     Number = InputBox(strError & vbCrLf & strMessage)

     Valid = IsNumeric(Number)

     IF Valid THEN

          IF (Number < 10) THEN
               wscript.echo ("The number you typed in is less than 10")
          ELSE
               wscript.echo ("The number you typed in is greater than or equal to 10")
          END IF
     ELSE
          strError = "WARNING: You must type in a number!"
     END IF

LOOP WHILE Valid = FALSE

So here we set up a Boolean variable called Valid. Valid can be either TRUE or FALSE, and we default it to FALSE. However, Valid then takes on the value from the test of IsNumeric(Number), which means if it’s a number Valid becomes TRUE, but if it’s not a number Valid becomes FALSE. As long as Valid is FALSE, the loop repeats.

Now there’s one last bit to this, which I did not address in my quick version of 21 which I linked to earlier, and that’s the case of what happens when you hit the Cancel button on the InputBox. If you run the above script and, instead of entering a value, you click Cancel you get a box that pops up saying: “The number you typed in is less than 10”. But, of course, you didn’t type in any number at all!

What happens is that VBScript will interpret a variable that has no value as a 0 if it’s used as a number, or as “” (which is a null string) if it’s used as a string. To verify that the Number has no value, use this code:

strMessage = "Type a number:"
strError = "" 

Valid = FALSE

DO
     Number = InputBox(strError & vbCrLf & strMessage)

     Valid = IsNumeric(Number)

     IF Valid THEN
          strMessage = "The value of the number you typed is " & Number & vbCrLf

          IF (Number < 10) THEN

               strMessage = strMessage & "The number you typed in is less than 10"

          ELSE
               strMessage = strMessage & "The number you typed in is greater than or equal to 10"
          END IF
          wscript.echo(strMessage)
     ELSE
          strError = "WARNING: You must type in a number!"
     END IF

LOOP WHILE Valid = FALSE

If you run this and hit Cancel you can see that no value is displayed for the number. Now, in the script version of 21, I actually exploited this feature because a 0 value meant to cancel out of the menu, so it worked to my benefit to have VBScript treat the null value as if it were a 0. But here it doesn’t work to our advantage. In this case, we can do a test using the VarType command to see if the Cancel button was pressed, and if it was we can terminate the script:

strMessage = "Type a number:"
strError = "" 

Valid = FALSE

DO
     Number = InputBox(strError & vbCrLf & strMessage)

     IF VarType(Number) = 0 THEN wscript.quit

     Valid = IsNumeric(Number)

     IF Valid THEN
          strMessage = "The value of the number you typed is " & Number & vbCrLf

          IF (Number < 10) THEN

               strMessage = strMessage & "The number you typed in is less than 10"

          ELSE
               strMessage = strMessage & "The number you typed in is greater than or  equal to 10"
          END IF
          wscript.echo(strMessage)
     ELSE
          strError = "WARNING: You must type in a number!"
     END IF

LOOP WHILE Valid = FALSE

This is the basic way I used InputBox to get data from the user in the 21 script.

I’ll go over the details of it in a future post.

So it’s a good thing I didn’t finish it, because now I can go over it a bit more organically here on the blog. In other words, you can see closer to “real time” how I flesh out concepts when I’m working on a program.

Overview

First of all, we need to know what the basic gist of the program is going to be. Obviously, 21 is a Blackjack lookalike—but that doesn’t tell us enough about it to start programming. We need to look at the rules.

The first rule is that there are two players: the user and the dealer. The dealer will be controlled by the computer code. The user is going to be the person who runs the program.

The object of the game is to get “cards” in your hand that get as close to 21, but not over. The user bets a small sum (say, $1 for the game) and begins. The user can always select to receive another card, as long as the current total in his hand is less than 21. (We can also let the user be an idiot and select a card if his hand value is equal to 21 too.) The user can also decide to “hold” at any point, and the value of the cards he holds will be his “score” for the round. If the user goes over 21, he “busts” and loses automatically, thus giving the dealer the $1 (this, incidentally, is part of what gives the dealer the edge in the game—he doesn’t have to play if the user busts first).

Assuming the user does not bust, the dealer then plays. The dealer must either meet or beat the score of the user’s hand, without going bust himself. If the dealer gets the same score as the user (that is, he “meets” the user’s score) then it is considered a tie, and the $1 is given back to the user. If the dealer beats the user’s hand, the dealer wins the $1. If the dealer busts, the user wins back both the $1 he bet and another $1 as reward for winning.

In 21, we will not use an actual deck of cards (i.e., having an Ace, 2 – 10, Jack, Queen, and King), but instead we will use a random number generator. To give the user a little more control of what goes on, we will give him the option of selecting from two different types of card. Card type 1 will be a card that will have a value between 3 and 7. Card type 2 will be a card that will have a value between 1 and 11 (this value is selected so that it is possible for a user to get 21 after only two draws, by drawing a 10 and an 11, or to even go bust after only two draws by drawing two 11s).

The game begins by drawing a “Pot” card from Card Type 2. The Pot card will be used by both the dealer and the user to begin their hand. Thereafter, each player will draw their own unique cards for their hand. In other words, suppose the Pot card at the beginning is 8. Both the user’s current score and the dealer’s current score is 8. But, the user will draw his own card (say, a 7) and his new total will be the sum of the Pot card and the user’s new card, in this case 15. Meanwhile the dealer’s is still 8. Supposing the player holds at 15, the dealer can then select to draw a card (say, a 10)—and his total will then be the Pot card plus the dealer’s new card, or in this case 18.

Program Structure

At this point, we can begin to think a bit about the structure of the program. I am going to select a menu-type interface (since we’re using VBScript), where the user will be able to select numbers to determine actions. We will therefore have the main program controlled by a DO … LOOP WHILE loop, which I will explain in detail as we get to it. Essentially, the program will loop until the while condition is satisfied, which we will define as being two conditions: 1) the user terminates the program; 2) the user has no more money.

Note: in order for us to implement (2) above, this will require us to keep track of the user’s bankroll. For instance, we can begin the game as a whole by having the user start with $10. At any point the user gets to $0, the game is over. Likewise, at any point the user wishes to exit the game, the game will end and his winnings will be displayed.

So the basic gist of the program will begin thus:

HEADER INFORMATION (i.e., where all the constants and variables
                          are created)

BEGIN MAIN PROGRAM LOOP:

     PLAY A ROUND OF THE GAME

     DETERMINE IF GAME OVER

END MAIN PROGRAM LOOP

DISPLAY END RESULTS

Now we need to better define what constitutes PLAY(ing) A ROUND OF THE GAME. So let’s look at the next level of structure:

SELECT A POT CARD

     ROUND IS PLAYED

RESULTS OF ROUND

Now let’s drill down into what happens when a ROUND IS PLAYED:

USER PLAYS

IF USER DOESN’T LOSE, DEALER PLAYS

Finally, we need to define both what USER PLAYS means and what DEALER PLAYS means. So first, USER PLAYS:

BEGIN USER TURN LOOP:

     PRESENT OPTIONS (user can draw type 1, type 2, or hold)

          IF USER SELECTS TO HOLD
               END USER TURN AS HOLD

          IF USER SELECTS TYPE 1
               DRAW TYPE 1 CARD
          IF USER SELECTS TYPE 2
               DRAW TYPE2 CARD

          ADD NEW CARD TO USER TOTAL

          IF USER BUSTS
               END USER TURN AS LOSS     

END USER TURN LOOP

This loop will terminate either if the user holds (i.e., END USER TURN AS HOLD) or busts (i.e., END USER TURN AS LOSS).

Now let’s examine the DEALER TURN. This only occurs IF USER DOESN’T LOSE:

BEGIN DEALER TURN LOOP:

     USE STATISTICS TO DECIDE WHICH TYPE OF CARD TO DRAW

     ADD NEW CARD TO DEALER TOTAL

     IF DEALER TOTAL > 21
          END DEALER TURN AS USER WIN

     IF DEALER TOTAL > USER TOTAL
          END DEALER TURN AS DEALER WIN

    IF DEALER TOTAL = USER TOTAL
          END DEALER TURN AS TIE

END DEALER TURN LOOP

Note that in the above, the loop will go until the dealer either busts, ties the user, or beats the user. Furthermore, if the dealer ties, right now we’re going to just make it a tie. In the future, we can add AI that will determine whether or not the dealer would like to draw again. (For instance, suppose that the user’s score is 14 and he holds. If the dealer reaches 14, he can still draw a card of type 1 (which is 3 – 7) and be guaranteed of a win—but for now, to keep it simple, we’ll just force the tie.)

So now let’s put the entire structure together:

21 PROGRAM STRUCTURE

HEADER INFORMATION

BEGIN MAIN PROGRAM LOOP:

     SELECT A POT CARD

          BEGIN USER TURN LOOP:

               PRESENT OPTIONS

               IF USER SELECTS TO HOLD
                    END USER TURN AS HOLD

               IF USER SELECTS TYPE 1
                    DRAW TYPE 1 CARD
               IF USER SELECTS TYPE 2
                    DRAW TYPE2 CARD

               ADD NEW CARD TO USER TOTAL

               IF USER BUSTS
                    END USER TURN AS LOSS     

          END USER TURN LOOP

          IF USER HASN’T LOST

               BEGIN DEALER TURN LOOP:

                    USE STATISTICS TO DECIDE WHICH TYPE OF CARD
                    TO DRAW

                    ADD NEW CARD TO DEALER TOTAL

                   IF DEALER TOTAL > 21
                        END DEALER TURN AS USER WIN

                   IF DEALER TOTAL > USER TOTAL
                        END DEALER TURN AS DEALER WIN

                   IF DEALER TOTAL = USER TOTAL
                        END DEALER TURN AS TIE

              END DEALER TURN LOOP

     RESULTS OF ROUND

     DETERMINE IF GAME OVER

END MAIN PROGRAM LOOP

DISPLAY END RESULTS

So that’s the basic structure. Next up, we’ll begin to actually code some of this :-)

Now, since this was on Facebook, I won’t put the name of one of the people who responded, but the question was asked in response: “Would this make God a deciever [sic] though?” I always find this question interesting, because it presumes that when God was creating the world, He must have considered all our future inferences about how to measure the age of the universe and then specifically set out to make up a false history in order to trick us in some manner. It never occurs to people who ask this question that maybe God didn’t concern Himself at all with our inferences but instead had completely different reasons for having the Earth “look” old.

I put “look” in quotes above precisely because the apparent age of an object has no bearing on its actual age. Consider the Tower of Terror ride at Disney California Adventure. It’s modeled after a 1930s look and is covered with fake cobwebs and dust to give the appearance that the hotel is old and decrepit, but it actually opened at DCA in 2004. Does anyone think that such a design qualifies as a deception on the part of Disney? No, for we recognize this as an aesthetic choice Disney made that’s intended to make a ride more enjoyable so that people will be more willing to part with their money to ride it.

Now, if human beings can make something with the appearance of age without it being deceptive, why then would we rule out the ability for God to do so?

In closing, I merely point out that I take no stance on the age of the universe at all. I believe time is meaningless without a temporal observer to experience it, so it’s really pointless to speak of any time before Adam was created in the first place.

There are three things you have to keep in mind. First of all, the hour format needs to be in the 12-hour clock mode. This means that when it’s 0 hours, we change the 0 into a 12, and then for every hour greater than 12, we subtract 12 from that (so 13 becomes 1).

The second thing is that if the hour is less than 12, it needs to be listed as AM, but if it is greater than or equal to 12, it needs to be listed as PM.

The third is that any minute or second that is less than 10 needs to be printed with a preceding 0. That is, you want the time to read 12:00:00, not 12:0:0.

To do all of these, we just need conditional statements, which we’ll do here using if … else commands. For the structure, I’ll capitalize the IF, THEN, ELSE, and END IF commands.

First, we can take care of the AM or PM switch. I created a new variable called am_pm for this. Then we use the following conditional:

 	' Test if time is AM or PM
	' ------------------------
	IF hour < 12 THEN
		am_pm = "AM"
	ELSE
		am_pm = "PM"
	END IF

If the hour is less than 12, this marks it as AM. Otherwise, it’s marked as PM.

Next up is the conditional to make 0 display as 12. For this, we needed a new variable to display the hour. Typically, you could use the hour variable itself, but since it controls our loop, I didn’t want to change its value, so I created a new variable called hour_displayed.

	' Convert 0 to 12, if needed
	' --------------------------
	IF hour = 0 THEN
		hour_displayed = 12
	ELSE
		hour_displayed = hour
	END IF

The final thing to do with the hour is to subtract 12 from any hour_displayed variable that is greater than 12.

 	' Convert anything over 12 to proper format
	' -----------------------------------------
	IF hour_displayed > 12 THEN
		hour_displayed = hour_displayed - 12
	END IF

For this, we didn’t need an ELSE statement, since the variable is fine as it is if it is less than or equal to 12 already.

Finally, we need to convert the minutes and seconds less than 10 so they display with a leading zero. I did this in the middle of the “second” loop (that is, the loop counting seconds) so as to get both minutes and seconds at the same time:

			' Add leading 0 to any single digit for both minutes & seconds

			IF minute < 10 THEN
				minute_displayed = "0" & minute
			ELSE
				minute_displayed = minute
			END IF

			IF second < 10 THEN
				second_displayed = "0" & second
			ELSE
				second_displayed = second
			END IF

Finally, we plug all that in to our original program and we get this, which perfectly mimics the FormatDateTime function (as used previously).

 'VBScript program to make a fake clock

' ===== Variables ====================

option explicit
dim hour, minute, second, clock
dim objFSO, objFile, objNotepad
dim am_pm, hour_displayed, minute_displayed, second_displayed

' ===== Initialization ===============

set objFSO = CreateObject("Scripting.FileSystemObject")
set objFile = objFSO.CreateTextFile("output.txt", TRUE)

' ===== Loops ========================

for hour = 0 to 23

	' Test if time is AM or PM
	' ------------------------
	IF hour < 12 THEN
		am_pm = "AM"
	ELSE
		am_pm = "PM"
	END IF

	' Convert 0 to 12, if needed
	' --------------------------
	IF hour = 0 THEN
		hour_displayed = 12
	ELSE
		hour_displayed = hour
	END IF

	' Convert anything over 12 to proper format
	' -----------------------------------------
	IF hour_displayed > 12 THEN
		hour_displayed = hour_displayed - 12
	END IF

	for minute = 0 to 59
		for second = 0 to 59

			' Add leading 0 to any single digit for both minutes & seconds

			IF minute < 10 THEN
				minute_displayed = "0" & minute
			ELSE
				minute_displayed = minute
			END IF

			IF second < 10 THEN
				second_displayed = "0" & second
			ELSE
				second_displayed = second
			END IF

			clock = hour_displayed & ":" & minute_displayed & _
				":" & second_displayed & " " & am_pm

			objFile.WriteLine(clock)
		next ' second loop
	next ' minute loop
next ' hour loop

' ===== Clean up loose ends =========

objFile.Close

wscript.echo("Done.  Click OK to view results.")

set objNotepad = CreateObject("Wscript.Shell")
objNotepad.Run("notepad.exe output.txt")

There ya go. :-)