Keeping track of associative lists in Design Philosophy

ID:265636
 
Sep 24 2006, 4: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 =/


#1 Sep 24 2006, 7: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.
#2 Sep 24 2006, 12:04 pm
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
#3 Sep 24 2006, 8:49 pm
In response to Lummox JR (#2)
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
#4 Sep 25 2006, 4:07 am
In response to FananaQ (#3)
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

#5 Sep 25 2006, 4:32 am
In response to Crispy (#4)
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
#6 Sep 25 2006, 5:51 pm
In response to DivineO'peanut (#5)
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"))
#7 Sep 26 2006, 3:48 am
In response to DarkView (#6)
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]?
#8 Sep 26 2006, 4:20 am
In response to DivineO'peanut (#7)
That should output 7, yes.

biglist["rofl"]["lol"]["omg"][2] would do the same.
#9 Sep 26 2006, 7:52 pm
In response to DivineO'peanut (#7)
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.
#10 Sep 27 2006, 3:56 am
In response to Crispy (#9)
Hurr... That's confusing. 0.o

Thanks though, now I can use huge lists of huge lists of huge lists! :D
#11 Sep 27 2006, 4:44 am
In response to DivineO'peanut (#10)
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.
#12 Sep 27 2006, 2:30 pm
In response to Nadrew (#11)
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.
#13 Sep 27 2006, 2:32 pm
In response to ACWraith (#12)
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.