orthogonal sets of floating-point comparison operators

David Hough uunet!Eng.Sun.COM!David.Hough
Wed Dec 4 09:38:57 PST 1991


Data types whose representable values are only partially ordered have up to
four possible outcomes of
a comparison: less than, equal, greater than, and unordered.
Thus there are 16 possible comparison operators corresponding to all the
combinations of 4 things taken any number at a time.   
Two of these - always true and always false - aren't interesting from the
language design point of view.

The standard C operators == != < <= > >= correspond to an odd subset of
these comparison operators:

	Operator	True if

	==		eq
	!=		lt gt un
	<		lt
	<=		lt eq
	>		gt
	>=		ge

and when you're designing hardware instruction sets, having to allow for
all sixteen possibilities isn't much more trouble than allowing for these
six.   The question is whether the language design should reflect this 
underlying hardware reality.   Part of the "spirit of C" is being close to
the hardware level.

There are straightforward extensions that get you up to 10/14:

	!<		eq gt un
	!<=		gt un
	!>		eq lt un
	!>=		lt un

and to get a complete set, only four more are needed that could be written

	<>		lt gt
	!<>		eq un
	!<>=		un
	<>=		lt eq gt

I don't think the issue is how often these last four would be used, but how
often people would have to look up the exact semantics of the supported
operators because they were an incomplete set and therefore harder to remember.
Omitting the extra operators would be a defect in NCEG C, 
and usurping them for another purpose would be a defect in another language, 
but perhaps not grave by comparison to other defects that some people have
considered tolerable.   Of course, part of NCEG's charter is to remove some
of the latter.   Human coders can work around many kinds of defects, and
with sufficient effort optimizers can reverse engineer the workarounds to
understand and implement the original intent efficiently, but isn't a better
goal to avoid or remove the defects when the opportunity arises?
Whatever the other merits of the additional operators, they are a small 
additional burden on compilers that intend to do a good job on all of NCEG C.

Another syntax that was considered for implementing an orthgonal set of
operators involved, instead of '!' to
indicate the logical complement, using '?' to mean "or unordered" as in
<? or =?, but the natural character to use for this purpose, '?', was already
usurped for the purpose of trigraphs.



More information about the Numeric-interest mailing list