Precedence Rules (was Re: Software vendors not using Ada but C)

Precedence Rules (was Re: Software vendors not using Ada but C)

[agate!howland.reston.ans.net!darwin.sura.net!haven.umd.edu!news.umbc.edu!]

mfeldman@seas.gwu.edu (Michael Feldman) writes:
| In article <1993Jun23.163346.29745@sei.cmu.edu> firth@sei.cmu.edu
| (Robert Firth) writes:

| >Good grief.  And I thought Jean Ichbiah was paranoid when he refused to
| >give "and" and "or" the same precedence rules in Ada that they had in the
| >propositional calculus.  Not verbatim, but approximately: "Robert, a
| >programmer should never have to learn a new precedence rule as part of
| >a language.  The language should use only rules everyone already knows."

| And how! Students have more important things to learn than big precedence
| tables. IMHO the precedence rules are designed to make expression
| evaluation well-defined and (reasonably) intuitive, in the absence of
| parentheses. I teach precedence as a more-or-less advanced topic, more
| to illustrate how the language designers thought out the precedence
| than to make the students learn it.

When talking precedence, of course my thoughts turn immediately to mod
and rem (don't yours?).

I have seen the best programmers/mathematicians/all-around-nice-guys
brought down by the seemingly non-intuitive precedence rules surrounding
negative arguments and the mod and rem operators. The expression
-3 mod 2 is interpreted as -(3 mod 2), not (-3) mod 2, as most people
expect (I can make that generalization - we instructors get to ask lots
o' people).

The syntactic reasoning is clear, but not obvious. mod and rem are
grouped with the multiplying operators, which have higher precedence
than unary minus. For * and / this makes no difference in the first
operand, as (-3)*2 and -(3*2) produce the same result. 

When I read Mike and Roberts' comments, I thought "Oh, these rules must
somehow mirror some reality with which I am not familiar". Or something
like that. Checking the Rationale, I found the following (p. 92):

	The operations /, mod, and rem require explanation. There
	is no universal agreement on the semantics of these operations
	for negative operand values. Because different machines
	perform these operations differently, it is tempting not to
	define them for negative values.

So what's the real story-behind-the-story? Is it just easier to set up
the precedence rules this way, or is there some neat anecdote associated
with mod and rem?

Also, (I've always wanted to ask this), does anyone really use mod and
rem with negative operands?


-- 
Mike Berman                           
University of Maryland, Baltimore County           berman@umbc.edu
The views represented in the above post are my own.      

Re: Precedence Rules (was Re: Software vendors not using Ada but C)

[magnesium.club.cc.cmu.edu!news.sei.cmu.edu!ae]

berman@umbc.edu (Mike Berman) asks:
> does anyone really use mod and rem with negative operands?

Sure.  The ACVC test suite uses them.

Oh -- you mean _real_ programs.  Probably not, at least on purpose.

Art Evans

Re: Precedence Rules (was Re: Software vendors not using Ada but C)

[cis.ohio-state.edu!news.sei.cmu.edu!jbg]

In article <20cajmINNqeb@umbc4.umbc.edu>, berman@umbc.edu (Mike Berman) writes:

|> So what's the real story-behind-the-story? Is it just easier to set up
|> the precedence rules this way [i.e., with mod and rem the same precedence
|> as for / and therefore of higher precedence than unary minus], or is there
|> some neat anecdote associated with mod and rem?

The problem is really with the precedence of unary minus.  Some languages make
all unary operators the highest precedence.  Ada doesn't in part because Jean
didn't want too many levels of precedence -- he felt strongly that languages
with many precedence levels were too complicated (I think this was in part a
reaction against ALGOL 68).  The design team also rejected a proposal to place
all unary operators at a higher level of precedence.  During the design, Ron
Brender (and others) suggested that unary + and - be placed with abs at the
highest precedence level.  The design team rejected the proposal (in comment
#5289), saying:

	It is important to be able to say

		-abs X

	Hence the need to have unary adding on a different level [than abs].

Implicit in this decision is a decision not to create an additional higher
precedence level (in the syntax) for unary + and - operators; this is where
the designer's concern for minimizing the numbers of levels of precedence also
affected the final decision (in my opinion).

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: Precedence Rules (was Re: Software vendors not using Ada but C)

[Jonathan Schilling]

In article <20cajmINNqeb@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:
>
>Also, (I've always wanted to ask this), does anyone really use mod and
>rem with negative operands?

Probably not.  But people do use mod with types that include negative
numbers (like INTEGER), and unless the compiler is able to figure out
that the operands have non-negative values, a fair amount of code will
be generated for mod.  This is because the semantics for mod do not
match the semantics of most machines' divide and remainder instructions,
for negative numbers.

Thus, it is a good habit to only use mod with non-negative subtypes,
or to avoid mod and use rem (unless you really have negative operands
and care about the semantics).

-- 
Jonathan Schilling
DDC-I, Inc.
uunet!ddciiny!jls

Re: Precedence Rules (was Re: Software vendors not using Ada but C)

[Michael Feldman]

In article <C96nFu.F4r@ddciiny.UUCP> jls@ddciiny.UUCP (Jonathan Schilling) writ
es:

[stuff deleted]
>
>Probably not.  But people do use mod with types that include negative
>numbers (like INTEGER), and unless the compiler is able to figure out
>that the operands have non-negative values, a fair amount of code will
>be generated for mod.  This is because the semantics for mod do not
>match the semantics of most machines' divide and remainder instructions,
>for negative numbers.
>
>Thus, it is a good habit to only use mod with non-negative subtypes,
>or to avoid mod and use rem (unless you really have negative operands
>and care about the semantics).
>
I agree. This has always been a tough one for me to get across to
students who are used to Pascal's MOD semantics, which of course has
the semantics of Ada's REM. Sigh... Ever try to mechanically translate
some Pascal or Modula-2 code to Ada? Watch out.

Cheers -

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  co-chair, SIGAda Education Committee
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-5296 (fax) - mfeldman@seas.gwu.edu (Internet)
"Pork is what those other guys get from the Government."
------------------------------------------------------------------------

Re: Precedence Rules (was Re: Software vendors not using Ada but C)

[cis.ohio-state.edu!math.ohio-state.edu!sdd.hp.com!network.ucsd.edu!munnar]

In article <1993Jun25.205022.29499@seas.gwu.edu>, mfeldman@seas.gwu.edu (Michae
l Feldman) writes:
> I agree. This has always been a tough one for me to get across to
> students who are used to Pascal's MOD semantics, which of course has
> the semantics of Ada's REM.

The Pascal standard (IOS/EIC 7185:1990) says that
(i mod j) is an error if j <= 0.  That surprised me, I hadn't realised
that it was defined for i < 0.  It goes on to point out explicitly
"Only for i >= 0 and j > 0 does the relation (i div j)*j + i mod j = i hold."
_That_ stunned me.  i div j and i mod j both defined for negative i,
but not compatibly?

Students who have been taught well about Pascal use the rule
    "Never use i div j or i mod j except when (i >= 0) and (j > 0)."
I use the same rule in Ada.

-- 
Richard A. O'Keefe; ok@goanna.cs.rmit.oz.au; RMIT, Melbourne, Australia.

Re: Precedence Rules (was Re: Software vendors not using Ada but C)

[Michael Feldman]

In article <20556@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'K
eefe) writes:

>Students who have been taught well about Pascal use the rule
>    "Never use i div j or i mod j except when (i >= 0) and (j > 0)."
>I use the same rule in Ada.
>
Amen. And I tell students to avoid Ada's MOD, and use REM instead.
It's even more mnemonic - REM means "remainder." Simple. But not for
Pascal-ers.

Mike