Zugg Software :: View topic - What's the best way to use a temp var with #delitem?

Posted: Sun Mar 08, 2009 4:54 am

I can't use just $one alone or it doesn't work. I ended up putting $one in a %concat statement. Is there any better way to do this?

#additem onevar "One"
#forall (one) {
$one = %concat( %i, "var")
#if (%ismember( "One", @{$one})) {
#say here $one
#delitem %concat( $one) "One"
}
}
#say "Final: " @onevar

SubAdmin Joined: 18 Nov 2001 Posts: 5182

That is about the best way. Indirect references/pointers aren't really encouraged in zScript. There are usually better ways to build the same script result.

Posted: Sun Mar 08, 2009 3:43 pm

If they aren't encouraged, what's the way to get around that then? I have a list of variable names that need to be looped through and I either need to construct them by looping through them or list them all outside a loop. I thought I was being a bit more efficient doing it this way.

Magician Joined: 17 Apr 2005 Posts: 496

Posted: Sun Mar 08, 2009 4:10 pm

Thanks for that code gamma_ray, but what I'm trying to do is a bit different from what I posted above to ask the initial question. In the code below I'm looping through the different string lists that hold city names and I remove the name if it is found. As far as I can tell I either do it this way or I unroll the loop and do them all one at a time manually. I just thought this looked a bit neater and was easier to alter if needed instead of making the same alteration to each of the components individually if I unroll it.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I can't really suggest a better way for this particular piece of script without knowing some details about the NameHonor and Citizen* variables. I am assuming CityList is a complete list of all citizens in your city, but it makes little sense to me why you would loop through such a list testing for '!=%1' when %ismember provides an equivalent capabilty. I need to know more about what the variables contain and what you want to do to suggest the correct solution.

So far I don't see anything that actually requires an indirect reference.

Posted: Sun Mar 08, 2009 9:34 pm

Going into that code, @CityList contains a list of the cities in the world. Combine the text in @CityList with 'Citizens' becomes the name of the variable with all the citizens of that particular city, for example @CitynameCitizens. @NameHonor is the name of an individual who is under investigation at this point in time. Additionally, %1 is the city to which the person in @NameHonor belongs.

So, overall, as I loop through the different cities if they don't belong to the city and they are listed under the city they are not a part of, then remove them from that list. They might be erroneously listed under any of them, so I check them all.

Magician Joined: 17 Apr 2005 Posts: 496

From reading it (and guessing) I think what it is, is like this:

@CityList // a list of all cities in game
@CityCitizens // a list of all citizens in City, referenced by @{$CityVar}
//and I think it's in some sort of "check information about a person" script, so
%i // the name of the city that the person is actually currently a member of
@NameHonor // the person in question

So, check which city a person is a member of right now. Go through all cities, if it's not the city that the person is a member of, check if they're recorded as having been a member, if so, remove their name from the list.

No better version at present, maybe after breakfast.

Posted: Sun Mar 08, 2009 10:03 pm

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I will assume citizenship can only be to one city.
#ADDKEY Citizen {@NameHonor} {%1}

If you really need them listed by city.

Posted: Sun Mar 08, 2009 10:35 pm

Normally I'd go with a database variable, but in this case I use the citizenship variables to highlight players with:

Regex: \b(@cityCitizens)\b
#cw color

Done for each city.

Magician Joined: 17 Apr 2005 Posts: 496

It wouldn't be a bad idea to keep it in a DB var and then use that to update your string lists. At least you can get rid of looping and simply remove from the old citizenship list and add to the new citizenship list. Also, since you won't have any duplicate items on your lists (ever), you can use %removeitem without a loop.

Posted: Mon Mar 09, 2009 12:18 am

You probably don't want to use that regex, ReedN - I'm assuming that the list of citizens will be pretty big, and running a regex with tons and tons of items without making some kind of trie from it will be incredibly slow. I remember someone was doing something similar with City Enemies on Achaea and was having trouble with the match speed of the regex. I've been meaning to get around to writing some code that'll take a long list of names like that and build a patricia trie regex from it in the hope that that'll improve the speed, but I've been so busy recently :(

Anyway, back to the original problem - let me first make sure I understand the problem. You have a bunch of variables CityCitizens that list all the people in that city, and you want to check to see if your variables are accurate. You have a way of determining which city someone's from, and after you use it you want to check that that person is stored in the correct city. Is that right?

Firstly, I assume that the list of cities is constant or changes only very occasionally, in which case you probably want to hard-code them. Any time something has to be compiled before it can be run (like the dynamic varrefs you're creating as a result of @{blah}) will be slower than something that can be compiled once and then just executed (a @blah reference).

The specific reason that the code in the OP doesn't work is because #delitem is trying to perform the operation on the contents of the $one variable rather than on a variable whose name is contained in the $one variable. Using %string($one) to work on the variable named in $one rather than $one itself should be all you need to get that particular code working.

But I wonder if that's the best way to go about this problem. Is this an operation you perform often, or is it a batch-style thing where you'll update everyone at the same time each day? Because it might be good for you to create a reverse-table of people you've recorded, where keys are people's names and values are the city they're recorded as being part of. Then you can simply test to see if their city is correct using the reverse table. If it isn't, you delete them from the old city (which you know from the reverse table) and add them to the new one.

The trouble comes with keeping the forwards- and reverse-tables synced, and I was writing it I'd want to completely rebuild the reverse table before I started looping through my list of names just to be on the safe side. But if the list is short (or even only one name long) then rebuilding the reverse table each time will be unwieldy and you'll either have to make sure you update the reverse table at the same time you do the forwards one, or use a different solution.

Posted: Mon Mar 09, 2009 12:37 am

Posted: Mon Mar 09, 2009 1:15 am

Well, building the tree is the easy bit and I already have code to do that. The trouble is making a regex from it, which is more complex than you'd think - you need to create the regex bart? when bar and bart are in the tree, but foo(?:bar)? when foo and foobar are in the tree. Frankly, I'm about ready to say "sod it" and just use bar(?:t)?, it's less pretty but much easier to write.

At least this thread is working well for getting me off my chuff and thinking about it :P

Enchanter Joined: 09 Sep 2007 Posts: 605

Building a regex from the tree is a way easy than build the tree itself. I could upload my patricia tree package to the library, if you are interested in it

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Knowing what your usage of this is changes a lot of things. Execution time isn't taking a tad longer, it is extremely horrible. Right now everytime you do this '#delitem %concat( $one) "One"' one of those '\b(@cityCitizens)\b' triggers has to be recompiled. I will write up a more detailed solution when I get home from work.

Posted: Mon Mar 09, 2009 8:22 pm

I thought up a different way to approach this. After seeing how easy it is to lock up Cmud if I accidentally have an empty string in between the \b's I put some more thought into this.

Previously I had 7 individual regex triggers looking for: \b(@var1)\b through \b(@var7)\b
Now I have just one regex looking for \b([A-Z][a-z]+)\b. After it matches it then has a switch to determine which list it is a part of:

Posted: Mon Mar 09, 2009 8:55 pm

ctrl+q is about matching speed, though, not processing time, and in the case of ctrl+q it's only about the match coming up false, not true. The new regex will obviously fail faster for ctrl+q, because the three places where \b doesn't fail (start of the string, before the space and after it) will be rejected in one check by [A-Z]. All 4000 entries from the old list would have to be processed individually in each of those three positions, hence the speed increase. In real text, where matches might come up very often but not be a person's name, doing all those %ismember checks may end up being slower than using a regex. I guess it depends on the ratio of false positives to real names.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

That is certainely better. You can make it even better using a trigger that is only active part of the time. Some events merit checking against the names list, like a person entering the zone or room, or when you are specifically check who/qwho. This trigger can be enabled with "#STATE ColorNames 1" and shuts itself off quite conviently.

Posted: Mon Mar 09, 2009 10:15 pm

Fang: I was considering exactly those factors:

Pro:
Tests will now only occur primarily at:
- The start of sentences where the first letter is capitalized
- Proper names.
Previously all 7 triggers were testing each and every word boundary in a sentence which is many many more checks.
It can never hang because of a %null item in the list

Con:
It takes a lot more time to fail/pass each time it makes a hit.

Overall I thought the pros outweighed the cons.

Vijilante: That's a good idea and I had toyed around with doing something like that, but I'm afraid that I'd need to keep it on for 90% of the text coming in anyway. I'd want it active on just about any random line to show up because it might be some attack or even something new I hadn't seen before. With my anticipated nearly always on methodology, creating triggers to turn it off only during the portion I know I won't need it might just push it over into consuming more computation resources.

Posted: Tue Mar 10, 2009 4:16 pm

It just occurred to me that now that I'm just testing for "\b([A-Z][a-z]+)\b" I can just change the string lists into a single DB variable. I think I'm correct in stating that it will be faster to do one lookup than to do 7 %ismember functions to each of the string lists. So now it would just be:

CityMembershipDB will have keys of Names and Values of city names.

Posted: Tue Mar 10, 2009 4:45 pm

I would expect that to be faster, yes (though all seven %ismembers wouldn't be called every time, the average is probably still about 3.5, which is still going to be slow). You could even cut a call out by doing:

Posted: Wed Mar 11, 2009 2:22 am

I used your simplification Fang, thanks for the suggestion!

With the list converted to a DB variable I ran across this function and converted it. It takes a list of random people and displays them by their city grouping. I couldn't find any more efficient way to do this. Does this look optimal for what I'm trying to do?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Small optimization. Making the %db lookup occur only once per person will be slightly faster. The total savings will only be noticeable if your list has a fairly large number of people. If you are using this to process large lists frequently then I might suggest a fancy subregex.