[MUD-Dev] Let's talk about numbers.

[Jon A. Lambert]

On 24 Sep 98, Brandon J. Rickman wrote:
> On Thu, 24 Sep 1998, Jon A. Lambert wrote:
> > On 23 Sep 98, Adam J. Thornton wrote:
> > > There's a great maxim from somewhere that I can't remember: there
> > > are only three interesting numbers: zero, one, and
> > > infinity-defined-as-the-largest- number-your-machine-can-deal-with. 
> > > I've found it's usually a good maxim to apply: either you can't have
> > > something, you can have one of it, or I'll try to allocate space for
> > > it for you and let you know if I can't.
> > 
> > ...
> > I agree,  we should always attempt an implementation  in terms 0, 1 
> > and many(unknown/infinity/X).  There are exceptions and instances 
> > where we must pay homage at some level to the failings of our 
> > silicon, but these should be rare and abstracted if possible.   
> 
> This is silly.

No it's not.  :)
 
> Okay, say there are 3 interesting numbers: Zero, One, and Many. 
> Since 3 is not interesting we should call it Many.  There are Many
> interesting numbers.  Or there are 4 interesting numbers: Zero, One,
> 3, and Many.
> 
> You are advocating a very rigid and inhumane programming practice. 

Is it?   Assume you are designing a mud and you decide upon modeling 
3 stats.   Your mud has been running for about a month and you've hit 
upon some good ideas and desire to extend your design to model 2 
additional stats.  If your implementation has assumed 'many' as 
opposed to '3' is it more easily modified?   Does this mean your 
original design was bad because you failed to originally document the 
need for the 2 additional stats, or good because you were able to 
modify your design because your implementation assumed extensibility?

> Some thought should go into how numbers are important to the game,
> not to the CPU.  Player stats ranging into the thousands would be
> irritating, stats in the millions incomprehensible.  A player
> walking around with 2^31 coins in her pocket is still a bug, even if
> the code is bulletproof.

I'm not saying that assuming 'many' is to assume 'infinity' nor the 
limits of the CPU.  I probably shouldn't have parenthesized 
'infinity'.   Although it can't be discounted as a possibility in 
some scientific applications.  Yes there are often damn good reasons 
to impose limitations on 'many' in order to catch errors.  A string 
that expands to 1 megabyte may be an error.  Then again, it might 
also be a .jpeg file.  And there are often times when it is good 
practice to make an astract data type that exceeds the limitations of 
you CPU.  A 64-bit integer class on a 32-bit machine for instance.  
Later the class can be easily replaced by a true 64-bit integer.  
Depending upon bit flags and bit masks is another problem.  Look at 
my object-wear model on my web pages for an outstanding example of 
bad design.  (My only defense is that it was designed to be 
integrated into a server whose design was already shot to hell with 
magic-numbers ).

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--