Tic Tac Toe Coding Challenge

[agill]

---

jasonhill wrote:

<mode grouch="tech geek">
Darn kids. In my day everyone used .rar because .zip did not support disk spanning.  Do you remember disk spanning?  Gaining popularity.  PAH!  Regaining, more like.

Fetch me my cane! (and some coffee)
</mode grouch="tech geek">

---

Eh, it's a matter of semantics.

If something is "regaining" popularity, it is also "gaining" popularity.  Once, again it's a matter of semantics.  In fact, I have indeed used disk spanning with rar, and its disk spanning (well, mainly by file splitting) is still being used today.

Message Edited by agill on 06-26-2006 11:13 AM

[Daklu]

PKZip was the one I remember using first. When disk spanning was introduced it was a huge leap in technology.

Heh heh... we must be geeks if we're reminiscing about file compression technology. 😄

tst, I've gone through the tutorials (mostly skimmed with periodic in depth reading) and the Connexions tutorial is easily the best. It has a good table of contents making it simple to quickly go to the section of interest. The NI tutorial is pretty good too. As for the others... meh. There might be one or two points to be learned, but for the most part they are dated and not very complete.

I've also tried to save my vi in version 7.1. I don't know if it worked, but here's my attempt.

Message Edited by Daklu on 06-26-2006 11:08 AM

[tst]

---

@Daklu wrote:

tst, I've gone through the tutorials (mostly skimmed with periodic in depth reading) and the Connexions tutorial is easily the best. It has a good table of contents making it simple to quickly go to the section of interest. The NI tutorial is pretty good too.

---

In that case, I'll just leave it in its current order. I'll leave the others in just in case real newbies want more tutorials. BTW, if you'll look at the title page of the cnx tutorial, you'll see it was written by NI.

Anyway, your code was almost fully saved (player.ctl wasn't). To save for a previous version, it's probably best to just open the top level VI and perform a save for previous. It should save all dependencies. No need to save it again.

I really don't think anyone would mock your code. I only gave it a quick look, but I can tell you that it looks very good, appears to be relatively well documented, has coooool icons (don't underestimate that, a lot of us would probably prefer spending most of our development time designing cool icons) and appears to be well structured. I can't comment on functionality, but that's already up to you.

3 points I will make is that those 2 "unstraight" wires in the top level VI really stand out like a clown's nose, that you'd be better off setting the diagram terminals not to appear as icons and that for controls used in more than one VI it would usually be wise to create a typedef.

P.S. Have you seen the BreakPoint? I think you'll like it.

[Daklu]

Thanks for looking it over tst. I realize everyone here has real work to do if they want to keep getting their paycheck, so I really appreciate the feedback.

"has coooool icons..."

LOL. I certainly won't win the contest, but maybe I can get a boobie prize for best icons. 😄

"your code was almost fully saved (player.ctl wasn't)"

player.ctl was distributed with the original challenge. (Just in case anyone else has the same problem.) I probably shouldn't have included it.

"those 2 "unstraight" wires in the top level VI really stand out like a clown's nose"

Perfect for a joker like me. 😉

Yeah, I almost always try to keep my wires as straight as I can (to the point of spending way more time on the layout than the functionality) -- I'm not sure why I didn't that time. I also thought about the left to right coding standard, but figured bringing a couple wires from the top of the diagram would be easier to read than creating long wires from the left side.

"you'd be better off setting the diagram terminals not to appear as icons"

Agreed. I left most things as icons simply to help me remember what each thing was. Color me a noob. 🙂

"for controls used in more than one VI it would usually be wise to create a typedef."

Don't know how to do that yet. Nor do I know what the advantages are, disadvantages are, or how to use them correctly. Other than that, I'll be sure to do that next time. (I'll have to search for advanced tutorials.)

"Have you seen the BreakPoint? I think you'll like it."

Bookmarked. Thanks.

[tst]

---

@Daklu wrote:

Yeah, I almost always try to keep my wires as straight as I can (to the point of spending way more time on the layout than the functionality) -- I'm not sure why I didn't that time. I also thought about the left to right coding standard, but figured bringing a couple wires from the top of the diagram would be easier to read than creating long wires from the left side.

---

There's no problem with wires coming from the top. I agree that it's better than wires coming all the way from the left. My problem was actually that one of them was also going backwards and the other one was very close to it, so they created clutter. I know what you mean about the layout - I very often spend time on aligning code in different frames of a case structure just so that it would look right. In my defense, I believe it also links the pieces of code better in my mind.

The advantage of a typedef is that changes to it propogate to all your VIs (think what would happen if you wanted to change that radio button to have another option or to rename one of the options). The main (only?) disadvantages are that you end up with another file to manage and that certain things are locked by the typedef and can't be individually modified for each instance. This is more problematic with your UI and with strict typedefs.

[Daklu]

---

@tst wrote:
The advantage of a typedef is that changes to it propogate to all your VIs (think what would happen if you wanted to change that radio button to have another option or to rename one of the options).

---

I don't think I'm quite following you here. Right now I'm using DesirabilityFunction.vi in three different places. If I make a change to any one of them, the other two are also changed. What am I missing?

Message Edited by Daklu on 06-26-2006 05:30 PM

[tst]

A typedef is a control, not an entire VI. An example of this would be player.ctl, which is a picture ring typedef (I hope). If you wanted to add another kind of player, you would only need to do it once. If it was a regular control (which it might be, I haven't checked) then you would have to go and change it at each place it's used.

Typedefs make it very easy to work with data through different VIs, because you can keep changing the structure of your data. Enums and clusters work very good with this. Note, however, that if you delete or move stuff in a typedef, LV will try to fix it for you, not always with desirable results and you may not be alerted to it, so you should try sticking to only adding stuff to typedefs, unless you're ready to go through your entire code and make sure it's still OK.

[BruceAmmons]

First preliminary scoring is coming!!!

I downloaded all the different entries I could find on this thread.  I also have a few entries that have been emailed directly to me.  I will be running them all against each other in the next few days and posting the preliminary results.

If you have a new version you want included in this scoring, it is probably best to email it to me at tictactoe@ammonsengineering.com to make sure I get it.

My current plan is to run each player matchup 100 times as X and 100 times as O.  Right now, I don't plan on breaking any ties until the final scoring.

Bruce

[BruceAmmons]

I ran each player 500 times as X and 500 times as O against each of the other players.  I did two runs, one with the random players and one without.  The scores are:

No Random Players:
9906 ohw313
9894 Dan Marlow
9888 Toe Jam
9776 CC ref
9612 KP2a
9598 Ammons
9127 Opus 1
6656 Shane
6543 Altenbach001

With Random Players:
13745 ohw313
13617 Dan Marlow
13548 CC Ref
13410 Toe Jam
13405 Ammons
13042 KP2a
11489 Opus 1
9113 Altenbach001
8820 Shane
6312 CC Random
4499 AE Random

Perhaps this will get the discussion going again.  Right now, I would say the lead is clear enough to not require a tie breaker.  For the final scoring, I will increase the number of times the game is played against each player.

Bruce

[ohw313]

HI Bruce,

Thanks for the results.

Just a little unsure of what the score is. You say each players plays 500 times against all others as X and then 500 times as O.

So, with 9 players each player should play against 8 opponents(I.e. 8000 matches)

Is the score then the amount of times the player wins or loses?

Sorry for the confusion.