Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Fw: Please post for me

Dear P1788,
For the sake of my friend Bill Walster who is experiencing "technical difficulties," I am forwarding the three attached e-mails as requested. 

Sincerely,

Nate
----- Original Message ----- From: "Bill" <kayewalster@xxxxxxxxx> 
To: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, May 18, 2011 1:43 PM
Subject: Please post for me




Nate,

I'm on my wife's computer.  Mine is ill. :(

Please post the attached emails for me.  They were rejected as seen in
the third attachment.

Thanks,

Bill

P. S.:  Hope all is well with you and your work.
--- Begin Message --- There is no reason for an interval arithmetic standard to specify how it is implemented other than that *any* implementation must not violate containment, which is the *only* error an interval implementation can make.
--- End Message ---
--- Begin Message --- 
On 5/18/11 9:23 AM, Nate Hayes wrote:

Nick Maclaren wrote:

In particular, I regard any hint that such a standard includes a
requirement for established languages to make unacceptable changes
as almost certain to kill acceptance.

But, to make a more positive contribution, here is another approach:

   Expressions are required to return an interval that must contain
   all of the possible values resulting from a mathematically perfect
   evaluation of all possible values in the input intervals.

Both the performance and tightness of the result would be quality of
implementation issues.


Amen.

Yes.


This is particularly true when considering the topic of property tracking
with decorations. But unfortunately, most of that lengthy discussion has
taken place offline over the past 5 months, so I suspect few people
listening will know why I mention that.

Nate




And, yes, a compiler WOULD be allowed to replace
an expression by a numerically better equivalent.

And Amen!


Most compilers would
then have flags, choosing the balance.

That was also my preference for IEEE 754 support, incidentally, but it's
trickier to specify for that.


Regards,
Nick.

--- End Message ---
--- Begin Message ---

---------- Forwarded message ----------
From: IEEE LISTSERV Server (16.0) <LISTSERV@xxxxxxxx>
Date: Wed, May 18, 2011 at 10:02 AM
Subject: Rejected posting to STDS-1788@xxxxxxxxxxxxxxxxx
To: kayewalster@xxxxxxxxx


You  are  not  authorized  to  send  mail  to  the  STDS-1788  list  from  your
kayewalster@xxxxxxxxx account. You might be authorized to post to the list from
another account, or perhaps when using another mail program configured to use a
different email address.  However, LISTSERV has no way to  associate this other
account  or address  with yours.  If you  need assistance  or if  you have  any
questions regarding the  policy of the STDS-1788 list, please  contact the list
owners at STDS-1788-request@xxxxxxxxxxxxxxxxx.


---------- Forwarded message ----------
From: Bill <kayewalster@xxxxxxxxx>
To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
Date: Wed, 18 May 2011 09:54:34 -0700
Subject: Re: _expression_ evaluation [was Re: I vote NO ...]
On 5/18/11 9:23 AM, Nate Hayes wrote:
Nick Maclaren wrote:
In particular, I regard any hint that such a standard includes a
requirement for established languages to make unacceptable changes
as almost certain to kill acceptance.

But, to make a more positive contribution, here is another approach:

  Expressions are required to return an interval that must contain
  all of the possible values resulting from a mathematically perfect
  evaluation of all possible values in the input intervals.

Both the performance and tightness of the result would be quality of
implementation issues.

Amen.
Yes.

This is particularly true when considering the topic of property tracking
with decorations. But unfortunately, most of that lengthy discussion has
taken place offline over the past 5 months, so I suspect few people
listening will know why I mention that.

Nate



And, yes, a compiler WOULD be allowed to replace
an _expression_ by a numerically better equivalent.
And Amen!

Most compilers would
then have flags, choosing the balance.

That was also my preference for IEEE 754 support, incidentally, but it's
trickier to specify for that.


Regards,
Nick.





--- End Message ---