• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• [ Next ] Maybe in reply to: Bill Frantz

--=====================_906165845==_

Due to excessive archive instincts, I start archiving as soon as I smelled a list starting. Attached is my Eudora archive.

--=====================_906165845==_

>From ???@??? Thu Sep 17 15:17:53 1998

Return-Path: <markm@caplet.com>
Received: from discuss.foresight.org (discuss.foresight.org [207.142.17.9])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id PAA20222;
	Thu, 17 Sep 1998 15:17:45 -0700
Received: from wittgenstein.communities.com (mg134-147.ricochet.net [204.179.134.147])
          by discuss.foresight.org (8.8.4/8.8.4) with SMTP
	  id PAA21563; Fri, 18 Sep 1998 15:12:53 -0700

        Bill Frantz <frantz@communities.com>, "Eric Messick" <eric@toad.com>,
        "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>

Right now, in both ELib and ELang, equality is totally screwed up.

1. tables.* currently use either java's "==" or java's ".equals()". The first is fine as an E low-level EQ operator. The second cannot be made to work with Promises (or other similar intermediaries).
2. EQMatcher currently has a symmetric equality operator that's much too expensive (and misleadingly named "eq").

Instead I propose a "static public boolean same(Object a, Object b)" operation for use by non-EQ mappings and tables, and for use by EQMatcher.join() and ELang's "==" operator. The detailed semantics of same() in terms of Java-level pseudo-code:

if (either a or b are DEFERRED or BROKEN) {

throw an exception same() only applies to KEPT references }

if (a and b are both Float or Double) {

//don't use a.equals(b), as it answers wrong for NaN and -0.0 return a.doubleValue() == b.doubleValue() }

//this check comes AFTER the above, so same(NaN,NaN) will yield false if (a == b) {

return true
}

if (a and b are both Byte, Short, Integer, Long, or BigInteger) {

turn both into BigIntegers
//apparent asymmetry is ok, since BigInteger is known to answer //symmetrically
return a equals(b)
}

if (a are both PassByCopy) {

if (a type != b type) {

return false
}
for member in (a type members) {

        if (! same(a member, b member)) {
            return false
        }

return false

Abstractly, same() is an immediate/synchronous symmetrical test of equality in the old-fashioned sense: if same(a, b), then a and b should be substitutable for each other without changing the meaning of a computational state. Unfortunately, in order to enable one to write algorithms that walk cyclic/infinite PassByCopy structures, or PassByCopy structures that contain DEFERRED references, we must still expose primitive EQ, or at least EQ-based tables. As long as this is exposed, the above substitutability claim is false.

For floating-point values, same() sides with arithmetic equality over strict substitutability -- in both Java and the proposed E behavior (where the E behavior is implemented with same()):

	NaN == NaN	yields false
	0.0 == -0.0	yields true

EQMatcher.join() is a corresponding eventual/asynchronous symmetrical equality sufficient for grant matching. It's already implemented (trivially) modulo the need to bottom out in a working same().

There would of course be a "static public int sameHash(Object)" operation that has the usual correspondence with same(), except that sameHash() need not even be exposed to the ELang programmer, assuming our collection classes satisfy their need for hashing.

Note that neither of these operations are extensible by the ELang programmer, and neither is meant to be extensible by the ELib programmer.

	Cheers,
	--MarkM

>From ???@??? Thu Sep 17 15:37:53 1998

Return-Path: <shap@eros.cis.upenn.edu>
Received: from cis.upenn.edu (cm20813845107.cableco-op.com [208.138.45.107])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id PAA20860;
	Thu, 17 Sep 1998 15:40:01 -0700

	by cis.upenn.edu (8.8.7/8.8.7) with ESMTP id PAA09958;
	Thu, 17 Sep 1998 15:42:48 -0400

        Bill Frantz <frantz@communities.com>, "Eric Messick" <eric@toad.com>,
        "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>

<3.0.3.32.19980917151640.006f17e8@ricochet.net> Date: Thu, 17 Sep 1998 15:42:48 -0400
Sender: shap@eros.cis.upenn.edu
X-UIDL: 8d179c6ae84c01a7562612b11fe97467

The idea behind the same() primitive sounds fine, but here are some questions about the particulars:

> if (either a or b are DEFERRED or BROKEN) {
> throw an exception same() only applies to KEPT references
> }

In general, I'm not a fan of exceptions where the violated sanity condition could have been checked explicitly. The exception handling logic is invariably too far away from the computation to recover gracefully. In this particular case, I think the semantics you propose are not what I want.

Claim: a broken Promise is by definition not an object, and it should therefore be the case that the Same() operator behaves consistent with comparing a Float to NaN. This comparison is perfectly sensible, and should be permitted.

Proposed Rules in order of priority from top to bottom:

     Same(NaO, <any>) -> false
     Same(<any>, NaO) -> false
     Same(X, X) -> true unless X is NaO
     Same(X, Y) -> false

In the face of NaO there must also be a Different() primitive:

     Different(NaO, <any>) -> false
     Different(<any>, NaO) -> false
     Different(X, X) -> false unless X is NaO
     Different(X, Y) -> false

Regardless of the Java spec (which I believe gets the definition of != badly wrong in the face of NaN), I believe that the same rules should apply for float,NaN and double,NaN comparisons. That is: these primitives should return true exactly if the comparison is determinable AND true.

Throwing an exception on DEFERRED seems fine.

> Note that neither of these operations are extensible by the ELang
> programmer, and neither is meant to be extensible by the ELib programmer.

Why not?

Jonathan

>From ???@??? Thu Sep 17 17:03:16 1998

Return-Path: <shap@eros.cis.upenn.edu>
Received: from cis.upenn.edu (cm20813845107.cableco-op.com [208.138.45.107])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id RAA22917;
	Thu, 17 Sep 1998 17:03:11 -0700

	by cis.upenn.edu (8.8.7/8.8.7) with ESMTP id RAA12961;
	Thu, 17 Sep 1998 17:05:42 -0400

        Bill Frantz <frantz@communities.com>, "Eric Messick" <eric@toad.com>,
        "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>,
        "Doug Crockford" <crock@communities.com>,
        "Marc Stiegler" <marcs@skyhunter.com>

<3.0.3.32.19980917163419.00dcc430@ricochet.net> Date: Thu, 17 Sep 1998 17:05:42 -0400
Sender: shap@eros.cis.upenn.edu
X-UIDL: 2d050680601198d944fbea5276b1ef8e

> I think I like this. Plausibly, we should push the analogy even further --
> treating a NaN in all ways as a broken reference:

If the two are unified it becomes impossible to distinguish a broken promise for a float from a satisfied promise for a float whose value happens to be NaN. This is quite bad.

> >Proposed Rules in order of priority from top to bottom:
> >
> > Same(NaO, <any>) -> false
> > Same(<any>, NaO) -> false
> > Same(X, X) -> true unless X is NaO
> > Same(X, Y) -> false
>
> Given that NaO includes NaN, and if by a repeated variable, you mean a
> java-primitive EQ check, then I understand & agree with the first three
> lines. What do you mean by your fourth line?

I *think* what I mean is:

	same(x,y)       = false    if isNaN(x)
	                = false    if isNaN(y)
	                = eq(x,y)  otherwise

	different(x,y)  = false    if isNaN(x)
	                = false    if isNaN(y)
	                = eq(x,y)  otherwise

I hesitate only because as a non-Java-person I'm not sure what the semantics of Java's eq operator are.

> What does the IEEE standard say? Java's "!=" does indeed disagree with
> your "Different()". Rather, in java, "a != b" is always equivalent to "!(a
> == b)". If Java & IEEE agree, I'll be strongly inclined to follow along.

I don't own a copy of the floating point spec, and my copy of the C standard is buried in a box at the moment. My recollection is that the IEEE standard specifies that the result of any comparison against NaN is ``unordered.'' [and therefore neither equal nor not equal]. This outcome is consistent with what NaN was really intended to mean, which was that the outcome was not a member of the partial order expressable within the relevant floating point format.

If this recollection is correct, it follows that Java's handling of x==x is correct, but their handling of x != x is simply wrong.

Other possibly useful input from the x86 reference page for fcomp (floating point compare):

If either operand is NaN ... the invalid operation exception is raised and the condition bits are set to ``unordered.''

I expect Norm hardy would know what the correct answer should be.

> >Throwing an exception on DEFERRED seems fine.
>
> Good! Otherwise, equality wouldn't be stable, making collection classes
> much harder to write.

I agree about equality instability, but I'm not really certain that the second part follows. My experience is that exceptions are VERY hard to program well, and that it is actually easier to test conditions like this one explicitly. I therefore tend to take the view that exceptions should be thrown only for outcomes that could not be statically tested (e.g. underflow). My view is that it is easy to write

	if (isDeferred(x))
          throw(someError)

the counterargument is that any parameter could be a promise, and one doesn't want to have to code defensively against that.

Assuming that you *do* throw an exception, there are other issues that arise:

There should be a means to iterate over all non-deferred members of a collection.

It should be possible to define a sort order in which all deferred members go to one extreme or the other.

There may wish to be an event hook associated with the collection class that will generate a message when all promises have been satisfied.

It should be possible for any piece of code to attach an event firing to a promise. E.g. you want to be able to write collections that remain sorted as their member promises are satisfied.

> Equality is a symmetric question. As argued in
> "http://www.caplet.com/security/taxonomy/grant-match/grant-matcher.html",
> from a security viewpoint, it is plausibly the only symmetric question.

I think that *inequality* must by definition be symmetric under the same argument, but I take your point.

As to the rest, I agree that the primitive probably should not be overloadable, but don't expect that to stop people from trying. The problem is that equality is a necessary subcondition of magnitude comparisons, and magnitude comparisons are unavoidable for sorted collections. In a typeless language people *will* build heterogeneous collections and expect to define methods for sorting them. This will cause a convention to arise whether you like it or not, and it is better to state what the proper convention should be than have 10 conventions arise independently.

Actually, it suggests that the comparison function for a sorted collection should be a member pointer rather than <=.

shap

>From ???@??? Thu Sep 17 17:08:38 1998

Return-Path: <shap@eros.cis.upenn.edu>
Received: from cis.upenn.edu (cm20813845107.cableco-op.com [208.138.45.107])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id RAA23070;
	Thu, 17 Sep 1998 17:08:56 -0700

	by cis.upenn.edu (8.8.7/8.8.7) with ESMTP id RAA13340;
	Thu, 17 Sep 1998 17:11:58 -0400

        "Chip Morningstar" <chip@communities.com>,
        Bill Frantz <frantz@communities.com>, "Eric Messick" <eric@toad.com>,
        "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>,
        "Doug Crockford" <crock@communities.com>,
        "Marc Stiegler" <marcs@skyhunter.com>

<199809172105.RAA12961@cis.upenn.edu> Date: Thu, 17 Sep 1998 17:11:58 -0400
Sender: shap@eros.cis.upenn.edu
X-UIDL: a5a8e137fe1617ff96648f9101b37184

Oops. I meant to write:

	different(x,y)  = false    if isNaN(x)
	                = false    if isNaN(y)
	                = !eq(x,y) otherwise

>From ???@??? Thu Sep 17 16:33:14 1998

Return-Path: <markm@caplet.com>
Received: from discuss.foresight.org (discuss.foresight.org [207.142.17.9])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id QAA22312;
	Thu, 17 Sep 1998 16:35:16 -0700
Received: from wittgenstein.communities.com (mg134-147.ricochet.net [204.179.134.147])
          by discuss.foresight.org (8.8.4/8.8.4) with SMTP
	  id QAA22031; Fri, 18 Sep 1998 16:30:29 -0700

        Bill Frantz <frantz@communities.com>, "Eric Messick" <eric@toad.com>,
        "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>,
        "Doug Crockford" <crock@communities.com>,
        "Marc Stiegler" <marcs@skyhunter.com>
In-Reply-To: <199809171942.PAA09958@cis.upenn.edu>
References: <Your message of "Thu, 17 Sep 1998 15:16:40 PDT."             <3.0.3.32.19980917151640.006f17e8@ricochet.net>

At 03:42 PM 9/17/98 -0400, shap@eros.cis.upenn.edu wrote:
>Claim: a broken Promise is by definition not an object, and it
>should therefore be the case that the Same() operator behaves
>consistent with comparing a Float to NaN. This comparison is
>perfectly sensible, and should be permitted.

I think I like this. Plausibly, we should push the analogy even further -- treating a NaN in all ways as a broken reference:

	E state(NaN)		-> "BROKEN"
	E optProblem(NaN)	-> new NaNException()

>Proposed Rules in order of priority from top to bottom:
>
> Same(NaO, <any>) -> false
> Same(<any>, NaO) -> false
> Same(X, X) -> true unless X is NaO
> Same(X, Y) -> false

Given that NaO includes NaN, and if by a repeated variable, you mean a java-primitive EQ check, then I understand & agree with the first three lines. What do you mean by your fourth line?

>In the face of NaO there must also be a Different() primitive:
>
> Different(NaO, <any>) -> false
> Different(<any>, NaO) -> false
> Different(X, X) -> false unless X is NaO
> Different(X, Y) -> false
>
>Regardless of the Java spec (which I believe gets the definition of
>!= badly wrong in the face of NaN), I believe that the same rules
>should apply for float,NaN and double,NaN comparisons. That is:
>these primitives should return true exactly if the comparison is
>determinable AND true.

What does the IEEE standard say? Java's "!=" does indeed disagree with your "Different()". Rather, in java, "a != b" is always equivalent to "!(a == b)". If Java & IEEE agree, I'll be strongly inclined to follow along.

>Throwing an exception on DEFERRED seems fine.

Good! Otherwise, equality wouldn't be stable, making collection classes much harder to write.

>> Note that neither of these operations are extensible by the ELang
>> programmer, and neither is meant to be extensible by the ELib programmer.
>
>Why not?

It's hard enough to get non-extensible equality right. ;)

Equality is a symmetric question. As argued in "http://www.caplet.com/security/taxonomy/grant-match/grant-matcher.html", from a security viewpoint, it is plausibly the only symmetric question. Our normal object-based notion of extensibility admits that extensions always have to live somewhere, and are therefore a claim by someone. For example, java's "a.equals(b)" only yield an answer according to "a".

However, I'm perhaps overstating when I say E's equality is non-extensible. Rather, it's like KeyKOS's DISCRIM (and presumably EROS's analog?): there is a third party that is conventionally in scope at a particular name (in E) or slot number (in KeyKOS/EROS), and equality is a query to this third party with the two specimens as arguments. In other words, in E under this proposal, "a == b" expands to "E same(a, b)". This notion is extensible by replacing/shadowing the definition of "E".

But such extensions are not encouraged or expected to be useful.

	Comments?
	--MarkM

>From ???@??? Thu Sep 17 17:42:36 1998

Return-Path: <shap@eros.cis.upenn.edu>
Received: from cis.upenn.edu (cm20813845107.cableco-op.com [208.138.45.107])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id RAA23831
	for <frantz@communities.com>; Thu, 17 Sep 1998 17:45:27 -0700

	by cis.upenn.edu (8.8.7/8.8.7) with ESMTP id RAA14731;
	Thu, 17 Sep 1998 17:48:30 -0400

        "Eric Messick" <eric@toad.com>, "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>,
        "Marc Stiegler" <marcs@skyhunter.com>

<3.0.32.19980917173633.00b17968@homer> Date: Thu, 17 Sep 1998 17:48:30 -0400
Sender: shap@eros.cis.upenn.edu
X-UIDL: bbbde3e04447c3a6a8043130ab3d1c58

Bill:

Are you aware of the TCP over HTTP stuff that has been done? A lot of people are justifiably reluctant to reconfigure their firewalls, but it proves that one can build a full stream protocol on top of http.

shap

>From ???@??? Thu Sep 17 17:53:34 1998

Return-Path: <shap@eros.cis.upenn.edu>
Received: from cis.upenn.edu (cm20813845107.cableco-op.com [208.138.45.107])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id RAA24006
	for <frantz@communities.com>; Thu, 17 Sep 1998 17:53:02 -0700

	by cis.upenn.edu (8.8.7/8.8.7) with ESMTP id RAA15003;
	Thu, 17 Sep 1998 17:55:36 -0400

        "Eric Messick" <eric@toad.com>, "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>,
        "Marc Stiegler" <marcs@skyhunter.com>

<3.0.32.19980917174359.00b15ec4@homer> Date: Thu, 17 Sep 1998 17:55:36 -0400
Sender: shap@eros.cis.upenn.edu
X-UIDL: 62a3420f7b60516979c85739d76e30bf

> I think I just re-invented the wheel. Does the stuff that has been done
> provide for an "outside" listen port?

I don't know. The group I'm thinking of is doing internet broadcast presentation stuff. They're a xerox spinout. Markm will remember who it was -- Pavel Curtis is currently working there. They might even be willing to give away the implementation; cannot hurt to ask.

shap

>From ???@??? Thu Sep 17 20:38:34 1998

Return-Path: <markm@caplet.com>
Received: from discuss.foresight.org (discuss.foresight.org [207.142.17.9])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id UAA26697;
	Thu, 17 Sep 1998 20:37:30 -0700
Received: from wittgenstein.communities.com (mg134-147.ricochet.net [204.179.134.147])
          by discuss.foresight.org (8.8.4/8.8.4) with SMTP
	  id UAA22874; Fri, 18 Sep 1998 20:32:46 -0700

        Bill Frantz <frantz@communities.com>, "Eric Messick" <eric@toad.com>,
        "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>,
        "Doug Crockford" <crock@communities.com>,
        "Marc Stiegler" <marcs@skyhunter.com>, "Steve Witham" <sw@tiac.net>,
        <sw@truesoft.com>
In-Reply-To: <199809172105.RAA12961@cis.upenn.edu>
References: <Your message of "Thu, 17 Sep 1998 16:34:19 PDT."             <3.0.3.32.19980917163419.00dcc430@ricochet.net>

Wow! I take a nap for a few hours, and when I wake up I find I've got an E-email list going. Cool!

At 05:05 PM 9/17/98 -0400, shap@eros.cis.upenn.edu wrote:
>> I think I like this. Plausibly, we should push the analogy even further --
>> treating a NaN in all ways as a broken reference:
>
>If the two are unified it becomes impossible to distinguish a broken
>promise for a float from a satisfied promise for a float whose value
>happens to be NaN. This is quite bad.

But why not retroactively rationalize a "float whose value happens to be NaN" as exactly a broken promise for a floating point *number*. Otherwise, E has two categories of exceptional data: broken promises and NaNs. This seems unnecessary and excessive. As Alan Kay says about (especially) language design: "Similar things should be made the same or very different".

Besides, they would be distinguishable as follows:

	define isNaN(x) {
	    E state(x) == "BROKEN" && E optProblem(x) isa(NaNException)
	}

with the caveat that a NaN would still be indistinguishable from a reference broken with a NaNException. Indeed, the proposed retroactive rationalization of a NaN is to define it as such.

>I *think* what I mean is:
>
> same(x,y) = false if isNaN(x)
> = false if isNaN(y)
> = eq(x,y) otherwise
>
> different(x,y) = false if isNaN(x)
> = false if isNaN(y)
> = eq(x,y) otherwise
>
>I hesitate only because as a non-Java-person I'm not sure what the
>semantics of Java's eq operator are.

Part of what I was trying to say in my original post is that PassByCopy objects are judged to be the same() or not based on the same()ness of their respective types and members. I assume you didn't intend to suggest dropping this?

>... My recollection is that
>the IEEE standard specifies that the result of any comparison against
>NaN is ``unordered.'' [and therefore neither equal nor not equal].
>...
>If this recollection is correct, it follows that Java's handling of
>x==x is correct, but their handling of x != x is simply wrong.

Java does indeed follow the unordered interpretation correctly. In "a < b", "a <= b", "a == b", "a >= b", and "a > b", if either is a NaN, the result is false. However, it does not follow that "a != b" should be false if either is a NaN. It depends on how you want to think of "!=". Since we pronounce it "not equals", it isn't implausible to me to think of it as syntactic sugar for "!(a == b)".

Unfortunately, a casual web search resulted in lots of IEEE & Java floating point info (especially "http://java.sun.com/people/jag/FP.html#classes") and much wasted time, but no resolution of the issue. As floating point arithmetic is one of the areas I least want to innovate in, I'm inclined to defer to Java until there's a good reason not to.

>My experience is that exceptions are VERY
>hard to program well, and that it is actually easier to test
>conditions like this one explicitly. I therefore tend to take the
>view that exceptions should be thrown only for outcomes that could not
>be statically tested (e.g. underflow). My view is that it is easy to
>write
>
> if (isDeferred(x))
> throw(someError)

I don't understand this argument. When I define an abstraction, I often have a notion of correct input. If I detect incorrect input, my best and simplest choice is to throw an exception before I do any damage to myself, and not mislead my caller that I did the job requested.

When I use such an abstraction, if I wish to avoid getting an exception thrown at me, it's my responsibility to ensure that my arguments meet the abstraction's preconditions. I believe your example code above is an illustration of this. But when the caller doesn't do this, then the callee should throw an exception so that naive callers will be terminated, rather than continue in a confused manner. When you have to choose, always choose safety over liveness. In other words:

Death Before Confusion!

More soon...

>From ???@??? Thu Sep 17 21:58:34 1998

Return-Path: <markm@caplet.com>
Received: from discuss.foresight.org (discuss.foresight.org [207.142.17.9])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id WAA27578;
	Thu, 17 Sep 1998 22:00:30 -0700
Received: from wittgenstein.communities.com (mg134-147.ricochet.net [204.179.134.147])
          by discuss.foresight.org (8.8.4/8.8.4) with SMTP
	  id VAA23162; Fri, 18 Sep 1998 21:56:01 -0700

        Bill Frantz <frantz@communities.com>, "Eric Messick" <eric@toad.com>,
        "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>,
        "Doug Crockford" <crock@communities.com>,
        "Marc Stiegler" <marcs@skyhunter.com>, "Steve Witham" <sw@tiac.net>,
        <sw@truesoft.com>
In-Reply-To: <199809172105.RAA12961@cis.upenn.edu>
References: <Your message of "Thu, 17 Sep 1998 16:34:19 PDT."             <3.0.3.32.19980917163419.00dcc430@ricochet.net>

At 05:05 PM 9/17/98 -0400, shap@eros.cis.upenn.edu wrote:
>Assuming that you *do* throw an exception, there are other issues that
>arise:
>
> There should be a means to iterate over all non-deferred members of
> a collection.

By "members", I'm not sure if you meant keys, values, or both.

All my collections are single-valued mappings from keys to values. Ie, all my collection contain a set of key-value pairs, where there is at most one pair containing a given key. However, the notion of "given key" is the issue here, and the proposal on the table is to support two kinds: primitive EQ (java pointer '==') and same() (the E language's '==' operator). The following comments apply only to same()-based collections, or "normal collections".

If we define same() such that same(x, x) is true only for a certain category of x, then I propose that E's normal collections only allow keys in this category. Since this category necessarily excludes deferred references, we *can* only iterate over non-deferred keys, so the issue is moot. As far as iterating over non-deferred values, the following works without extra mechanism:

	for val ? (E state(val) != "DEFERRED") in collection {
	    //whatever
	}

For those that don't already know: '?' is read "such that". The above code is equivalent to for:

	for val in collection {
	    if (E state(val) != "DEFERRED") {
	        //whatever
	    }
	}

(If the deferred-key issue were not moot, the same technique would work for keys as well, without extra mechanism.)

> It should be possible to define a sort order in which all deferred
> members go to one extreme or the other.

I'll take this opportunity to explain the new expansion of E's magnitude comparison operators. We start with Java's convention of a 'compareTo()' method. For several classes (eg, String, BigInteger, BigDecimal), 'a.compareTo(b)' yields a negative number, zero, or a positive number as 'a' claims that it is less than, as big as, or greater than 'b'. The idea in Java is that the callee has one method to define, while the caller can simply say:

a.compareTo(b) op 0

where 'op' is '<', '<=', '>=', or '>'. In E, the magnitude comparison operators expand to such code. Note that 'a' can claim to be incomparable to 'b' by returning a NaN, since the resulting comparisons of NaN and zero will always yield false. E's floating point numbers implement compareTo() such that if either operand is a NaN, the result is a NaN. E's sets implement compareTo() to indicate subset-ness, which is indeed a partial order on sets.

Note that, unlike '==', E's magnitude comparisons are asymmetric! In E, 'a < b' and 'b > a' are asking the same question, but the first is asking 'a', whereas the second is asking 'b'. When doing capability programming, the programmer must always remember to ask themselves "according to whom?".

So, to get back to your original question,

	define compareTo(a, b) {
	    if (E state(a) == "DEFERRED") {
	        if (E state(b) == "DEFERRED") {
	            0 //if you want these to sort as-big-as
	            //NaN if you want these to be incomparable
	        } else {
	            -1 //a DEFERRED reference is less than all else
	        }
	    } else if (E state(b) == "DEFERRED") {
	        1
	    } else {
	        a compareTo(b)
	    }
	}

While this would work, it would not be stable. Over time, DEFERRED reference become non-DEFERRED. Those that become KEPT are necessarily indistinguishable from their target.

This does raise an interesting question: is the state of a reference guaranteed to be stable during an event? After all, DEFERRED references are *the* interface between different vats. The two current implementations of inter-vat DEFERRED references -- Proxy in the proxy comm system, and ExternalRef for lightweight use in a shared address space -- only effect reference state() between events. It's probably a good idea for the semantics to specify this.

> There may wish to be an event hook associated with the collection
> class that will generate a message when all promises have been
> satisfied.

Why with a collection? This would seem to burden the wrong abstraction. There are such hooks on the objects themselves: whenFulfilled() whenResolved() and whenBroken() (as documented in ObjectSugar).

> It should be possible for any piece of code to attach an event
> firing to a promise. E.g. you want to be able to write collections
> that remain sorted as their member promises are satisfied.

Given that you mean "eventually sorted", this is indeed possible. But why?

>As to the rest, I agree that the primitive probably should not be
>overloadable, but don't expect that to stop people from trying. The
>problem is that equality is a necessary subcondition of magnitude
>comparisons, and magnitude comparisons are unavoidable for sorted
>collections. In a typeless language people *will* build heterogeneous
>collections and expect to define methods for sorting them. This will
>cause a convention to arise whether you like it or not, and it is
>better to state what the proper convention should be than have 10
>conventions arise independently.

Yup. You've zeroed in on a bit of purposeful sleaze. I'm not treating '==' as a magnitude comparison operator. Given my expansion of '<', etc, I could define, for example 'a === b' to mean "a is as big as b" and to expand to 'a compareTo(b) == 0'. This could then be proper arithmetic equality, and I could then unburden '==' from numeric issues, turning it into a pure substitutability test.

However, this would be way too much to explain to most anyone. We already have too many different equalities as it is:

1. same() -- E's '==',
2. join() -- eventual equality for grant matching, and
3. EQ -- java's pointer '=='.

In addition, many E programmers will make extensive use of java's libraries, in which case they may also need to understand

4) java's 'a.equals(b)'.

even though this isn't exposed to the E language programmer. Help! Fortunately, an explanation of programming in E need not mention anything other than E's '==' for many many chapters.

When the E programmer really wishes to ask "What's a's opinion on whether it's as big as b?" then they can manually say:

a compareTo(b) == 0

If they don't know enough to say this, they probably don't know enough to understand the difference between this and "Are a and b the same?". I hope they usually they shouldn't need to know the difference.

>Actually, it suggests that the comparison function for a sorted
>collection should be a member pointer rather than <=.

I think I'm terminologically challenged. What's a member pointer?

"Some equals are more piggish than others."

--George Orwell, sort of

>From ???@??? Thu Sep 17 22:18:34 1998

Return-Path: <markm@caplet.com>
Received: from discuss.foresight.org (discuss.foresight.org [207.142.17.9])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id WAA27788;
	Thu, 17 Sep 1998 22:18:01 -0700
Received: from wittgenstein.communities.com (mg134-147.ricochet.net [204.179.134.147])
          by discuss.foresight.org (8.8.4/8.8.4) with SMTP
	  id WAA23229; Fri, 18 Sep 1998 22:13:41 -0700

        "Chip Morningstar" <chip@communities.com>,
        "Eric Messick" <eric@toad.com>, "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>,
        "Doug Crockford" <crock@communities.com>,
        "Marc Stiegler" <marcs@skyhunter.com>

At 05:20 PM 9/17/98 -0700, Bill Frantz wrote:
>At 05:05 PM 9/17/98 -0400, shap@eros.cis.upenn.edu wrote:
>>I hesitate only because as a non-Java-person I'm not sure what the
>>semantics of Java's eq operator are.
>>
>>> What does the IEEE standard say? Java's "!=" does indeed disagree with
>>> your "Different()". Rather, in java, "a != b" is always equivalent to
"!(a
>>> == b)". If Java & IEEE agree, I'll be strongly inclined to follow along.
>
>Java is particularly brain dead with NaNs. If you have two Floats which
>are NaN, then: a == b yields true.

To be precise, 'a.equals(b)' yields true, and 'a == b' yields true iff 'a' and 'b' point to the identical Float object.

>If you have two floats (note the caps)
>which are NaN, then correctly: a == b yields false and a != b yields false.

In this case, I believe 'a != b' yield true.

>From ???@??? Fri Sep 18 01:33:38 1998

Return-Path: <ping@lfw.org>
Received: from discuss.foresight.org (discuss.foresight.org [207.142.17.9])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id BAA29671;
	Fri, 18 Sep 1998 01:33:07 -0700
Received: from skuld.lfw.org (root@sfo-ca5-17.ix.netcom.com [199.35.210.177])
          by discuss.foresight.org (8.8.4/8.8.4) with ESMTP
	  id BAA24056; Sat, 19 Sep 1998 01:27:35 -0700

        Chip Morningstar <chip@communities.com>,
        Bill Frantz <frantz@communities.com>, Eric Messick <eric@toad.com>,
        Danfuzz Bornstein <danfuzz@milk.com>, Jay Fenton <jay@fentonia.com>,
        Jonathan Shapiro <jsshapiro@earthlink.net>,
        Norm Hardy <norm@netcom.com>, "E. Dean Tribble" <tribble@netcom.com>,
        Doug Crockford <crock@communities.com>,
        Marc Stiegler <marcs@skyhunter.com>, Steve Witham <sw@tiac.net>,
        sw@truesoft.com

Organization: lfw <http://www.lfw.org/>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 17 Sep 1998, Mark S. Miller wrote:
> > There may wish to be an event hook associated with the collection
> > class that will generate a message when all promises have been
> > satisfied.
>
> Why with a collection? This would seem to burden the wrong abstraction.
> There are such hooks on the objects themselves: whenFulfilled()
> whenResolved() and whenBroken() (as documented in ObjectSugar).

If you wanted to know when the entire collection was deterministically sorted, would you expect the objects to all be modified so that they knew enough to notify the collection, then?

> However, this would be way too much to explain to most anyone. We already
> have too many different equalities as it is:
>
> 1) same() -- E's '==',
> 2) join() -- eventual equality for grant matching, and
> 3) EQ -- java's pointer '=='.
>
> In addition, many E programmers will make extensive use of java's
> libraries, in which case they may also need to understand
>
> 4) java's 'a.equals(b)'.

Could you explain what the intended difference between same() and equals() is? I assumed that they were intended to tell you if two things appeared the same. But same() is symmetric where equals() is not.

And why would the E programmer ever care about java's pointer == (door number 3) anyway?

> >Actually, it suggests that the comparison function for a sorted
> >collection should be a member pointer rather than <=.
>
> I think I'm terminologically challenged. What's a member pointer?

I think he meant an object method, i.e. your compareTo.

Ping
<ping@lfw.org>

>From ???@??? Fri Sep 18 08:08:43 1998

Return-Path: <shap@eros.cis.upenn.edu>
Received: from cis.upenn.edu (cm20813845107.cableco-op.com [208.138.45.107])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id IAA32015;
	Fri, 18 Sep 1998 08:09:32 -0700

	by cis.upenn.edu (8.8.7/8.8.7) with ESMTP id IAA19856;
	Fri, 18 Sep 1998 08:12:31 -0400

        Chip Morningstar <chip@communities.com>,
        Bill Frantz <frantz@communities.com>, Eric Messick <eric@toad.com>,
        Danfuzz Bornstein <danfuzz@milk.com>, Jay Fenton <jay@fentonia.com>,
        Jonathan Shapiro <jsshapiro@earthlink.net>,
        Norm Hardy <norm@netcom.com>, "E. Dean Tribble" <tribble@netcom.com>,
        Doug Crockford <crock@communities.com>,
        Marc Stiegler <marcs@skyhunter.com>, Steve Witham <sw@tiac.net>,
        sw@truesoft.com

<Pine.LNX.3.93.980918012930.10104A-100000@skuld.lfw.org> Date: Fri, 18 Sep 1998 08:12:31 -0400
Sender: shap@eros.cis.upenn.edu
X-UIDL: 580eef2f1675e3e396531f2802339a25

> If you wanted to know when the entire collection was
> deterministically sorted, would you expect the objects
> to all be modified so that they knew enough to notify
> the collection, then?

Yes. I'ld expect that as Promise objects are inserted into the collection the collection would attach notifiers to them, and would keep a counter of the number of outstanding Promise objects. When this counter goes to zero, the collection can be sorted.

> > >Actually, it suggests that the comparison function for a sorted
> > >collection should be a member pointer rather than <=.
> >
> > I think I'm terminologically challenged. What's a member pointer?
>
> I think he meant an object method, i.e. your compareTo.

I meant a global function cmp(ob1, ob2). The problem is that for primitive objects you cannot add members, and in heterogeneous objects the comparator provided with the object won't know what to do in all cases. There is therefore a need to have a comparison function that is not bound to the particular object types.

shap

>From ???@??? Fri Sep 18 09:18:44 1998

Return-Path: <e-lang-request@eros.cis.upenn.edu> Received: from eros.cis.upenn.edu (EROS.CIS.UPENN.EDU [158.130.6.119])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id JAA00061;
	Fri, 18 Sep 1998 09:17:59 -0700
Received: (from listserv@localhost)
	by eros.cis.upenn.edu (8.8.5/8.8.5) id MAA00046;
	Fri, 18 Sep 1998 12:02:04 -0400

Since I've only been seeing half of the replies, and since this discussion ought to get archived, I've set up an E language mailing list at eros.cis.upenn.edu:

e-lang@eros.cis.upenn.edu

Mail to this alias will go to all of us and will also get archived.

At the moment, the list manager isn't majordomo, so subscribe/unsubscribe must be handled in the *subject* line. Someday soon I'm going to convert to majordomo.

Eventually this list should migrate to erights.org, but markm hasn't woken up yet and I didn't want to lose any more traffic while we were sorting things out.

Steve Witham: You are getting this at work because I explicitly bcc'd you there. Only your home email address is actually on the list alias.

shap

>From ???@??? Thu Sep 17 17:36:33 1998

To: "Mark S. Miller" <markm@caplet.com>, shap@eros.cis.upenn.edu From: Bill Frantz <frantz@communities.com> Subject: E communications through firewalls Cc: <bugs@erights.org>, "Eric Messick" <eric@toad.com>, "Danfuzz Bornstein" <danfuzz@milk.com>, "Jay Fenton" <jay@fentonia.com>, "Jonathan Shapiro" <jsshapiro@earthlink.net>, "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>, "E. Dean Tribble" <tribble@netcom.com>, "Marc Stiegler" <marcs@skyhunter.com> Bcc:
X-Attachments:

I am in the process of designing the necessary communication bits which will allow E communications to work through firewalls. I am looking for comments on the design. If any of you would like to review and comment, I can send you the specification.

N.B. The specification is in HTML. It can be flattened to 7 bit ASCII, but it will lose links and fonts in the process.

>From ???@??? Thu Sep 17 17:43:59 1998

To: shap@eros.cis.upenn.edu
From: Bill Frantz <frantz@communities.com> Subject: Re: E communications through firewalls Cc: "Mark S. Miller" <markm@caplet.com>, bugs@erights.org, "Eric Messick" <eric@toad.com>, "Danfuzz Bornstein" <danfuzz@milk.com>, "Jay Fenton" <jay@fentonia.com>, "Jonathan Shapiro" <jsshapiro@earthlink.net>, "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>, "E. Dean Tribble" <tribble@netcom.com>, "Marc Stiegler" <marcs@skyhunter.com> Bcc:
X-Attachments:

I think I just re-invented the wheel. Does the stuff that has been done provide for an "outside" listen port?

At 05:48 PM 9/17/98 -0400, shap@eros.cis.upenn.edu wrote:
>Bill:
>
>Are you aware of the TCP over HTTP stuff that has been done? A lot of
>people are justifiably reluctant to reconfigure their firewalls, but
>it proves that one can build a full stream protocol on top of http.
>
>
>shap
>
>
>From ???@??? Fri Sep 18 10:25:55 1998

To: "Mark S. Miller" <markm@caplet.com>
From: Bill Frantz <frantz@communities.com> Subject: Re: ELib: ELang: Equality totally screwed up. Needs overhaul Cc: shap@eros.cis.upenn.edu, <bugs@erights.org>, "Chip Morningstar" <chip@communities.com>, "Eric Messick" <eric@toad.com>, "Danfuzz Bornstein" <danfuzz@milk.com>, "Jay Fenton" <jay@fentonia.com>, "Jonathan Shapiro" <jsshapiro@earthlink.net>, "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>, "E. Dean Tribble" <tribble@netcom.com>, "Doug Crockford" <crock@communities.com>, "Marc Stiegler" <marcs@skyhunter.com> Bcc:
X-Attachments:

At 10:17 PM 9/17/98 -0700, Mark S. Miller wrote:
>At 05:20 PM 9/17/98 -0700, Bill Frantz wrote:
>>At 05:05 PM 9/17/98 -0400, shap@eros.cis.upenn.edu wrote:
>>>I hesitate only because as a non-Java-person I'm not sure what the
>>>semantics of Java's eq operator are.
>>>
>>>> What does the IEEE standard say? Java's "!=" does indeed disagree with
>>>> your "Different()". Rather, in java, "a != b" is always equivalent to
>"!(a
>>>> == b)". If Java & IEEE agree, I'll be strongly inclined to follow along.
>>
>>Java is particularly brain dead with NaNs. If you have two Floats which
>>are NaN, then: a == b yields true.
>
>To be precise, 'a.equals(b)' yields true, and 'a == b' yields true iff 'a'
>and 'b' point to the identical Float object.
>
>
>>If you have two floats (note the caps)
>>which are NaN, then correctly: a == b yields false and a != b yields false.
>
>In this case, I believe 'a != b' yield true.

Yup. I should RTFM first.

>From ???@??? Thu Sep 17 17:18:22 1998

To: shap@eros.cis.upenn.edu, "Mark S. Miller" <markm@caplet.com> From: Bill Frantz <frantz@communities.com> Subject: Re: ELib: ELang: Equality totally screwed up. Needs overhaul Cc: bugs@erights.org, "Chip Morningstar" <chip@communities.com>, "Eric Messick" <eric@toad.com>, "Danfuzz Bornstein" <danfuzz@milk.com>, "Jay Fenton" <jay@fentonia.com>, "Jonathan Shapiro" <jsshapiro@earthlink.net>, "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>, "E. Dean Tribble" <tribble@netcom.com>, "Doug Crockford" <crock@communities.com>, "Marc Stiegler" <marcs@skyhunter.com> Bcc:
X-Attachments:

At 05:05 PM 9/17/98 -0400, shap@eros.cis.upenn.edu wrote:
>I hesitate only because as a non-Java-person I'm not sure what the
>semantics of Java's eq operator are.
>
>> What does the IEEE standard say? Java's "!=" does indeed disagree with
>> your "Different()". Rather, in java, "a != b" is always equivalent to "!(a
>> == b)". If Java & IEEE agree, I'll be strongly inclined to follow along.

Java is particularly brain dead with NaNs. If you have two Floats which are NaN, then: a == b yields true. If you have two floats (note the caps) which are NaN, then correctly: a == b yields false and a != b yields false.

Java has an object type Float and a scaler type float. (Scaler types in Java are very much like the same type in C assuming a 32 bit int and a 64 bit long.)

>From ???@??? Fri Sep 18 08:03:43 1998

Return-Path: <shap@eros.cis.upenn.edu>
Received: from cis.upenn.edu (cm20813845107.cableco-op.com [208.138.45.107])

	by homer.communities.com (8.9.1/8.9.1) with ESMTP id IAA31938;
	Fri, 18 Sep 1998 08:02:18 -0700

	by cis.upenn.edu (8.8.7/8.8.7) with ESMTP id IAA19826;
	Fri, 18 Sep 1998 08:05:14 -0400

        Bill Frantz <frantz@communities.com>, "Eric Messick" <eric@toad.com>,
        "Danfuzz Bornstein" <danfuzz@milk.com>,
        "Jay Fenton" <jay@fentonia.com>,
        "Jonathan Shapiro" <jsshapiro@earthlink.net>,
        "Ka-Ping Yee" <ping@foresight.org>, "Norm Hardy" <norm@netcom.com>,
        "E. Dean Tribble" <tribble@netcom.com>,
        "Doug Crockford" <crock@communities.com>,
        "Marc Stiegler" <marcs@skyhunter.com>, "Steve Witham" <sw@tiac.net>,
        sw@truesoft.com

<3.0.3.32.19980917203627.00db7bb0@ricochet.net> Date: Fri, 18 Sep 1998 08:05:14 -0400
Sender: shap@eros.cis.upenn.edu
X-UIDL: 27ba20981a6771398b90427affe49e30

> >If the two are unified it becomes impossible to distinguish a broken
> >promise for a float from a satisfied promise for a float whose value
> >happens to be NaN. This is quite bad.
>
> But why not retroactively rationalize a "float whose value happens to be
> NaN" as exactly a broken promise for a floating point
> *number*.... They would be distinguishable as follows:
>
> define isNaN(x) {
> E state(x) == "BROKEN" && E optProblem(x) isa(NaNException)
> }

There are two distinguished NaN values in IEEE-compliant hardware: +NaN and -NaN. In such implementations, magnitude comparisons between +NaN and -NaN respond according to the obvious partial order. In addition, NaN's can be signalling or non-signalling.

Bottom line: don't make NaN a broken promise for a float until you've talked to someone who does serious numerics programming.

> Part of what I was trying to say in my original post is that PassByCopy
> objects are judged to be the same() or not based on the same()ness of their
> respective types and members. I assume you didn't intend to suggest
> dropping this?

I was paying attention exclusively to the question of equality without reference to any larger issue. My view is that we must first define equality correctly and we can then define things derived from it.

> However, it does not follow that "a != b" should be false if either
> is a NaN.... Since we pronounce it "not equals", it isn't
> implausible to me to think of it as syntactic sugar for "!(a == b)".

This is a question of mathematical definitions. How we pronounce it is not especially relevant.

That said, I just ran a test case in C with somewhat surprising results. The program is attached at the bottom of this file. When qnan (quiet -- i.e. non-signalling) field is set to 1, == gives true if the NaN signs are the same and false if the signs are different. != comes out as ! (x == y), which matches Java.

The bad news is that the answers are different on x86 and sparc for signalling NaN's (qnan = 0). At this point I have to conclude that I don't quite grok the format.

Perhaps Bill or Norm will be able to see what I got wrong. Actually, I'm not entirely surprised; the x86 FPU is known to have some issues in the area of NaN handling.

> I don't understand this argument. When I define an abstraction, I often
> have a notion of correct input.

I agree, though in the particular case of NaN the definition of ``correct input'' depends on the application. This is why applications have the authority to suppress floating point exceptions in certain cases.

> If I detect incorrect input, my best and simplest choice is to throw
> an exception before I do any damage to myself, and not mislead my
> caller that I did the job requested.

The question is whether you should *check* for correct input in the case where the hardware does not and the user could easily have done so. Because of the marginal test and branch (which is forward and therefore mis-predicted), the best possible compilation yields a factor of 2 to 3 difference in cost between (x and y are doubles):

non-defensive exception-preempting

          z=x/y                if (y != 0)
                                  z = x/y;

Also, note that the second completely screws most loop optimizations.

In many cases, the user already knows that the values are good even when the compiler does not.

In the particular case of numeric programming, factors of 3 to 5 really matter.

> When you have to choose, always choose safety over liveness.
>
> Death Before Confusion!
>

This is a deep philosophical separation between us. In your view performance is not a design criterion. In my view it is, and must sometimes be balanced against safety. This is an area where the Java group simply got some things wrong, and the results speak for themselves. I think that the factor of 2 in the case shown above is an unacceptable cost when the alternative is to allow the user program to turn off NaN signalling.

It is useful to have abstractions that protect me from my errors in a natural and easy to understand way.

It is *essential* to have means to bypass these added protections when I know what I'm doing and performance matters.

shap

#include <features.h>
#include <ieee754.h>
#ifdef linux
#include <fpu_control.h>
#endif

#define _IEEE_754

/* #include <nan.h> */

double d1;
double d2;

#if defined(_IEEE) || defined(_IEEE_754)

#if defined(_BIG_ENDIAN)

typedef union
{

	struct
	{
		unsigned sign		: 1;
		unsigned exponent	:11;
		unsigned bits		:20;
		unsigned fraction_low	:32;
	} inf_parts;
	struct
	{
		unsigned sign		: 1;
		unsigned exponent	:11;
		unsigned qnan_bit	: 1;
		unsigned bits		:19;
		unsigned fraction_low	:32;
	} nan_parts;
	double d;

} dnan;

#else /* Must be _LITTLE_ENDIAN */

typedef union
{

	struct {
		unsigned fraction_low	:32;
		unsigned bits		:20;
		unsigned exponent	:11;
		unsigned sign		: 1;
	} inf_parts;
	struct {
		unsigned fraction_low	:32;
		unsigned bits		:19;
		unsigned qnan_bit	: 1;
		unsigned exponent	:11;
		unsigned sign		: 1;
	} nan_parts;
	double d;

#endif /* Endian based selection */

/*
 * IsNANorINF checks that exponent of double == 2047
 * i.e. that number is a NaN or an infinity
 */
#define	IsNANorINF(X)  (((dnan *)&(X))->nan_parts.exponent == 0x7ff)

/*

• IsINF must be used after IsNANorINF has checked the exponent */ #define IsINF(X) (((dnan *)&(X))->inf_parts.bits == 0 && \ ((dnan *)&(X))->inf_parts.fraction_low == 0)

/*
 * IsPosNAN and IsNegNAN can be used to check the sign of infinities too
 */
#define	IsPosNAN(X)	(((dnan *)&(X))->nan_parts.sign == 0)

#define	IsNegNAN(X)	(((dnan *)&(X))->nan_parts.sign == 1)

#define	NaN(X)		(((dnan *)&(X))->nan_parts.exponent == 0x7ff)

#else

#error "Not an IEEE compilation system"

#endif

void f(double, double);

main()
{
dnan pos_nan;
dnan neg_nan;

#ifdef linux
/* Setting this has the unfortunate consequence of masking inexact

result faults, which may mask NaN comparisons on x86 */ __setfpucw(_FPU_IEEE);
#endif

  pos_nan.nan_parts.sign = 0;
  pos_nan.nan_parts.exponent = 0x7ff;
  pos_nan.nan_parts.qnan_bit = 1;
  pos_nan.nan_parts.bits = 0;
  pos_nan.nan_parts.fraction_low = 0;
  
  neg_nan.nan_parts.sign = 0;
  neg_nan.nan_parts.exponent = 0x7ff;
  neg_nan.nan_parts.qnan_bit = 1;

  f(pos_nan.d, pos_nan.d);
  f(neg_nan.d, neg_nan.d);
  f(pos_nan.d, neg_nan.d);

pos_nan.nan_parts.qnan_bit = 0;
neg_nan.nan_parts.qnan_bit = 0;

  f(pos_nan.d, pos_nan.d);
  f(neg_nan.d, neg_nan.d);
  f(pos_nan.d, neg_nan.d);

void
f(double d1, double d2)
{
if (NaN(d1))
printf("d1 is nan\n");

if (NaN(d2))
printf("d2 is nan\n");

if (d1 == d2)
printf("nan == nan => true\n");
else
printf("nan == nan => false\n");

if (d1 != d2)
printf("nan != nan => true\n");
else
printf("nan != nan => false\n");
}

--=====================_906165845==_--

• [ Next ] Maybe in reply to: Bill Frantz