I would like to change the following diagram to have a single decision node (three branches) and a single merge node.
Is such a diagram possible with plantuml? The above diagram results from this code:
#startuml
skinparam ConditionEndStyle diamond
:A;
if (case1) then (yes)
:B1;
else (no)
if (case 2) then (yes)
:B2;
else (no)
:B3;
endif
endif
:C;
#enduml
I know about elseif; it does not produce the result I seek. (It retains two decision nodes, and uses a bar instead of a merge node; is this even valid UML?) I would reluctantly consider a ConditionalNode as an alternative, but I don't see a way to construct one in plantuml.
This could work with the switch conditional:
#startuml
:A;
switch (test?)
case (case1)
:B1;
case (case 2)
:B2;
case (else)
:B3;
endswitch
:C;
#enduml
Related
I am using NetLogo to create a simulation modelling bees visiting flowers and pollinating them. To understand genetic diversity I'd like each turtle to record the location of a flower it visits, every time it visits one. This means I then know the last recorded flower could have been pollinated by any of the flowers above it in the generated list. I have modelled the flowers as yellow patches that are generated randomly, they turn blue once a bee has collected pollen from them and then white if a bee has pollinated them, although this only happens if they have been visited when the bee has enough pollen to pollinate.
This information would also be needed to clearly be individual to each turtle. My hope would be if after running it could generate a file with each turtle and a list underneath them of the locations of flowers they visited in sequential order.
I imagined it working by every time a bee visits a flower it stores the x and y coordinate of that flower.
to store-location
ask turtles [
if ((pcolor = yellow) or (pcolor = blue) or (pcolor = white))
set xy_list fput (list int xcor int ycor) xy_list
]
]
end
I haven't tested this, but it looks almost correct to me. In fact, I am surprised it didn't work (you didn't explain the problem). But instead of:
set xy_list fput (list int xcor int ycor) xy_list
have
set xy_list fput patch-here xy_list
Your approach of putting a new entry in the list is fine. But the way you have it will give you lists of lists. Instead, you can store the patch (so you don't need to take int) and then you will have a single level list with items like patch 1 4 which will be easier to read later.
Then, when the run is complete, you can write the lists to a file. If you need help with that bit, please ask a separate question.
I read somewhere that the switch statement uses "Binary Search" or some sorting techniques to exactly choose the correct case and this increases its performance compared to else-if ladder.
And also if we give the case in order does the switch work faster? is it so? Can you add your valuable suggestions on this?
We discussed here about the same and planned to post as a question.
It's actually up to the compiler how a switch statement is realized in code.
However, my understanding is that when it's suitable (that is, relatively dense cases), a jump table is used.
That would mean that something like:
switch(i) {
case 0: doZero(); break;
case 1: doOne();
case 2: doTwo(); break;
default: doDefault();
}
Would end up getting compiled to something like (horrible pseudo-assembler, but it should be clear, I hope).
load i into REG
compare REG to 2
if greater, jmp to DEFAULT
compare REG to 0
if less jmp to DEFAULT
jmp to table[REG]
data table
ZERO
ONE
TWO
end data
ZERO: call doZero
jmp END
ONE: call doOne
TWO: call doTwo
jmp END
DEFAULT: call doDefault
END:
If that's not the case, there are other possible implementations that allow for some extent of "better than a a sequence of conditionals".
How swtich is implemented depends on what values you have. For values that are close in range, the compiler will generally generate a jump table. If the values are far apart, it will generate a linked branch, using something like a binary search to find the right value.
The order of the switch statements as such doesn't matter, it will do the same thing whether you have the order in ascending, descending or random order - do what makes most sense with regard to what you want to do.
If nothing else, switch is usually a lot easier to read than an if-else sequence.
On some googling I found some interestin link and planned to post as an answer to my question.
http://www.codeproject.com/Articles/100473/Something-You-May-Not-Know-About-the-Switch-Statem
Comments are welcome..
Although it can be implemented as several ways it depends on how the language designer wants to implement it.
One possible efficient way is to use Hash Maps
Map every condition (usually integer) to the corresponding expression to be evaluated followed by a jump statement.
Other solutions also might work as often switch has finite conditions but a efficient solution shall be to use Hash map
I was thinking about implementing the classical river crossing puzzle game and I was wondering what would be the most appropriate search algorithm to solve it.
Here is an example of the game
Apparently there is enough information to predict the distance from the current state to the goal, so a heuristic search could be used. Going through the different states I found a case where the search can enter an endless loop.
Here is the case:
On the left side of the river there are two creatures (one of both kinds)
On the right side of the river there are four creatures (two of both kinds)
The boat is on the right side
There are 2 legal moves:
return two munchkins (those who should not be outnumbered by the others) this will cause a loop
return two creatures (1 of both kinds) this is the move that should be taken
Is the usage of informed search better in this case? What would be the appropriate type of heuristic i.e Hill Climbing, A*
What would be the best way to go through that looping.
I am trying to implement some form of AI into my Net Logo game.
I am planning on calculating the Manhattan distance from a zombie turtle to a human turtle.
So far I have managed to calculate the Manhattan distance from the two and draw the path and also move the zombie agent along the calculated path towards the human turtle.
The problem I am facing now is that the human agents location is going to be controlled by the user. The Manhattan distance uses a while loop and doesn't break out of the loop until the it has reached the human agent. I would like the zombie agent to move one step towards the human agent and then let the human agent move.
Code so far Net Logo Game
I am not sure what you are trying to do in your plot-manhattan-distance procedure. It seems like a complicated approach to something that should be relatively simple, but maybe I misunderstood your purpose. Here is how I would approach the whole problem:
globals [
zombie
human
]
to setup
clear-all
ask n-of 2 patches [ sprout 1 ]
set human turtle 0
ask human [ set shape "person" ]
set zombie turtle 1
ask zombie [ pen-down ]
end
to go
ask human [ flee zombie ]
ask zombie [ pursue human ]
end
to pursue [ target ]
face target
set heading first sort-by [abs (?1 - heading) < abs (?2 - heading)] [0 90 180 270]
fd 1
end
to flee [ pursuer ]
face pursuer
rt 180
fd 0.5
end
The meat is in the pursue procedure. Since the zombie cannot predict where the human is going to go, it is just trying to move in its general direction. It starts by facing the human directly (with the handy NetLogo face primitive). But since it is presumably only allowed to move in one of the four cardinal directions, it must choose the one that is the most desirable, i.e.: the one that is the least different from its current (ideal) heading. This is what the sort-by [abs (?1 - heading) < abs (?2 - heading)] [0 90 180 270] expression does: it sorts the list of directions by comparing their absolute difference with the current heading. The first item of this sorted list will be the one with the smallest difference, and thus, the one that the zombie needs to use.
In the current implementation, the human just tries to move away from the zombie, but you could easily replace that with player control code.
I have the following review question for my upcoming exam that I would like to have some help with. I have to answer the query "Mary only uses green apples to make pies" using resolution. My current knowledge base and language is the following sentences:
Mary only uses apples from John to make pies:
∀π,a(Apple(a) ∧ Pie(π) ∧ Make(M,π,a) => Grows(J,a))
(⌐Apple(a) V ⌐Pie(π) V ⌐Make(M, π, a) V Grows(J,a)) (in CNF)
Latest update:
I will try to be more specific in general. The thing I want to prove is "Mary only uses green apples to make pies".
Writing this logic I get:
Mary only uses green apples to make pies:
π,a Pie(π) A Make(M, π, a) => Green(a)
And the steps in translating it into CNF form (http://en.wikipedia.org/wiki/Conjunctive_normal_form):
π,a ⌐(Pie(π) A Make(M, π, a)) V Green(a)
π,a (⌐Pie(π) V ⌐Make(M, π, a)) V Green(a)
(⌐Pie(π) V ⌐Make(M, π, a)) V Green(a)
⌐Pie(π) V ⌐Make(M, π, a) V Green(a) (CNF form)
Negation of this statement in CNF form (Which we will use in the resolution for the proof):
Pie(π) A Make(M, π, a) A ⌐Green(a)
Now when using resolution for first order logic :(http://en.wikipedia.org/wiki/Resolution_(logic))
Is this right!? Or am I getting it wrong?
I'm not sure you're approaching the problem correctly. The first step is to encode the three statements ("Apples are either green or red", "John only grows green apples", "Mary only uses apples from John to make pies") into clausal form, which you haven't done.
The second step is to encode the negation of the statement you are trying to prove ("Mary only uses green apples to make pies") into clausal form as well. I don't think you've done that, I think you've encoded the positive statement. Perhaps I'm missing something. But encoding the query statement's negation ends up with four short statement strung together with ANDs, each of which can be treated as a statement in the knowledge base.
From there, the reduction is mechanical.
Update: Once again, you need to add the negation of the statement you are trying to prove. You're not doing that, you're adding the statement itself and another statement about the apples being green. Don't do that. You're not trying to prove a statement about the apples being green, you're trying to prove a statement about Mary only using green apples to make a pie. Negate that statement, resolve it with your three other knowledge base statements, and extract a contradiction (which is to say, resolve X and not-X together for some statement X.)
That is the algorithm. It works. If you don't do that, whether or not you "need" to, you're doing something other than the resolution algorithm, and were I grading your homework/exam, I'd grade it as incorrect.
Update 2: You're getting closer, but your query statement needs an additional clause about a being an Apple (i.e., Apple(a)) as several of your other statements already have. It should look almost exactly like the statement about Mary only using John's apples (and then negated because it is the query.) The form of it is correct, with the small clauses strung together with AND's, you're just missing one.
But then notice that once you do have that, each of those small clauses (because they are strung together with AND's) can act as an independent statement in your Knowledge Base. So for instance, the way you've formulated it right now, you could resolve Pie(p) with the expression for your third statement. There are a lot of steps in the resolution proof, but once you completely encode the query-negation, they are all tiny steps like that.
As a general information, you need to have your knowledge base in CNF, and a NEGATED goal (also in CNF). Then by unifying and applying resolution either you need to have a nil resolvent or the goal state itself. Other option is not being able to find any of these and resolve infinitely.
If
Make(p,π,a)
is in your knowledge base, then unifying and applying resolution it with the last resolvent which is:
⌐Make(M,π,a)
gives you a nil resolvent. At this point you can stop and conclude.