Re: Constructors motion
> Date: Thu, 29 Dec 2011 20:52:07 +0100
> From: =?ISO-8859-15?Q?J=FCrgen_Wolff_von_Gudenberg?=
> <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> CC: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>, stds-1788@xxxxxxxxxxxxxxxxx
> 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
OK, let's decide NOW whether or not we want Kauchers
to be part of the standard, extension or not.
Where it goes in the document is unimportant. An
appendix is fine.
And how is the situation more complex than recommended
functions? The analogy seems exact to me. That is:
you may or may not use them but, if you do, we want
them to behave in a standard manner.
If that analogy is valid, we MUST define them if only
to have standard/portable/provable behavior out of
them.
Can we really afford to leave it up to the whims of
those less expert than this collective forum?
In other words: Where BETTER to answer this question?
Dan