Re: Will someone make a formal motion? Re: mid-rad, inf-sup, a caution...

[Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>]

Nate et al,

Thank you for the clarification of your thoughts and stand.

I hadn't read the recent postings to this list to imply we should
in any way prevent internal implementations of mid-rad.  My main
reading is that, for an implementation of interval arithmetic
to be "1788 standard-conforming," it must ...  Perhaps
this will end up implying that it must implement inf-sup arithmetic,
but I don't see how it can say it must not implement
mid-rad arithmetic. It may also end up specifying conversion
between inf-sup and mid-rad form, just as it specifies conversion
between interval forms and text or decimal forms, without saying
how the mid-rad form should be manipulated internally.

Baker

On 5/12/2010 20:19, Nate Hayes wrote:
> Baker,
>
> That's a fair summary on the cache issue. Please excuse me, but in this
> context I found John's comment very shocking!
>
> The recently discussed conversions for mid-rad (ala Vienna and Arnolds
> comment about the x+-r constructor) are good enough for P1788; I gave
> the computer graphics and non-754 mid-rad encoding examples to support
> this idea!!!
>
> My only lingering concern is that we should not prevent (whenever
> possible) internal implementations of mid-rad. I've continued to be a
> little confused on this point, because I hear what I think are
> conflicting messages.
>
> Nate
>
>
>
> ----- Original Message ----- From: "Ralph Baker Kearfott"
> <rbk@xxxxxxxxxxxx>
> To: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> Cc: "R. Baker Kearfott" <rbk@xxxxxxxxxxxxx>; "John Pryce"
> <j.d.pryce@xxxxxxxxxxxx>; "P1788" <stds-1788@xxxxxxxxxxxxxxxxx>
> Sent: Wednesday, May 12, 2010 6:57 PM
> Subject: Re: Will someone make a formal motion? Re: mid-rad, inf-sup, a
> caution...
>
>
> > Nate et al,
> >
> > Ah, so may I summarize (subject to your correction)?:
> >
> > The program is somehow parallelizable because it fits into cache,
> > and it may not fit into cache if the data elements are too large.
> > I'll need to trust you on that, since I have not worked on that level
> > with
> > cache and do not see the exact situation or context.
> >
> > The question remains about whether or not this is a compelling
> > reason to standardize mid-rad (in view of arguments that we are
> > not preventing implementation of mid-rad internally).
> >
> > Baker


--

---------------------------------------------------------------
R. 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
---------------------------------------------------------------