Keeping track of associative lists

ID:265636
 
Sep 24 2006, 2:33 am
I'm currently trying to keep track of huge assosiative lists, and was wondering which one(if any) of these methods would work better?

list method
var/list/villages = list( \
    "village1" = list( \
        "rank1" = list(),
        "rank2" = list(),
        "rank3" = list(),
    "village2" = list( \
        "rank1" = list(),
        "rank2" = list(),
        "rank3" = list())
    )
)
//but sadly, i have no idea on how to access that, and it looks ugly =/

datum method
village1
    var
        list
            rank1 = list()
            rank2 = list("adg","asgta","gad")
            rank3 = list("veh","gadg")

village2
    var
        list
            rank1 = list("gas")
            rank2 = list("35")
            rank3 = list("asdha")

var
    village1/first = new /village1()
    village2/second = new /village2()

// yet this doesn't look very efficient =/


Sep 24 2006, 5:14 am
DivineO'peanut wrote:
> village1
>   var
>       list
>           rank1 = list()
>           rank2 = list("adg","asgta","gad")
>           rank3 = list("veh","gadg")
> 
> village2
>   var
>       list
>           rank1 = list("gas")
>           rank2 = list("35")
>           rank3 = list("asdha")
> 
> var
>   village1/first = new /village1()
>   village2/second = new /village2()
> 
> // yet this doesn't look very efficient =/
>


I'd go with the datums because they're much less complicated than that list setup. Also, what if you had a parent village type? Something like this, maybe?

datum/village
    var/list {rank1;rank2;rank3}
    village1
        rank1=list()
        rank2=list()
        rank3=list()
    village2
        rank1=list()
        rank2=list()
        rank3=list()
    //And so on...


That's what I think, anywho. You should probably wait for a few more opinions, though.
Sep 24 2006, 10:04 am
As DC suggested, you need datums here, but also the rank1, rank2, rank3 vars are a huge red flag. Unless you'll only ever need those three, you should consider making those a list as well.

Also, don't initialize lists you don't need yet. It's wasteful and will tax the limit.

Lummox JR
Sep 24 2006, 6:49 pm
In response to Lummox JR
Lummox JR wrote:
As DC suggested, you need datums here, but also the rank1, rank2, rank3 vars are a huge red flag. Unless you'll only ever need those three, you should consider making those a list as well.

Huh? They're already a list, what do you mean?

Also, don't initialize lists you don't need yet. It's wasteful and will tax the limit.

I do, they're set as the game begins. :p
Sep 25 2006, 2:07 am
In response to FananaQ
FananaQ wrote:
Huh? They're already a list, what do you mean?

You can have lists of lists. =)

var/list/rank = list(list("Someone with rank1", "Someone else with rank 1"), list("Rank 2 people here"), list("Rank 3 people"))


And then to access the list of people in a particular rank, you just access them by index:

// List everyone with rank 2
world << "<b>People of rank 2:</b>"
for (var/X in rank[2])
    world << X


Or even (and this is the kind of thing that makes it better to use a list of lists):

// List everyone in the village, ordered by rank
for (var/r = 1 to length(rank))
    world << "<b>People of rank [r]:</b>"
    for (var/X in rank[r])
        world << X

Sep 25 2006, 2:32 am
In response to Crispy
Oh, like in my first example? Sorry, I didn't understand. :p

Problem with that is, that when you have lists of lists of lists, I've got no idea how to access them. 0.o
Sep 25 2006, 3:51 pm
In response to DivineO'peanut
Well in some situations you can use loops like Crispy showed, but most of the time you'll do something like rank[1][2], where 2 is the index of the list within index 1 of the main list.

Ie, in the following [1][2] would be the second value in the first list, "2".

list(list("1","2"),list("3","4"))
Sep 26 2006, 1:48 am
In response to DarkView
So...

var/list/biglist = list("rofl" = list("lol" = list("omfg" = list(3,7))))


I'd access 7 like this? <code>biglist[1][1][1][2]?
Sep 26 2006, 2:20 am
In response to DivineO'peanut
That should output 7, yes.

biglist["rofl"]["lol"]["omg"][2] would do the same.
Sep 26 2006, 5:52 pm
In response to DivineO'peanut
DivineO'peanut wrote:
I'd access 7 like this? <code>biglist[1][1][1][2]?</code>

Actually, no... biglist[1] would give you "rofl". biglist[1][1], biglist[1][1][1], and biglist[1][1][1][2] would all give you runtime errors.

It's a bit unintuitive, but that's the way it is.

What you want is <code>biglist["rofl"]["lol"]["omfg"][2]</code>.


This might just confuse you (if so, don't worry about it), but I think of DM lists as having three pieces of information attached to each entry:

1. A list index. This is the entry's position in the list; 1, 2, 3, etc.

2. A value. This can be anything.

3. An additional associated value.

When you use ordinary lists, (like var/list/L=list("red", "green", "blue")), you're only using #1 (as the "key") and #2 (as the "value"). #3 is null. For example, if you accessed L[2] in my example, you'd get "green". If you accessed L["green"], you'd get null.

When you use "associative lists" you're using #2 as the "key" and #3 as the "value". #1 still exists, but you don't tend to use it.

A consequence of this is that non-associative lists are exactly the same as associative lists as far as DM is concerned; it's just that the associated values are all null.

Took me a while to figure this out. It has to be the oddest implementation of lists that I've seen in any programming language, but it works pretty well.
Sep 27 2006, 1:56 am
In response to Crispy
Hurr... That's confusing. 0.o

Thanks though, now I can use huge lists of huge lists of huge lists! :D
Sep 27 2006, 2:44 am
In response to DivineO'peanut
Don't get too cocky with those lists, there's still a limit on how many you can have (65535), and each list() or list/new() you use goes towards the limit. Associative lists are handy, and multidimension ones are even handier, but you need to know when to use them and when not to.
Sep 27 2006, 12:30 pm
In response to Nadrew
I've been thinking the same thing whenever I've read this thread, but I didn't know where to post.

In some instances, I've taken to using a single flat list. In other words, I put labels in a list and put values between the labels. There's a speed hit because of multiple calls to different list procs instead of using the [] operator. However, a single list can hold billions of things and I don't have to worry about requiring unique values to make associations.
Sep 27 2006, 12:32 pm
In response to ACWraith
Huh! I never looked at it that way.

I've used flat lists before when I had a simple structure -- it's just a simple matter of taking a slice of the list by using list.Copy(start_index, end_index) -- but the limit never came to mind.

Of course, I don't think I've ever been in danger of breaching the list limit either.