Re: YES on Motion P1788/0019.01
> Date: Sun, 12 Sep 2010 20:07:52 +0200
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> CC: rbk@xxxxxxxxxxxx, stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: YES on Motion P1788/0019.01
>
> Dan Zuras Intervals wrote:
> >> Date: Sat, 11 Sep 2010 13:28:55 -0500
> >> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> >> To: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> >> CC: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> >> Subject: Motion P1788/0019.01: Explicit/Implicit idatatypes -- voting period begins
> >>
> >> P1788 members:
> >>
> >> The discussion period for Motion 19 is now officially ended, and
> >> the voting period herewith begins, to run until the end of Saturday,
> >> October 2. (The voting period may be extended at the discretion
> >> of the vote tabulator if a quorum is not reached by then.) The
> >> voting rules are those for position papers.
> >>
> >
> > I vote YES on motion 19. - Dan
> >
> > P.S. - I know yes votes should go uncommented but I feel
> > I should point out that the recent discussion about this
> > motion excluding mid-rads is false. Motion 19 is, in
> > fact, designed to find a way to INCLUDE mid-rads in a
> > manner that does not water down the specifications for
> > inf-sup forms. Please don't vote on misinformation.
>
> I think you should expand your (in my view completely unsupported)
> claim by letting everyone know in which way this design allows
> what you claim it does.
>
> If the motion allows an implementation to conform to the standard
> if it has no infsup datatype, how can the standard require, say,
> the following two items:
> (i) provision of support for [0,inf] without overestimation
> (ii) a square root evaluation that is tightest
> (both very sensible and important requirements in the context of
> applications to solving constrained nonlinear systems and global
> optimization)?
>
> It is even difficult to motiviate why one should prescribe this just
> for an infsup implementation if provided, since the standard then
> makes very different requirements for infsup and midrad.
>
> Essentially, a standard modelled after this motion but restrictive
> for infsup must be of the form:
> (a) for infsup, require a lot,
> (b) for midrad require almost nothing
> (b) is necessary since there is neither theory nor practice that
> can tell what would be meaningful requirements in this case).
>
>
> I hope the majority of voters is rational enough to vote in a way
> that serves those having to live with the standard in the future,
> rather than voting to avoid dissens with a few who want the standard
> to reflect issues that in the past (and for good reasons0 never had
> enough life blood to lead to a serious implementation.
>
>
> Arnold Neumaier
>
Arnold,
You point out that an imlementation that conforms to a
standard that follows this motion must either
(a) conform to a form that is explicit for which inf-sup
forms easily qualify & about which we can say much that
is sure, or
(b) conform to a form that is implicit for which mid-rad
forms qualify & about which this motion has little to
say because we don't quite know what we can say that is
sure yet.
As opposed to a standard that does not follow this motion
about which we must either
(a) say very little about how either form conforms, or
(b) exclude mid-rads altogether in favor of inf-sups.
So it is failure to pass this motion that threatens to
either gut the standard or eliminate mid-rads, not the
reverse.
We can go as you please but I prefer to consider the
possibility that mid-rad forms have merit. Just how
we are to restrict their behavior in any meaningful
way is the subject of some future motion written by
those who know this subject far better than I.
Let's see what they come up with rather than assume
their failure from the beginning.
Dan