Discussions

eagle wrote:

As we have plugged in the computers, the computers have plugged into us!

I could turn it off if I wanted too.

John.

prog_dotnet wrote:

So to conclude;
Visual Basic has 11 control structures;
sequence, three types of selection and seven
types of repetition.
Each program is formed by combining as many of each type of control structure as is necessary.

For someone so keen to copy a page from Chapter One of "The Idiot's Guide to Learning Visual Basic for Dummies" I'm surprised to notice your over-zealous use of the semi-colon punctuation mark.

Perhaps we are meant to infer some relevance of your comments to this thread, based on the fact that the only control structure in the logic puzzle posted above is a jump?

Or did you really think that your comments were useful information, even though this is the year 2004 and this is a forum for programmers? Do you suppose we hadn't noticed? Perhaps in your next installment you can wax historical about object-oriented programming, recursive control structures, and functional paradigms.

How is it do you suppose that your control structures are implemented for your CPU by your compiler? Do you not suppose that the entire point of the question requiring the use of GOTO was to force a programmer to think about how a program might be implemented with serious limiting constraints on their ability to express their program?

In this case our 'virtual machine' has one bit of read-only state (i.e. non-program memory), which is either zero or one depending on if a parachute is on the track or not which is presumably read via some IO device. The only branching constructs are JMP (jump, AKA goto) and JZ (jump if zero), there were no specified constraints on the size of our program, although with such a constrained programming language any real-world counter part would likely (not exist anymore ) have a pretty hard limit on the size of the program itself (and probably be implemented directly in hardware, perhaps by hooking up the base, collector and emitter on a few transistors (with little black caps) to a handful of other primitive components).

I was really hoping someone would catch me on an off-by-one error, or take a shot at me for making a spelling mistake or flawed assertion (I spotted at least one already). I'm miffed at hearing about how Visual Basic has support for 11 control structures. I'm about as interested as I would be if you told me there were 26 characters in the English alphabet.

John.

OK, I tried to leave this alone, but I'm forced out of frustration to break my promise. It's a disease.

Firstly, it's not explicit in the instructions that STOP will terminate the program, although based on the example I assume this was implied. This is likely omitted since the STOP instruction seems to be nothing more than a red-herring. But I assume it will terminate the program rather than pause the car for one unit of time. It would be nice if STOP could be used to vary the rate of movement of the car and there was some method for determining efficiency (i.e. optimise for fast code, optimise for small code, optimise for car conservation of energy, etc.). Having stats of typical distances that cars might be separated when they land could help you come up with algorithms that were likely to be more efficient in the greatest proportion of likely cases.

Secondly, the language specification in the question states that each instruction takes one unit of time to execute. It states that the "number:" syntax is an instruction, so it will take one unit of time to evaluate a labelled statement prior to executing the statement it labels. This is bogus, so I ignored it when coming up with my last solution assuming it was a mistake in the specification. I also ignored the rule that states the "IF ON PARACHUTE" 'instruction' takes one unit of time to execute. Mostly I ignored this because it's not likely to be relevant in any real application (unless 'searching' to determine 'on parachute' required slow machinery perhaps). Anyway, I pretty much only considered that 'moving' would take time, however with respect to the rules as stated, this program will also work (and is more 'efficient', although no parameters for determining efficiency have been given it is typically safe to assume that acceleration has a cost. It is however less intuitive code):

1: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 2
   GOTO 1

2: MOVE RIGHT
   GOTO 2

Thirdly, I have also assumed that the parachute will only cover 'one foot' of ground evenly aligned with the 'points' on the track that the car can move to, such that a distance of one foot could be considered as a point on a line, and that if only one parachute existed on the line and 'on parachute' was true at point x then 'on parachute' was not true at point x-1 or x+1 and that each car was separated by a number of feet that was an integer. I also assume that IF ON PARACHUTE will return true regardless of 'whose' parachute is being tested, and that the parachute will be left at the same point that the car lands, such that 'on parachute' would be true from the first instruction. So like this if the cars land at P(3) and P(8) for example:

-|--|--|--|--|--|--|-
-3--4--5--6--7--8--9-
-P--------------P----

If the parachute might cover more distance on the track than one point, perhaps like this:

-|--|--|--|--|--|--|-
-3--4--5--6--7--8--9-
-[ PA ]-----[  PB  ]-

Then as long as there is guaranteed to be at least one point at which a car will test for 'on parachute' where the result will be false between parachutes and the cars are 'on parachute' when the program commences, then you'd need a program like this:

1: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 1

2: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 3
   GOTO 2

3: MOVE RIGHT
   GOTO 3

If it is possible that the cars land next to each other such that their parachutes overlap then they will move in the same direction at the same rate infinitely looking for the beginning of the next parachute. If however the absolute possible distance that a parachute might cover is known then a program can be written to accommodate the possibility of overlapping parachutes. If not, then I don't know how to solve the problem.

Assuming the known maximum distance that a parachute could cover was X feet (points on the line), then the maximum distance a car could travel from its landing position in any direction before 'on parachute' was false at least once would be 2X feet. I guess implicitly we are relying on 'Newtonian' concepts of time and motion, which are crude but likely to work well enough for our example (if not I don't want to play anymore!). The corresponding maximum amount of 'instruction' time until a car was definitely not on a parachute would be 4X-1, and the minimum time is 3 (based on the first part of the algorithm that moves the car right until it is not on a parachute using the timings as originally specified). In which case the following program will work for x=3, assuming cars at the same point at the same time constitutes collision (hey, it's worth stating, a collision might require an overlap, of might happen earlier (i.e. if the cars have width), but since we consider cars as at a point, even thought they are likely to have something greater than infinitely small width, 'at the same point' seems fair enough):

1: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 1

   MOVE LEFT
   MOVE RIGHT
   MOVE LEFT
   MOVE RIGHT
   MOVE LEFT
   MOVE RIGHT
   MOVE LEFT
   MOVE RIGHT
   MOVE LEFT
   MOVE RIGHT
   MOVE LEFT
   MOVE RIGHT

2: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 3
   GOTO 2

3: MOVE RIGHT
   GOTO 3

If 'on parachute' is not true when the program begins executing then the direction in which this can be assumed to be true will need to be specified or else the distance in which it is possible for it to be true will need to be known in addition to this distance being less than any possible distance that the cars could be apart from each other when they land.

If 'on parachute' is only true for the parachute dropped by the car doing the testing (i.e. the parachute that 'belongs' to that car) then I don't know how to solve the problem. If 'on parachute' is true for any parachute then you would have a problem if there was a parachute on the track that was not dropped by either of the two cars.

If it was exceedingly unlikely, but still possible that 'on parachute' was false at the start of the program and the direction of the parachute was unknown then the following program would still be effective in the face of a failure by exactly one car (assuming parachutes are at a point):

IF ON PARACHUTE
  GOTO 1
STOP

1: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 2
   GOTO 1

2: MOVE RIGHT
   GOTO 2

Or in the same situation this program would cause the cars to collide after less time:

IF ON PARACHUTE
  GOTO 1
GOTO 3

1: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 2
   GOTO 1

2: MOVE RIGHT
   GOTO 2

3: MOVE LEFT
   GOTO 3

That was fun. I'm sure it was worthwhile..

John.

You'd think I'd have something better to do on Sunday evening.. anyway, there's something about moving to a space to the right and not testing it that bothers me. I prefer this algorithm:

1: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 2
   MOVE LEFT
   MOVE RIGHT
   GOTO 1

2: MOVE RIGHT
   GOTO 2

The cars are likely to collide sooner with this algorithm anyway. I'm leaving it alone now. I promise..

John.

Bah! This one is better..

1: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 2
   MOVE RIGHT
   MOVE LEFT
   GOTO 1

2: MOVE RIGHT
   GOTO 2

John.

Or with a slight optimisation..

1: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 3

2: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 3
   MOVE RIGHT
   MOVE LEFT
   GOTO 2

3: MOVE RIGHT
   GOTO 3

John.

spod wrote:

Both cars must execute the same program, and must start executing the program at the same time. each instruction takes 1 unit of time to execute ( so the programs are clock-synchronised)

Write a program that makes the cars collide.

1: MOVE RIGHT
   IF ON PARACHUTE
     GOTO 2
   MOVE RIGHT
   IF ON PARACHUTE
     GOTO 2
   MOVE LEFT
   GOTO 1

2: MOVE RIGHT
   GOTO 2

John.

I think that's an awesome idea.

If Mono was done this way, I would have contributed by now. The SqlTypes implementation is a mess for example, System.Data.SqlTypes.SqlBinary being a good case in point since the Byte[] is not cloned, etc.

I could fix this for the world, if the barrier to entry didn't seem so high.. perhaps it's just open-source ignorance on my behalf.

Any Mono contributors lurking around here?

John.

I'm addicted to the large thumb button as 'alt-tab'. I can't function with out it. (There is a bug with it such that if I log on to my computer with terminal services then these mouse buttons die, and I have to reboot.)

I had to down-grade my mouse driver to get the functionality back, some *idiot* (I'm sorry, I can't even begin to be nice about this one) decided that the 'tab-like' feature should 'scroll through windows', rather than 'recall last window'. If you're like me, you have at least 20 windows open at a time, so something like that is useless.

I was ropable when this happened. Seriously. I almost had to find something that I could break.

I'm never upgrading my mouse driver again.

John.

p.s. Someone tell me that I'm wrong, and that the functionality was simply 'hidden'. Please. Otherwise, I too what to know WHO IS RESPONSIBLE!?

Prodev wrote:

Is there any truth to optimization of source code by white-space conservation?

If it's javascript or t-sql going over a wire then definitely.

I discovered yesterday that the SqlClient in ADO.NET uses spaces on each side of the equals sign for SqlParameters. I was miffed. Totally useless waste of bandwidth. The stuff is machine genereated, it shouldn't put the spaces in there IMO, I'd be interested to know why they did?

Sure, it's not a big deal. But it's still a waste. It doesn't even help improve legibility (to any significant degree) when profiling..

John.