Prime

In BNF, the syntax of VNA could be defined as following: Argument ::= Number | Function Function ::= FunctionName, (, ArgList, ) Arglist ::= Argument, [, Arglist] Following this model I wrote a parser in VBA in Excel. I include here the following routines: 1). VNA() -- macro used to test parsing. On Excel worksheet put Location numbers from 0 to 199 in column 1 (optional); Command name in column 2 (optional); arguments a, b, and c into columns 3, 4, and 5. Select (bring in focus) an argument you want to parse and run the VNA macro. It should print resulting evaluation for argument "a" in column 7 on the same line, if you selected "b" in column 4, result will be in column 8; for "c" the result of parsing would appear in column 9, and column 10 will have an error message should an error occur. 2). Parse() -- recursive function for parsing arguments. 3). c_arg() -- recursive function for evaluating VNA functions a(x), b(x), and c(x) 4). p_add() -- recursive function for evaluating VNA fucntion add(x,y) To save space, I do not include other VNA function implementations, since they are very similar to c_arg() and p_add(). VNA driver executing commands and moving pointers together with user interface and utilities could be developed separately in accordance with personal taste. I am planning on doing it as an exercise to brush up my Excel programming skills.

I say... Hasn't Professor any water at home? Per Bonanova's calculations, the distance they traveled from their stop to water is only slightly shorter than the distance from that rest point to home. (It's something like 7 km vs. 9 km.) And if the horse refuses to go in any other direction, but towards the water, wouldn't it also insist on taking the shortest path to the river?

Obviously, he died from exhaustion while trying to decipher the message.

Don't beat yourself up too hard. Such things are in the nature of computer programming. My SHIFT statement has less levels of indirection than your test case. It simply refers to b(-2), which, in turn, has a simple arithmetic expression in it. Maybe, there is something wrong specifically with the "b" argument resolving. I ran few matches in FOTH's emulator and was gratified to see that the "repair" mode saved Fish3 on several occasions. Even twice in one of the matches. It beat Awesome 3 times out of 4. However, Flawless beats Fish3 consistently. Fish3 does not do well against a program that moves around, it has several serious weaknesses. E.g. an opponent could hide inside Fish3's 40-node body and be forever safe. I am going to try my Fish2 version, which is also a hopper. When I tried to load Pinguin Bomber also included with FOTH's emulator, the emulator crashed on "Reset Array" button press. There appears to be an invalid/unresolved reference in the statement: .Names("prog_" & .Names("Player2").RefersToRange.Value).RefersToRange.Copy in the CommandButton2_Click() Sub.

I don't think Excel could be blamed for not being able to handle the statement as above. It is up to your implementation of the "equ" function. Traditionally, interpreters have a recursive structure themselves, resolving references as they go. Your emulator resolves the arguments for the "equ" before it calls it: Public Function equ(a As Double, b As Double, c As Double, d As Double) As Double If a = b Then equ = c Else equ = d End Function To handle an equ statement as that, the implementation of the equ function could be something like: Public Function equ(equ_parms As String) As Double Dim a, b, c, d As String a = parm(1, eq_parms) b = parm(2, eq_parms) c = parm(3, eq_parms) d = parm(4, eq_parms) If resolve(a) = resolve(b) Then equ = resolve( c) Else equ = resolve(d) End Function Where "resolve()" is another function, which resolves the reference, and "parm()" is a function which separates equ's arguments delimited by commas.

I think this is great! I downloaded your emulator to my laptop. Now we can test and train programs before sending them into battle. It is just as well that Excell cannot handle circular references. They should be illegal. There is no way to detect all of them programmatically, so what we could do is to set some limit for nesting. When you do parsing, your functions could keep track of how "deep" nesting is and return an error if it is greater than some preset number, say 40. Spreadsheet format accomodates well for VNA commands. Maybe, we can do away with ";" delimeters? Just enter command name into one cell, argument a, into the next, then b, then c. I did not send anything to FOTH. The version he ran is the one that you published here. I did not go through FOTH's emulator code, but could see nothing wrong thus far with its operation. On the other hand, I am still curious, why Fish3 went astray on UR's emulator. Perhaps, you could step through it and see what causes it to branch out into "repair" mode.

This number system does not look consistent, somehow. What would be 12*2, and 12*3 in it? What would be 36 - 5?

The answer looks reasonable but the base is wrong.

Actually, it does. It copies those lines into the location where the SPAWN command creates a new independent pointer. The latter will take on the life of its own and proceed to bomb its parent. Also, after 9 itterations or so of the main program, the spawned program would land right on top of the parent program if it were alive at that point.

My reasoning for the average distance between two random points is similar to that already posted here. However, I am going to show it anyway, since I think it may help to solve the distance between two points in a circle problem. And, in time, the original problem in the OP. From this we could move to constructing a similar solution for the distance between two points in a circle. And from there to the original problem -- distance between a random segment in a circle and anohter random point. From which we could find triangles' area and thus the probability of the 4th random point falling inside it.

But then I don't see why my program would leave its normal loop and go into repair loop, unless it got bombed. The only bug I could see is the one you pointed out, in the repair loop, where I put an offset -6 instead of -7.

Your program (for #1) is a two-step process, which 1) copies itself 2) Erases itself and jumps to new location. Mine: 1) erases its old copy left 70 paces behind; 2) Copies itself to new location and jumps. First, I came up with the solution identical to yours, but then opted for the second variation as it seems to be better in a combat situation. Why: After the program copies itself in the first step, it has two points of vulnerability: 1) The same location where it is going to execute its second step, and 2) The location where its new copy resides and where it plans to jump in another step. Whereas second variation has only one point of vulnerability at all times -- the location it is going to execute on the very next step. Your comment with respect to #4 solution duly noted. I forgot to protect the bomb. However, here is another way to take care of it simply: SHIFT 3;-3;0 BLANK BLANK BOMB 0;0;0

#4 is easy. #5: There is no need for "Rand" function.

The following is most likely to do what #1 assignment requires in just one statement, as long as there is no accidentally matching parameter somehwere. So, no guaranty. If I got it right, it is a puzzle in itself to see why and how it works. I'll hold off on the explanation for now. With that I am giving away a special and very useful technique implicit in SHIFT command. That technique, I think, was mostly unnoticed till now. In return, I expect UR to look into my post in the VNA topic in the "Games" forum and answer it. The program with the SPAWN will obviously bomb itself soon enough. I would hold off on implementing that command for now. As a side note, most people on this forum don't even know what we are discussing here. For that matter, shouldn't this puzzle be in the Games forum?

That's not what I meant. Given the following code segment: EDITC x;mod(add(c(0),17),160);x PCOPY ... SHIFT equ(b(-2),mod(add(c(-2),17),160),true,false);x;x The "equ" statement in the SHIFT command must always evaluate to true, since it compares the "b" argument of the EDITC command with the expression which is equivalent to the one found in that argument and refers to the same input data. My understanding of the interpreter is that it evaluates b(-2) using the formula residing in the b(-2), then it evaluates the expression mod(add(c(-2),17),160) and finding the result to be equal (and it cannot be otherwise), returns "true". If it was not so, that would mess up my program. Other than that I can't see why it would leave its loop and go into the repair mode. Can you test whether that comparison in the SHIFT statement returns false? Because, if it does -- that would be the VNA Emulator's bug.

The lighter object will fall behind at all times. Consider 10 kg object and 2 kg object. Both start falling with acceleration 9.8 m/sec2. Say, at some speed V, the drag force is 9.8 kg*m/sec2, which only depends on the object shape and speed. At that point the total force acting on the 2 kg object is only half of the initial gravitational force. The total force acting upon 10 kg object is 0.9 of its gravitational attraction. Thus the 2 kg object accelerates at 4.9 m/sec2 at that point and the 10 kg object accelerates at approx. 8.8 m/sec2.

I don't see why. The program is supposed to loop endlessly in the three statements: EDITC 0;mod(add(c(0),17),160);0 PCOPY -2;add(c(-1),10);10 SHIFT equ(b(-2),mod(add(c(-2),17),160),equ(c(-1),10,1,4),3); equ(b(-2),mod(add(c(-2),17),160),equ(c(-1),10,mul(-1,add(c(-2),32)),-1),-2); equ(b(-2),mod(add(c(-2),17),160),equ(c(-1),10,-2,6),6) Unless it detected damage to itself. Then it should go into repair mode and return. Unless I don't understand something about VNA. I expect that the expression in the SHIFT statment: ... mod(add(c(-2),17),160) ... would evaluate to the same thing as the "b" parameter in the EDIT statement two lines prior: EDITC 0;mod(add(c(0),17),160);x regardles of the value of "x". I don't see why there aren't many draws. If programs move about and repair the damage, they could chase each other for a long time, not necessarily forever. Simply covering the entire field with bombs should not be enough to catch a good program.

I am not sure I understand your point. In presence of significant air resistance (drag) the heavier object will fall faster than the lighter object of the same shape. Take a large coin and cut out an identical shape from a piece of Styrofoam. Drop them from the same height at the same time and observe. Force of gravitational attraction is directly proportional to the mass of the object. F = mg, where acceleration constant g = 9.8 m/sec2. In the absence of air resistance, the objects fall at the same rate (increase in attraction force being cancelled by the increase in mass g = F/m). However, it would take proportionally smaller drag force to negate gravitational attraction and reach its terminal velocity for the lighter object. In other words, while the drag force is the same for the identical shape objects moving at the same speed, smaller force is required to stop lighter object’s acceleration.

There is a bug in my program. The third line from the end should be: SHIFT equ(c(-7),10,-1,-2);equ(c(-7),10,-6,-7);equ(c(-7),10,-6,0) Without testing, it's hard to make a program of some complexity to run on the first try. That said, I don't quite see why it could not compete as is, unless there is another bug somewhere in the program. That line should never have been executed, unless the program "sensed" it was corrupted (bombed). That statement was meant to fix the damage. If it failed to mend the damage, it simply tries to survive by looping on the same instruction. If the opponent failed to find and bomb it in a reasonable time -- that's a draw! A draw seems like a very legitimate outcome. A pointer may get lost and wind up executing the opponents program. Or both programs can end up in a cycle, where they cannot kill one another. It seems the tournament has revealed some areas for improvement of its format. Consider the following suggestions: 1. Set a limit for the length of each fight. Say, after 5000 steps if both pointers are still alive -- then it's a draw. 2. As I suggested before, there is no need for determining the winner between every two contestants. A tie should be perfectly acceptable. Let's say a match between two contestants consists of 2 rounds 2 games each. (One round: get random positions, let them fight (one game), swap the positions and the first move and let them fight again.) For each program an outcome of a single game could be: loss = 0 points, draw (both survived after 5000 steps) = 1 point; win (the opponent exploded) = 2 points. In the end just add up all points for each program and see who the winner is. That should save a lot of time. This game is fun. If I find the time, maybe, I'll write my own VNA interpreter, so that I can test my "Fishes" before sending them to fight.

Assuming the players are in a single line like 1,2,3,4,5, for example. Where 1 can only shoot at 2, 5 can only shoot at 4, whereas the rest of them have a choice of 2 people to shoot at. Also, assuming that shooting in the air is not allowed -- a player must shoot at someone other than him/herself on their turn. The solution could be as following: There may be a number of other solutions with different arrangements of shooting turn. This is a very good logical problem. But it is too violent.

Thanks for clarifying the terminology. I included your post into my previous post as a reference to the only solution provided thus far and not as a criticism. Also, my intention was to disambiguate the statement of the problem. If my comments and testing of the solutions and statements of problems are perceived as offensive and some kind of personal attacks -- that could discourage me from questioning/analyzing other people’s puzzles in future, rather than change my manner of expression. I still think that 3 points on the perimeter, 1 inside and 4 points anywhere inside the circle -- are two different problems. Both seem difficult. So let me state another problem yet, which seems related, yet simpler: Corollary Problem: What is the average distance between two random points inside a circle of a given radius?

To clarify: When I said "bike", I meant motorcycle, of course. No one goes 70 mph on a bicycle. Professional bicycle racers average around 30 mph over the short distances in time trials. I have a windshield which reaches about to my chin. Without that I used to get tired of the wind hitting in my chest over the longer trips. At 75 mph or more the wind noticeably pushes my head back. And, if I don't wear a helmet, my cheeks pull back and flap in the wind. That looks ridiculous, so I usually wear a 3/4 helmet with shield, if I plan to go fast. In case of a falling coin, when it has its edge pointing to the ground, the wind resistance is less. When it's face pointing down, the wind resistance is more. The difference in weight between fake coin and the gold one being small, the number of flips and position of the falling coin is going to be the deciding factor. I got an impression (maybe wrong) that some posters here beleived that heavier objects fall faster in the absence of the friction/air resistance. That is not what I was brought up to believe.

I am going to pick an issue with dropping coins down the elevator shaft. It is wrong on many levels. The 10-story elevator shaft is about 30 meters deep. Neglecting the air resistance the dropped coin would accelerate to approximately 24 m/sec before hitting the ground. (That is using d = gt2/2 formula I've been believing in for so many years. Where g=9.8m/sec2). That's like 87 km/hr, or less than 55 miles/hr. And that's the top speed at the very end of the fall. When I am on my bike, the wind does not bother me until about 70 mi/hr, or 110 km/hr. And gold coin's weight to its surface area ratio is so much greater than mine. Those coins are not going to notice any air resistance from such small height and will take same amount of time to fall. You are not going to see any appreciable difference. And if you could measure any time difference, it still would be inconclusive, since you cannot account for how many flips in the air the coin made before hitting the ground. The bike analogy is the best I can do, since I never got around to learn how to calculate air resistance. More importantly, how are you going to dig the coins out from the elevator shaft afterwards? If some coins end up missing, you'd be held accountable.

I don't think that the case where some points are on the perimeter of the circle need to be considered at all. The OP stated circle, not circumference. The probability for 3 random points to land exactly on the perimeter is zero (since the area of the perimeter is zero, mathematically speaking). Also, was there any special check when placing the points inside the circle to ensure they didn't land on the perimeter? So, I'll go with your first experiment of .926. And I'm still not up to finding the answer analytically. So I'll settle for this numeric solution.

If I understood this problem right… So, all that seems too complicated. Perhaps, Bonanova could run his simulation software to make an estimate of the probability. Where did this problem come from? I’m curious.