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

Re: Constructors motion

Hi Jurgen,

Just out of curiosity, why do you think the situation is so complex?

A valid computer implementation of Kaucher addition is:
   [a,b] + [c,d] = [roundDown(a+b),roundUp(c+d)]
Note this is the same formula as classic intervals except the constraint a<=b and c<=d is removed. Same is true for all monotonic library functions like reciprocal: 
   1/[a,b] = [roundDown(1/b),roundUp(1/a)]
or square root:
   sqrt([a,b]) = [roundDown(sqrt(a)),roundUp(sqrt(b))].
All these formulas are valid for any proper or improper interval in the natural domain of those functions. A Kaucher implementation is arguably more simple than a classic implementation in these respects because it doesn't have to validate that all inputs are proper.
A handful of functions like multiplication, sin, cos and tan require a few extra cases in thier piecewise-implementation over normal intervals. But note this does not mean at run-time they necessarily require any extra computational time or effort (especially if done in hardware). 

Nate
----- Original Message ----- From: "Jürgen Wolff von Gudenberg" <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 
To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
Cc: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>; <stds-1788@xxxxxxxxxxxxxxxxx>
Sent: Thursday, December 29, 2011 1:52 PM
Subject: Re: Constructors motion





Am 29.12.2011 20:09, schrieb Dan Zuras Intervals:

From: "Nate Hayes"<nh@xxxxxxxxxxxxxxxxx>
To: "Ralph Baker Kearfott"<rbk5287@xxxxxxxxxxxxx>,
=?ISO-8859-15?Q?J=FCrgen_Wolff_von_Gudenberg?=<wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Cc: "Dan Zuras Intervals"<intervals08@xxxxxxxxxxxxxx>,
"John Pryce"<j.d.pryce@xxxxxxxxxxxx>,
<stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: Constructors motion
Date: Thu, 29 Dec 2011 09:25:18 -0600


Folks,

I am with Nate on this one.  Jurgen, I don't think one
can appeal to KISS in this case.  Our users are going
to need some flavor of non-standard intervals to aid
them in solving equations.  I'll leave it to you&
others more qualified than me to decide just which
flavor.  But if we can anticipate a necessary extension,
we should define it, for all the reasons Nate describes
&  more.  There is no reason to publish a standard
which gets fragmented on day 1 for lack of a necessary
feature.

I guess, in that sense, KISS applies after all.  It is
simpler for the world to have one standard extension
for solving equations than many incompatible ones.

Do you not agree?


Dan


ok when we decide to provide an extension like kaucher intervals
we should build an architecture or write a document that clearly states how to provide extensions. Then we can formulate one or more such extensions in a separate document or appendix. I think the situation is more complex like the distinction between required and recommended elementary functions, that's why I propose not to include the extension into our document 
 Jürgen





Hi Baker,

On one hand, I agree what you say about this option. In this sense, its
better than nothing, so I support moving in this direction.

On the other hand, I'd be careful not to oversell this approach as a
panacea. For example, programs and applications written by users for such a 
system are likely under these circumstances not to be portable to other
conforming systems that don't provide the same arithmetic extensions. A
user's experience and understanding of what is an IEEE 1788 standard may
then become muddled or confused.
Think about my previous analogy: if a user writes a program that uses signed integers on a system that supports signed integer arithmetic, this program 
will not run on a different system that only supports arithmetic for
unsigned integers. Technically in this hypothetical scenario both systems are conforming to a "standard for integer arithemtic" but from the user's 
perspective this may lead to some head-scratching.

Sincerely,

Nate



----- Original Message -----
From: "Ralph Baker Kearfott"<rbk5287@xxxxxxxxxxxxx>
To: "JÃŒrgen Wolff von Gudenberg"<wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Cc: "Dan Zuras Intervals"<intervals08@xxxxxxxxxxxxxx>; "John Pryce"
<j.d.pryce@xxxxxxxxxxxx>;<stds-1788@xxxxxxxxxxxxxxxxx>
Sent: Thursday, December 29, 2011 5:48 AM
Subject: Re: Constructors motion



Yes, that's an option.

I'd like to remind people that, simply because something
doesn't appear in the standard, that doesn't necessarily
preclude someone from implementing it in a standard-conforming
system, as long as the standard does not mandate something that
makes it impossible to do so.

Does anyone wish to proffer one or more motions?

Baker

On 12/29/2011 05:39 AM, JÃŒrgen Wolff von Gudenberg wrote:

Dan, Nate, John and all
I think that the approach with 2 constructors is feasible.
we should provide those in P1788 but, because of KISS, nothing more on
Kaucher intervals
JÃŒrgen



--
o Prof. Dr. Juergen Wolff von Gudenberg, Lehrstuhl fuer Informatik II 
    / \          Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
InfoII o         Tel.: +49 931 / 31 86602
  / \  Uni       E-Mail: wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx
 o   o Wuerzburg