2.4k
views6
comments

Hi all!

If any of you saw any of my earlier posts you'll know I'm learning through making a program which gets basketball statistics and so on.
At the moment I have a file with a bunch of functions. Defined a value "date" it connects and gets me every nba match for that date and the statistics of every player.
Some thing in the like of:
For 03/11/09, it returns the players involved (in this case just the first match of the night), in a list in the like of:

> playersStats;;
val it :
  (string * string * string * string * string * string * string * string *
   string * string * string) list
= [("cj_miles", "22:58", "2-8", "1-2", "0-0", "3", "4", "1", "2", "2", "5");
   ("carlos_boozer", "32:03", "6-11", "0-0", "1-2", "8", "2", "5", "0", "4",
    "13");
   ("mehmet_okur", "29:32", "6-12", "2-4", "0-0", "10", "2", "5", "0", "0",
    "14");
   ("ronnie_brewer", "36:07", "5-12", "0-0", "4-4", "3", "0", "2", "2", "0",
    "14");
   ("deron_williams", "41:13", "9-17", "1-2", "1-2", "4", "9", "2", "1", "5",
    "20");
   ("maurice_evans", "17:55", "1-2", "0-0", "0-0", "3", "0", "0", "1", "1",
    "2");
   ("josh_smith", "42:20", "9-15", "0-0", "4-7", "12", "3", "3", "1", "1",
    "22");
   ("al_horford", "38:12", "5-10", "0-0", "3-8", "12", "2", "1", "2", "1",
    "13");
   ("joe_johnson", "44:13", "10-20", "3-4", "8-8", "3", "9", "4", "1", "3",
    "31");
   ("mike_bibby", "26:37", "1-6", "0-2", "0-0", "1", "2", "3", "1", "2", "2")]

As I said, I have it all mixed up in the same file and I think it's time to start organizing it well.

After reading twice Don Syme's chapter on "Encapsulating and packaging your code" I still have things I don't fully understand.

Trying to stay as functional as possible but with ease of understanding in mind:
1. Should I make a structure type in the like of the below ones for each player and another different one for every match or should I stay with lists like till now?

type PlayerStat = {
    name: string;
    team: string;
    position: string;
    minutesPlayed: System.DateTime;
    fieldGoals: string;
    threePointers: string
    freeThrows: string;
    rebounds: int;
    assists: int;
    fouls: int;
    steals: int;
    turnovers: int;
    bs: int
    points: int
}

type MatchStat = {
    date: System.DateTime;
    Teams: string;
    TeamAway: string;
    TeamHome: string;
    Team1Stats: PlayerStat list;
    Team2Stats: PlayerStat list;   
}

2. When should I put things into a module and or namespace? Which ones? Meaning... should the structures PlayerStats and MatchStats be included in the module or outside it?
Does it seem right to createa a namespace called "Stats" in this case?

3. Is there any real scenario where it's convenient to create an object type with values, members, etc...? Coming from OO programming seems the straightforward way of thinking... but I don't know if it's the better choice when programming with F#, or if it's really ever necessary some time or even useful.

Any help appreciated. Of course, if you have links to any good explanation on this, that'd be great.

If you manage to read it all... I can just say THANKS A LOT.

Cheers!

For organizing the data: I would go for the structured type - tupels are fine but in your case it's unreadable (what was the 7th component for?)

Using modules/namespaces:

I only use namespaces if I want to write code for a dll - i.e. algorithms etc. that get called from other programmers / other languagues (C# etc.) and I normaly create files/modules for purposes (for example a file for players, one for matches, etc.)

But this will depend on your style of programming (in OO you can go for one class per file, x classes per file or even partial classes that spreads a class over many files - you have to choose for yourself when to take what)

By Carsten Koenig on 3/12/2009 7:46 AM (permalink)

I guess then there isn't any fixed criteria on when to use what or how to organize everything.. isn't it?

Maybe this question is stupid, but.... do structures have any impact on performance compared to lists/matrixes, etc?

Thanks a lot!

By Cobo on 3/12/2009 8:29 AM (permalink)

Some ways of organizing your data will probably perform better than others, but a lot of it is going to depend on what you're trying to do with it. In most applications, you'd probably still have a list of player statistics, but instead of being a list of (string*string*...), it would be a list of PlayerStat objects. On the other hand, if you're always going to be looking at statistics on a team-by-team basis, you might want a map of lists of PlayerStat objects keyed by team name. If you only care about aggregated player data instead of game-by-game data, you would store your data differently as well.

On that note, you may also want to change your PlayerStat type a bit; if you want to filter your list so that you have only the instances where a player shot more than 90% from the line, that's going to be tough at the moment because free-throws are stored as a string. Instead, it probably makes sense to parse the string into a pair of integers for shots made/taken. In general, think about what you want to do with your data, and that should make it easier to think about what your types should look like.

By Keith Battocchi on 3/12/2009 8:53 AM (permalink)

1. I'd go even further in typing your code, getting rid of the strings alltogether (except for the names). Try making a ratio type (or whatever you want to call it) to encapsulate the "20:11" kinds of strings, and another one to encapsulate the "0-0" kind of strings.This will be more safe, less parsing of the values, and easy pattern matching. Otherwise your record types look good to me.2. Wouldn't worry about namespaces at this point. If you need them, you'll know, and they're trivial to add anyway. I agree with Ckoenig's advice.3. I can just say, yes it's still useful, for all the usual reasons. If you have a bunch of operations and some data that logically belong together, go ahead and make it an object. F# is not purely a functional langauge: it seeks to bring together functional, OO and imperative programming. You shouldn't be reluctant to use the OO skills you already have. Mix and match as you see fit: it's a free language ;)Kurt

By Kurt on 3/12/2009 1:18 PM (permalink)

It seems like you could use some internal harmony of your data types.

1) You can do key-value lookups on the data. That way, you can have flexibility in your what you present in your interface.

2) You might try moving things into ``right types''. I think strings lose a lot of the type safety inherent in f#. If you want to go crazy, you can attach units to all your values.

By none on 3/13/2009 10:31 AM (permalink)

Hi all and thanks for answering!

First of all... about what you all have pointed out about the types in the structure, I had already realised that the moment I put the code in here. I just was in a hurry (as always I guess) and wrote a quickly structure without caring for that. In the version I'll use the only strings left will be the names' ones. Thanks for the advice though!

Secondly... I have some simple questions. Having in mind that the data will be stored on a database:
2.1. Is it still usefull to have a Map<key, value> to lookup the data? Or does it have nothing to do with how you store your data?

2.2. As for the object thing... if applied the philosophy Kurt told... we will be making objects far more times than I've seen here in the forums and Don Syme's book. If so, we would be writing pure functional compositions and functions in things like a mathematical library and some other few examples. I believe objects also have an impact on performance.
Is this a personal matter or is there any criteria on when to use objects VS structured types, compositions and functions? If this is the case... I would be delighted if some of you could share their experience in making this kind of decissions. Maybe is a silly question, but when you're a beginner you see to have everything more "tied up" (I don't really know how to express that... I don't speak English as my mother language) I guess...

Thank you all for the help. I think I'm goind to start putting the conclussions of this into my blog just to try and help other beginners with similar questions to these.

Thanks again! Cheers!

By Cobo on 3/18/2009 2:42 AM (permalink)

Topic tags

Built with WebSharper

Home

Answers

Events

Courses

Groups and Conferences

Blogs

Jobs

Developers

Topic tags