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

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