Gammon Forum : MUSHclient : Python : Python co-routines, how to use them?

Log on

Gammon Forum

Entire forum

MUSHclient

Python

Python co-routines, how to use them?

Python co-routines, how to use them?

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #30 on Sun 16 Dec 2007 02:09 AM (UTC)

Message

Perhaps the easiest way to state my question is that I am looking for a precise definition of the semantics of the affliction set. What does it mean to have a list of possible afflictions; what does it mean when there is overlap in those sets; does order matter in the list of possible afflictions; etc.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Isthiriel (113 posts)

bio

Date

Reply #31 on Sun 16 Dec 2007 05:42 AM (UTC)

Amended on Sun 16 Dec 2007 09:52 AM (UTC) by Isthiriel

Message

I think skills are guaranteed to give you one new affliction if it is possible for them to do so (that is, you don't already have all of the afflictions that they can give you). Otherwise this whole exercise would be done better (and much, much easier) with probabilities. (Four limb-breaking attacks becomes a 1.5625% chance of only one limb broken, 9.375% chance of all four broken, 32.8125% chance of two broken and 56.25% chance of three broken with a 68.36% chance of any particular limb being broken. Which took only a couple of minutes to calculate by hand.)

So, for (<ra la>, <ra la>) it doesn't matter which affliction the first skill gives you, the second will give you the other affliction.

OTOH, for (<ra la>, ra) if the first skill gives you la, then both arms are broken. If it gives you ra then the second skill doesn't do anything.

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #32 on Sun 16 Dec 2007 08:03 AM (UTC)

Message

Quote:
So, for (<ra la>, <ra la>) it doesn't matter which affliction the first skill gives you, the second will give you the other affliction.

OTOH, for (<ra la>, ra) if the first skill gives you la, then both arms are broken. If it gives you ra then the second skill doesn't do anything.

If those are truly the operating assumptions then that changes things, thanks for clearing that up. Those assumptions do surprise me, though: it suggests that when I attack you with some skill, the code looks at the afflictions you have, and gives you whatever you don't already have. That seems odd: I would have thought that first an affliction would be chosen, and then it would be applied, potentially resulting in a noop.

Well, anyhow, I'll give it a think. There's probably a much better way of approaching the problem that doesn't involve testing every possible combination...

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Isthiriel (113 posts)

bio

Date

Reply #33 on Sun 16 Dec 2007 09:52 AM (UTC)

Message

Like I said, "I think". I haven't played the mud(s) in question so I can't be sure. In the case of broken limbs it makes sense (because you aren't going to bother attempting to multiply disable a limb), poisons less so. Spells... well, that's magic.

Personally, I would have coded afflictions to be less random, so a certain poison might give you nausea, blurred vision, blindness, confusion, bleeding from the mouth and nose and finally death. Resisting part of the effects would mean not receiving the later afflictions, but if you get blurred vision you already have nausea. A specific expensive magical cure would remove the poison and its effects (or an even more expensive general magical cure), otherwise you're patching symptoms. (And the fun here would be guessing the poison from the symptoms :D particularly if you have a high resistance and a lot of poisons start with nausea.)

Ofc, I don't understand balances either :-/

top

Posted by

Worstje Netherlands (899 posts)

bio

Date

Reply #34 on Wed 19 Dec 2007 09:21 PM (UTC)

Message

First of all, sorry for the belated reply. I've been rather busy the last few days and didn't see a chance to reply before this.

It seems your discussion has already properly determined the semantics of the afflictionsets. It is CORRECT that if skills can give an affliction, you are SURE to have a new added affliction. I imagine the code at the MUDs side indeed goes like 'check for non-present afflicton'-'give non-present affliction'.

The information inside an afflictionset should be 'sensible' at all times. This means that (<RL, LL>, LL) or even the more elaborate (<RL, LL, BLIND>, <RL, LL>, LL) are situations that will not exist - as soon as the final LL is added to the set the entire set is evaluated and the afflictionset is simplified into what would be (RL, LL) and (BLIND, RL, LL).

A simple count of limbs would indeed not be sufficient for all the various reasons given - the various problems and intricacies of this model were easiest to explain using limbs (due to simplicity and not being mud-specific) but in practice limbs are not what I'm concerned with - it is the larger afflictionsets where a single <> can contain 10 to 20 items.

I am very aware that there is no 'one' simplification of a set, since multiple afflictionsets can give the same resultset depending on the road wandered. (<a, b>, <b, c>) and (<a, c>, <b, c>) being the simplest example of that, but if one looks at the 3x<RL, LL, LA, RA>, you can also find several simplifications that are different, but essentially mean the same thing when you look at all the resultsets. This is NOT a problem for me - I merely want the afflictionsets to become as simple (=devoid of possible choices) as possible, and the precise simplification I end up with does not matter for me.

I think that addressed most stuff about the afflictionset idea I came up with. Now, balances. It's a word that we use to denote the time from curing in a certain way until we can cure again. For example:

> eat herbX
You eat some herbX.
Your clarity of mind returns. <-- yay, afflictionY cured.

..wait..wait..some seconds later..
The herb has cleared your system.

This is the point at which I can eat another herb and have the herb cure something. If I'd eat another herb BEFORE the previous herb cleared my system, it would be a dud and not work. 'Having herbbalance' would thus mean that I'd be able to eat a herb at a certain point. This concept prevents people from spamming cures and adds more of a tactical approach to curing, since you can't just spam all possible cures at all times. Hell, it is worse - for quite a few balances it is so that trying to use the balance (eat a herb while not ready to eat one again) would increase the time it'd take to regain the balance, slowing down ones curing considerably. Salve curing (used to cure limbs) in my mud is even a bit more complex - the time to regain the balance depends on the salve used and on top of that, some cures simply fail if another cure isn't done first: curing of the limbs.

Anyhow, I deviate again. The balances themselves do not matter for this problem (I merely mentioned them to clear something up I think) nor does the precise order in which stuff is cured. I've got plenty of experience and working code for that already. The afflictionsets are the ones I need to get simplified.

Premature thanks come in the paragraph, but hey, actually getting this discussion going means a lot to me already given the fact that what I'm doing is kind of over the top for 99% of the people I play my mud with.

Thanks for everything, Isthiriel, Nick Gammon and David Haley. It's very much appreciated. :)

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #35 on Wed 19 Dec 2007 09:50 PM (UTC)

Message

Given the discussion I had with Isthiriel, I don't understand how this:
(<RL, LL>, LL)

is simplified to this:
(RL, LL)

when the choice comes before the non-choice. However, I would be perfectly happy to take this:

(LL, <RL,LL>)

and simplify to this:
(LL, RL)

The problem is that I thought that the attacks were ordered chronologically, and that new attacks were guaranteed to add a new affliction if possible. In that case, the first attack above could yield LL, and the second attack would also yield LL (but not actually do anything). But in the second option (the one I understand), the first attack has to yield LL, in which case the second one has to yield RL because LL wouldn't be a new affliction.

So given this, I'd need to know the following:
- when does ordering of attacks (affliction sets) matter?
- what exactly does the ordering mean?
- is there any kind of chronological ordering of afflictions/attacks?

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Worstje Netherlands (899 posts)

bio

Date

Reply #36 on Thu 20 Dec 2007 12:21 AM (UTC)

Message

Sets do not have an order. It is why I am calling them sets and not lists. :)

(<RL, LL>, LL) is inherently redundant - you can not have your left leg broken twice. Therefore, (<RL>, LL) remains. But a 'choice' of one affliction essentially means that must be the only choice you can take, thus you are certain to have RL. A <> notation of one element is logically equivalent to the element without the <> around it.

I'll work out both scenario's, and for the matter of these examples I'll pretend the order -does- matter.

(<LL, RL>, LL): First we find out that someone breaks a leg. For example, you try to do something and find out you are limping which means that one of the two legs is broken. Then someone attacks you, and you get a message that your left leg breaks. Your left leg doesn't break twice, so the previous broken leg had to be de right leg. Thus follows (RL, LL).

(LL, <LL, RL>): I have broken my left leg, and I am aware of it. But before I can heal it, someone attacks me again and I get a message like "Your leg shrivels and withers away beneath you." which doesn't allow me to pinpoint which leg it is. But because I knew the other was already broken and that the attack WILL BE effective, it must be the right leg. Thus follows (LL, RL).

While the notation itself tries to avoid any thoughts about ordering, of course afflictions will come in a certain order. However, the beauty is that as time passes by, you learn more and more of your situation.

You eat a herbZ, but nothing is cured. Stuff cured by herbZ can be removed as choices.
You eat a herbZ, and 'slickness' is cured. If 'slickness' was available as a choice, we can identify one of the choices and push left over other choices with this option to keep logical integrity. Additionally, the 'slickness' being cured may imply we do not have another ailment because the herb is garantueed to cure paralysis before slickness. Thus if paralysis is an option in any choice, we can remove it there. Similar for if we actually think we have paralysis.

The system is self-correcting and in the process, allows the code to approximate a humans way of thinking by going for the most obvious things and striping away the things that are irrelevant. Even -if- the affliction tracker gets faulty information through illusions and such, it should deal with it as gracefully as possible and hopefully end up figuring out things are not possible without ever having tried to cure them. (Of course, this is not the only way I guard against illusions, but in case all other stuff fails, this is very important. Sadly illusions are becoming more undetectable and foolproofy by the day.)

Summary:

- when does ordering of attacks (affliction sets) matter?
In a given set, it does not. In live action, it should be self-correcting.
- what exactly does the ordering mean?
Nothing besides the fact that it makes it more readable that using a typewriter and writing all the words through eachother. :)
- is there any kind of chronological ordering of afflictions/attacks?
In the tracker itself: no. It just represents the CURRENT situation, which can be adjusted as more information becomes available.

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #37 on Thu 20 Dec 2007 04:12 AM (UTC)

Message

I think a lot of things make sense to me now... It seems that order is in fact crucial to improving the algorithm, because you never are presented with one giant set all at once that you have to simplify. You maintain a set of possibilities, that you refine over time as more information come in. (I don't like the term simplify because it suggests operating on a snapshot rather than an incremental change.) I think it's very confusing to talk about not having ordering because the algorithm really does operate chronologically: just look at how you explained it, for example.

Anyhow, I think the key in improving your algorithm will be in realizing that you only need to do work on the incrementals: there is no need to reprocess the entire set when new information comes in. You should only have to look at how that new information affects the existing uncertainties.

Have you given any thought to representing these as decision trees? It seems that could be promising. But again I need to think about this more, especially now that (I think) I have a better understanding of what exactly you mean with your notation and what exactly the problem is...

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Worstje Netherlands (899 posts)

bio

Date

Reply #38 on Tue 25 Dec 2007 12:10 PM (UTC)

Message

Crap, forgot to reply after I did some initial research on decision trees. I concluded that I have zero idea on how to implement those in this case.

I think I know how I can improve my current algorithm (Isthiriel has seen it) to exclude fruitless research that has been done in the past using lists of already-simplified-afflictionchoices, but it wouldn't be the prettiest thing on this side of the globe.

I appreciate any ideas you may have on this, David. :)

top

Posted by

Worstje Netherlands (899 posts)

bio

Date

Reply #39 on Wed 02 Jan 2008 11:11 PM (UTC)

Message

So I'm totally double-posting. Sue me, but my curiousity is getting the better of me. :) That and I hate it when I am stuck.

David, did you happen to come to any new realizations? And could you perhaps give me a good reference on decision trees (wikipedia isn't all that helpful to me) or perhaps an example of what you mean?

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #40 on Thu 10 Jan 2008 11:38 PM (UTC)

Message

Sorry for the big delay here -- I was away in Mexico for the break and just got back fairly recently; I haven't really had much time to think about all this. :-)

What you're trying to do is, I believe, a non-trivial problem in AI research, but I also believe it has been solved before. Basically it is the field of information update on a partial world view: you only know a subset of what is true, and worse, your knowledge is disjunctive; but, as new information comes in you can adjust your world view.

I have to context-switch back into what I was thinking before leaving to give you a good answer on what I meant by decision trees used in this context. But basically a decision tree is the following:

- At every node, you have a list of possibilities, i.e., decisions to make.
- Following a possibility (i.e. making a decision) puts you in a new decision node.
- After having exhausted the possibilities (i.e. running out of decisions) you know for sure where you are.

I believe that the book "AI: A Modern Approach" by Russell & Norvig provides a pretty good coverage of decision trees, but perhaps not in the correct context.

Again sorry for the delay and lack of useful information, give me a couple of days to think about this. It's a fairly fun puzzle to work through. :-)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #41 on Thu 10 Jan 2008 11:54 PM (UTC)

Message

Just mumbling here: it occurs to me that this kind of problem is very similar to classic problems solved by knowledge representation using modal logic. If you look up "Muddy Children" (probably on Wikipedia) you might see what I'm talking about. The idea is quite similar; you have a disjunctive view of the world, but as information comes in you can eliminate possibilities. That is almost exactly what you are trying to do here. I'll pursue this track and see what happens...

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Worstje Netherlands (899 posts)

bio

Date

Reply #42 on Fri 11 Jan 2008 12:47 AM (UTC)

Message

It's quite allright, I've been stuck and to be honest, I'm a horrible magician.. uhm, mathematician. They're my biggest obstacle in my Computer Science course, so I really appreciate any help I can get.

I just took a look at the Muddy Children problem (link: http://tcw2.ppsw.rug.nl/mas/LOK/lwb/muddy.html) and I think I can reason that one out in a rather simple way, although I admit I didn't go beyond k=3 since I'm tired and haven't got paper in front of me. I'd assume the mathematical side would be solvable using mathematical induction.. but I'm getting sidetracked. :D

I can see the comparison between the muddy children problem and my problem. I see two issues from the top of my head though.. first being that in unfortunate cases where the data is not proper (illusion snuck through or I didn't track a cure), it shouldn't fail. Second being that there is no real 'base' to start with nor a final 'gotcha' moment, but a continuously changing situation, of which the fact that an affliction is not certain to be able to calculated. But I'm talking in circles now I think, so I'm going to bed...

I hope Mexico was fun, andI hope you'll have a happy new year and all that stuff, too!

top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

96,635 views.

This is page 3, subject is 3 pages long: 1 2 3

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.