Re: Processing "no" votes associated with standards text
> Date: Sun, 1 Apr 2012 15:18:13 -0500 (CDT)
> From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Processing "no" votes associated with standards text
>
> Dan, Vincent, et al,
>
> Our P&P stipulates that the commentary associated with "no"
> votes is to be considered as a motion to amend.
>
> Are there any objections to putting all such "no"
> vote commentary into one motion, after the voting on this
> portion of the standards text runs its course, and then
> seeking a second? Also, it is logical that such a
> motion to amend be processed according to the rules
> for position papers.
>
> Best regards,
>
> Baker
Weeeellll, since this is based on MY no vote,
I cannot really object. Now can I? :-) - Dan
>
> On 03/27/2012 10:34 PM, Dan Zuras Intervals wrote:
> > Folks,
> >
> > This motion defines nums2bareinterval, text2bareinterval,
> > bareempty,& bareentire in some detail& then goes on to
> > define decorated constructors as something of an
> > afterthought.
> >
> > It is my opinion that bare intervals will be of great
> > utility to optimizing compilers to reduce both storage&
> > computation for those applications that can PROVABLY do
> > without decorations. But I believe it will turn out to
> > be poor programming practice for users to create bare
> > intervals on their own.
> >
> > Of course, it must be possible for users to do this. So
> > we must provide something like a makeBare. But to provide
> > a complete set of operations supporting bare intervals as
> > a first class datatype makes us complicit in that poor
> > programming practice.
> >
> > For when the rocket blows up due to some decoration being
> > ignored, finding
> >
> > xx = makeBare(nums2interval(a,b));
> >
> > in the code makes it the programmer's fault. Finding
> >
> > xx = nums2bareinterval(a,b);
> >
> > makes it our fault.
> >
> > And, as I would rather not be named in a $1 billion lawsuit,
> > I vote NO on this motion.
> >
> > I would vote yes if the bare versions of these constructors
> > were removed.
> >
> >
> > Dan
> >
>
>
> --
> ---------------------------------------------------------------
> Ralph Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
> (337) 482-5270 (work) (337) 993-1827 (home)
> URL: http://interval.louisiana.edu/kearfott.html
> Department of Mathematics, University of Louisiana at Lafayette
> (Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
> Box 4-1010, Lafayette, LA 70504-1010, USA
> ---------------------------------------------------------------