Newsgroups: rec.arts.int-fiction
Path: nntp.gmd.de!Dortmund.Germany.EU.net!Germany.EU.net!wizard.pn.com!mozo.cc.purdue.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!freenet.columbus.oh.us!pacific.mps.ohio-state.edu!math.ohio-state.edu!howland.erols.net!netcom.com!erkyrath
From: erkyrath@netcom.com (Andrew Plotkin)
Subject: Re: [Z-machine] Divison and modulo
Message-ID: <erkyrathDyIuHu.8y2@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <VA.0000000c.00320a5b@104312.2206>
Date: Mon, 30 Sep 1996 01:22:42 GMT
Lines: 69
Sender: erkyrath@netcom20.netcom.com

Bryan Scattergood (104312.2206@compuserve.com) wrote:
> Okay.  After picking through the messages in this thread which made it 
> through the wretched CompuServe news gateway, let me check that I've got 
> this straight.  When doing division and remainder *in* *the* 
> *Z-machine*, everyone agrees that the property

>     b!=0 => (a/b)*b + a%b == a

> ought to hold. 

This property is guaranteed in C and C++, so it certainly should carry 
over to Inform. Since (as you later infer) the % and * operators 
currently map straight to the @MOD and @DIV opcodes, it's easiest to do 
it at the Z-machine level as well.

> Now, when b>0 there are two reasonable approaches

> 1. Round towards zero.  Then sgn(a%b)==sgn(a).

> 2. Positive remainder so that 0 <= a%b < b.

> From the comments so far I guess that LH requires (1) to function 
> correctly and that many people believe that (2) is a useful property 
> (this is not an uncommon position; I've had to change the semantics of a 
> language I designed because users demanded this property there.)

> In this case I'd agree with Andrew that if genuine Infocom games need 
> it, then we can't do anything about this at the Z-machine level and we 
> have to stick with (1).

It's nice to have the paralysis of tradition on your side. :) 

> Now, some people have argued that when implementing the corresponding 
> opcode in an interpreter, this means that we can simply use

>     (signed) a % (signed) b
>     
> on the grounds that C then gives the answer required by (1).  While this 
> is common, it is not required by the ANSI standard.  

Correct.

> In general, the only way to fix this is to make the code for that 
> Z-machine operation more complicated to patch round the problem or be 
> prepared for nasty portability problems.

Mostly correct. I can ignore the problem on the Mac, because I know the
behavior of the CPU and the behavior of my compiler, and I'm not
(primarily) distributing source code. On XZip, in contrast, I should
definitely make the interpreter code more complex. (You'll note that I
didn't do that in 1.5. Shame on me.)

> This also raises the nasty question of what happens for b<0. 

In the C world, the commonest rule is that (a / b) == (-a / -b), and 
therefore (a % b) == -(-a % -b). Again, this descends from the behavior 
of the integer division operation on most CPUs out there. I think.

> This could 
> be one of those nasty areas where Infocom interpreters implement 
> something, but none of their games rely on it.  I'm tempted to leave 
> that one to those with more experience disassembling the original 
> interpreters and games.

--Z
-- 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
