[Gm2] div mod / rem

[Gaius Mulley]

Hi,

I'm forwarding this email to the list as was intended by
Michel and myself,

regards,
Gaius

From: Michel De Rosa
Subject: Re: [Gm2] logitech lib problems
To: Gaius Mulley
Date: Sun, 11 Sep 2005 02:29:11 -0400

On Fri, 2005-09-09 at 12:21 +0100, Gaius Mulley wrote:
> Michel De Rosa  writes:
> 
> > On Thu, 2005-09-08 at 11:22 +0100, Gaius Mulley wrote:
> > > Hi John and fellow gm2 people,
> > 
> > Hello Gaius and gm2ers.
> > 
> > > thanks for the reports, I've fixed the bug in
> > > gm2/gm2-libs/StringConvert.mod. However the bug has raised an
> > > important question, namely that of DIV, MOD with negative values.
> > > 
> > > I'm sure this has been documented elsewhere, numerous times, but this
> > > is the first time I've been bitten by this bug feature :-) Basically
> > > it appears that:
> > > 
> > > 
> > >         -31 DIV 10     -31 MOD 10
> > > 
> > > PIM2     -3            undefined    P24 of PIM2
> > > PIM3     -3            undefined    P27 of PIM3
> > > PIM4     -4            9            P29 of PIM4
> > > ISO      -4            9            P201 of ISO
> > > 
> > > 
> > > I propose that the compile time -Wpim2, -Wpim3, -Wpim4, -Wiso switches
> > > effect code generation to comply with the table above. And introducing
> > > -Wmodulus (or suitable name) which generates a runtime warning about
> > > negative modulus operands for PIM2 and PIM3. Is this generally
> > > acceptable?
> > > 
> > > It does mean we have to be careful which switches we use when are
> > > compiling legacy code. I guess the default behaviour should map onto
> > > PIM4 and ISO. Again has anyone strong opinions about this?
> > > 
> > 
> > Oh my.. nice can of worms that's just been opened there :)
> > 
> > This is even worse when we consider ISO's addition of / and REM for
> > whole numbers *and* the fact that the ISO standard (at least the
> > draft i've been reading) considers it an exception to use a negative
> > divisor for the DIV and MOD operators (whereas all the PIMs allow
> > them).
> > 
> > Now i've been going over various books on Modula-2, that predate
> > pim4 (and therefore ISO), and it seems generally accepted that
> > the following assertion hold true:
> > 
> >    lval = (rval*(lval DIV rval)) + (lval MOD rval)
> > 
> > Most Pim3 compilers i worked with (logitech, jpi, fst) would yield
> > remainders of -1, for -31 MOD 10.
> > 
> > Things get a little more interesting when the divisor is negative (or
> > both operands are negative).
> > 
> >                      Pim2/3          Pim4                ISO
> >                   -----------    -----------    ----------------------
> >    lval    rval   DIV     MOD    DIV     MOD    DIV    MOD    /    REM
> >     31      10      3       1      3       1      3      1     3     1
> >    -31      10     -3      -1     -4       9     -4      9    -3    -1
> >     31     -10     -3       1     -3       1     Exception    -3     1
> >    -31     -10      3      -1      4       9     Exception     3    -1
> > 
> > It is, however, interesting to note that, while not specifically defined
> > in pim2/3, the behaviour of it's div/mod (as typically implemented by
> > compiler vendors) matches that of ISO's / and REM operators..
> 
> Hi,
> 
> Thanks for taking the time to categories the complete range of
> operators and standards..

Hehe actually i realise *now* that the reply never went to the list, but
instead was sent to you directly *sigh* my intent was, of course, to
make sure we where all on a level ground, to discuss this :)

Along the same lines, it'd probably be usefull to mention the
constraints on the returned values for the different operators.

  rval = 0, will always raise an exception (or cause a program
  to halt), when used with DIV, MOD, / and REM.

  for DIV and MOD, i don't think either pim2 or pim3 place any
  specific constraints, except that the results be in range for
  the datatype being used. The same constrainst as those used
  for ISO's / and REM would seem to work well, as far as
  implementing pim2/pim3's version of DIV and MOD.

  PIM4 doesn't specifically specify constraints for the result
  of DIV, but MOD's result must be a number in the range:
     0 <= result < rval
  This obviously makes any negative rval illegal. It also,
  means that the result of DIV, must be such that the assertion
  stated earlier, is true..

  ISO, for DIV and MOD, the conditions for valid results are the
  same as for PIM4, however ISO does not allow negative rval values,
  so rval must be a number greater then 0.

  For / and REM, the results (quotient and remainder respectively) are
  such that the following holds true:
      lval = rval * quotient + remainder
  And the remainder will be 0 or an integer of the same
  sign as lval, and who's absolute value is smaller then the 
  absolute value of rval. i.e.
      0 <= ABS(remainder) < ABS(rval)

> How about the -Wpim2, -Wpim3, -Wpim4, -Wiso flags obey each
> standard according to their respective definitions. But users may
> override with:
> 
Right hehe i think we agree, and i suspect most others would, that
specifying -Wpim2 etc.. without any other 'overrides', should yield
results according to their respective definitions.Tho as i've hinted,
MOD, in pim2 and pim3's cases would tend to yield the same results
as if we had used REM, under ISO, assuming we also make it so DIV
behaves as ISO's / in this case.. which is what pim2/pim3 seem to
hint at (well it's what i assume, i don't have copies of pim 2 or 3).
To clarify, i'd just hate to see it go where i can no longer satisfy
the assertion   (lval MOD rval) = (lval - ((lval DIV rval) * rval),
which most pre-pim4/iso compilers could do..

> > Now my 2pennies on the subject of flags to the compiler.. It seems
> > reasonable to have programs behave in a 'conforming' manner, when
> > using -Wpim2 etc.. with the possibility of overriding this with
> > one (or more) flags, to describe specific behaviours. Possible ones:
> > 
> >   -Wstrict-iso-modulus  (tho not sure it's aptly named, since it
> >                          *should* imply exceptions on negative operands
> >                          to both the DIV and MOD operators).
> 
> I think this is not needed as it is already covered by the -Wiso flag.

Right the only use i can think for this flag, would be to test
compliance with ISO, when converting code, however since that suggest
running code for an unknown amount of time, it really is of dubious
value *grin*

> 
> >   -Wpositive-modulus-only  (or something along those lines, to force  
> >                             pim4 DIV/MOD behaviour).
> 
> ok

Right, this could in fact be used to loosen ISO's behaviour, allowing
negative values for DIV/MOD. but this might be a misnamed option, and
one that most people wouldn't 'catch' from just reading say the info
docs on the compiler switches.. hmm how about -Wallow-negative-divmod ?

This would only be relevant for ISO, since all the pims allow it..
And it'd make the intent clearer (and possibly get rid of some raised
exceptions in the process *grin*).

> > 
> >   -Wallow-divide-rem       (For -Wpimx switches, so we can use /  
> >                             and REM.. Tho i'm not quite sure how
> >                             usefull this would be, as in *when*
> >                             we'd need it?).
> 
> ok, maybe users extending PIM4 code might with to use it (rarely I
> suspect though) :-). Though I can see that using / REM has the great
> advantage of having the same results across all flavors of M2 (with
> this switch)
> 
Right.. for legacy code it's pretty useless, and correct if i had pim4
code that i wanted to easily adjust, that might be the way to go. But
as you say, not one i'd expect would be used too often (unless the
Pim4 app just happened to be too large to quickly convert to ISO).

Of course, i sent this as a reply again.. but this exchange, i think,
should really reach all the gm2 community, it might also be relevant
to the ObjM2 community since they are in the early stages of definition,
they might want to tackle this issue once and for all.

> regards,
> Gaius

Ciao!
Michel.