loose equipment and ricochet fair batted ball

[youngump]

Originally Posted by ronald

Both cases above, Dave, ball is dead. In this sit, ball remains live.

You do programming and it is logic based. In addition, the sentence introduces a specific particular (ricochets) and an unmodified noun (equipment). Logically then, it means any and all, a universal not a particular (offensive or defensive). That is how I read it.

For you UIC's, what do you make of this?

I do programming myself, and it gets me into a lot of trouble when I try to read the rule book... that's why I always come here to get straightened out after I read it. There are plenty of rules in the book that simply don't mean what they say.
________
Medical marijuana card

[NCASAUmp]

Originally Posted by youngump

I do programming myself, and it gets me into a lot of trouble when I try to read the rule book... that's why I always come here to get straightened out after I read it. There are plenty of rules in the book that simply don't mean what they say.

Think of the rules as functions(), not one big main();

It'll make more sense if you think of it that way.

/geek;

[ronald]

Originally Posted by NCASAUmp

Think of the rules as functions(), not one big main();

Please explain or pm with explanation. Sounds interesting to me.

Thanks.

[NCASAUmp]

Originally Posted by ronald

Please explain or pm with explanation. Sounds interesting to me.

Thanks.

Oh man... That'd take a while.

In programming, you have different functions that will handle or evaluate certain tasks, and each function is read sequentially. First do this, then do that, then do the other thing. If your program is really short (and I do mean REALLY short), you'd probably have just one function called main(). All of your commands are in this one function, run in the exact order in which they're written down (like a repair manual).

However, these days, programs are never that short. As a result, you need to "break things up" in order to keep from re-writing the same thing over and over again. For example, if your program needs to display error messages under varying conditions, you'd write a function that handles this task and "call" that function when you need it. This is better than writing the code over and over again in the one long main() function.

So to a programmer, the best way to approach the rule book is NOT to look at it as one long, sequential document where everything follows the exact order laid out in the book (ie., one long main() function). The game is dynamic, and you need to treat it as such, calling up the various functions and subroutines as they come along.

You'd probably have about 1,000 separate functions.