SimSet iterators

#1 You don't need them...just use a for loop, create an index, and use Set.getObject(%index).

#2 Thanks for the reply!

Looking at the post it wasn't really clear. What you suggest is what I normally do. I admit it, Python has spoiled me ;^) I've been doing more Python programming recently and the "for item in list:" is really nice. Failing that using a C++ type iterator is appealing. I was just curious if torquescript had iterators. No big deal that it doesn't, but I may write an iterator object just because ;^)

Incidentally, SimSets are really cool. I need to process a list in a random order and to do this I pull a randomly selected index number to the beginning of the list with the lower bound of the generated index increasing with each increment.

Tim Doty

#3 Btw, simsets don't store objects in any guaranteed order, so don't rely on ordering within simsets. I learned that the hard way. ;)

#4 @Jason:

I haven't looked at the underlying code, but I assumed it was a list of some sort which should give you a stable ordering unless an object is removed, added or changed position (bringToFront, pushToBack). Could you explain a bit more about your experience?

#5 SimSets are classified as an Unordered Set, in that there is no guarantee that order is maintained. There is no (again) guaranteed relationship between any two objects in the set, with the exception that they are both within the set.

Yes, for the most part, order is kind of kept, but especially at the theory level it would be unwise to plan on this staying the same over time--for example, someone may come up with a a new algorithm/implementation of SimSets in the future that would not operate the same, and any code that you wrote with the assumption that order was guaranteed would no longer work--because your assumption was incorrect.

Via pushToBack and pushToFront, you can enforce a limited amount of order within your set, but if you ever break from using either of those actions during your set manipulation, you will lose the ordering "agreement" you've implemented.

#6 I understand it being an unordered set. Examples would be sets that simply traversing alters the "order" of objects contained in it so traversing the same set twice could get the objects in different orders.

I guess part of my "issue" with that is the implication that even if the torquescript does nothing to a set that it could re-order. If that is the case then you can't even do a traversal and expect it to get all objects in the set or even only get an object once because the only means of traversing the set is via index. In fact, for most purposes it makes the set rather pointless. About the only thing you can do is use the simset membership function to determine if an object is of a given type.

While that has some utility you can do the same simply by setting a data member. The advantage of the simset would (theoretically) have been the ability to easily iterate over all objects of the type (the alternative being to iterate over all objects and only act on those with the data member).

Writing an actually useful container (say, a doubly-linked list) is completely trivial and can be done even in pure torquescript so it isn't like this limitation prevents anything, but I admit to being a little stunned at the utter futility of the SimSet and wonder at the point of even having it.

#7 No, as long as all you are doing is traversing the set, you are fine. We iterate over the contents of a SimSet quite often using something similar to the following:

%setCount = %mySet.getCount();
for (%index = 0; %index < %setCount(); %index ++)
{
  %objectInSet = %mySet.getObject(%index);
 .....
}

The set's ordering isn't going to change unless you delete an object that is within a set, remove an object from the set, or add an object to the set.

All I was talking about is don't count on being able to always call %someObject = %someSet.getObject(5); at any time and any manner. The main reason is that if %objectX happens to be within %setA, and some point in the future %objectX is deleted by another method, it will be (obviously) removed from %setA, and therefore your set may become re-ordered.

SimSets aren't futile at all, in fact once you start using them you will rarely find the need for any other data structure.

#8 Well, my question was for clarification from a statement by Jason:

Quote:
@Jason:

I haven't looked at the underlying code, but I assumed it was a list of some sort which should give you a stable ordering unless an object is removed, added or changed position (bringToFront, pushToBack). Could you explain a bit more about your experience?

To which you replied in part:

Quote:
Yes, for the most part, order is kind of kept, but especially at the theory level it would be unwise to plan on this staying the same over time--for example, someone may come up with a a new algorithm/implementation of SimSets in the future that would not operate the same, and any code that you wrote with the assumption that order was guaranteed would no longer work--because your assumption was incorrect.

I can't think of any dynamic set which would have the property of absolute indexing. The closest is using "auto_increment" fields in databases, but those are not guaranteed to always return the result. When you say "for the most part" and "at the theory level" it seriously implies greater dynamism than simply: "if you do something to alter the set." For example, the "index" of an object just added has not been defined and, as it clearly alters the set, in an unordered set you could get in trouble by making an assumption about ordering.

You're statement above is pretty strong. The "any code..." part for example. Hence my reaction. If all you meant was altering the set could alter the order that is much different.

Edit: forgot a bolded not. Sigh

#9 Mostly what I meant was that if you add some elements to a set, they may or may not be in the order in which they were added when you iterate over them with a for-loop. They should be pretty stable unless you remove/add more. I had some code which assumed order was maintained (a queue implementation), but it didn't always work, and finally I discovered why. So I made my own container classes to guarantee order.

Just trying to save you some headaches in the event you make the same assumptions. :)

#10 @ Jason: And I certainly appreciate that. And it made me think. There is one case where there is an implicit assumption that the order would be stable between instances (that is, if the client and server both have identical simsets and both add an object to it that the object would end up in the same position in each). Probably correct most of the time (like object handles incrementing), but not necessarily a good assumption.

My long term solution has always been to use server-pushed objects which will then be able to have unique identifiers consistent across all clients (the server object handle), but until then I probably should do something to ensure that objects are accurately identified between the client and the server. Not that I care for using names but the objects already have them and its a quick search to find the right object (I've already had to resort to similar search techniques in some client/server situations).

@ Stephen: And I appreciate you're trying to explain things to me. I can be as literal minded as a computer at times, but I do appreciate you're efforts.

#11 @Tim: Not a problem...sometimes it's hard on the forums to know folk's background, so I tend to try to explain theory behind concepts as well as specific implementation/usage questions. As it turns out, you obviously understand the concept of abstract data types, so I probably confused the idea further by not being complete in my description!

What I didn't refer to until my second post was the concept of smart referencing (and I should have used the term even in the second post)--which basically means that the reason you can't "trust" the ordered-ness of a SimSet between execution frames is that one of the elements of the set may have been deleted since your last access of the set--and that means that it will be auto-magically removed from the set, possibly reordering it.

Of course (assuming you stay single threaded), within a single execution frame the set will stay ordered as long as you don't add/remove from it.

#12 @Stephen: true enough about background and even though I've been a member for a while my posting is sporadic and suffered a major lapse for quite a while there. My tendency (when I'm giving explanations) is to over explain which has its own problems (like offending someone by assuming they don't know things they do). Whatever you do is a balance and never going to be right in all situations.

The single-threadedness assumption is violated as soon as a client/server relationship is invoked. It's been a while since I've done network programming and, as noted in my last post, I fell into that trap. Whether or not ordering is currently stable for only addition of objects between clients that is a bad assumption. After sleeping on it the solution is obvious and just part of the next implementation step.

Again, I appreciate you weighing in. Better a scare about the implementation than an obscure and hard to find bug due to a stupid oversight on my part.