Re: Basenote drift to the value of mid-rad forms...
> Date: Mon, 13 Sep 2010 16:47:59 +0200
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: Basenote drift to the value of mid-rad forms...
>
> I just resent the previous mail to the whole list which was my
> intented audience.
>
> Since you answered off-list, I answer this also offlist.
> If you resend your mail to the list, I'll resend this to the list.
>
> Alternatively, you could create a new reply to my previous mail,
> taking into account what I say below.
I'll do that.
Folks, here is a short private exchange between
Arnold & I which should have been made public.
>
> -----------------------------------------------------------------
>
>
> Dan Zuras Intervals wrote:
> >> Date: Mon, 13 Sep 2010 13:00:36 +0200
> >> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> >> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> >> Subject: Re: Basenote drift to the value of mid-rad forms...
> >>
> >> Dan Zuras Intervals wrote:
> >>>> . . .
> >>>>
> >> The Vienna Proposal is very clear, down to every relevant detail.
> >> We spent a lot of work creating it, and I am not prepared to repeat
> >> this.
> >>
> >> It still stands as the position of our group, apart from two points
> >> that only evolved later:
> >> (i) Decorations should replace exceptions.
> >> (ii) I now promote a smaller set of comparison operators,
> >> whereas the Vienna Proposal opted for a comprehensive scheme
> >> (which, however, resulted in many combinations of questionable
> >> usefulness).
> >>
> >> If you feel the need for a motion to decide the issues about not infsup
> >> matters beyond what is in Motion 16, you can copy part of the Vienna
> >> proposal, make it fit the structure delineated by the motions already
> >> passed, discuss the result with me if you like, and then turn it into
> >> a motion.
> >>
> >> The relevant passages are the following:
> >>
> >> . . .
> >>
> >> Arnold Neumaier
> >>
> >
> > You quote the relevant passages but not how you
> > would change them to accomplish what you seek.
> >
> > How would you do that?
>
> I don't want to change them. They express precisely what I want
> from the standard, except that the language is not wuite what
> evolved through the motions.
It takes time. Writing a document may be done
all at once by a lone author. But getting a
large group of people to agree to all its
details is an incremental process.
Trust that if it looks incomplete to you today,
it looks incomplete to everyone else too. We
will get it working step by step. No need to
condemn one step because the next is not there
yet.
>
> I don't think midrad deserved first class status.
Fair enough.
Still, I hope we agree that motion 19 separates
inf-sups (explicits) from mid-rads (implicits).
I think that is useful in that it allows us to
discuss explicits, ah, explicitly without needing
to consider the difficulties & uncertainties of
the implicits.
Sounds like a good first step whether you want
mid-rads in the standard or not.
It certainly simplifies part of our work.
>
>
>
> > Remember, I am the one who argued in favor of
> > a more first class status for mid-rad forms in
> > motion 19 by classifying them as implicits &
> > figuring out what that means later.
> >
> > My purpose was two fold. First, to separate
> > the inf-sups (explicits) from the mid-rads
> > (implicits) so that the former could be well
> > specified without the problems of the latter.
> > And to give the mid-rad folks time to figure
> > out how they wanted to well specify implicits.
> >
> > I believe that accomplishes getting rid of any
> > ambiguity when it comes to our further standards
> > work on explicits.
>
> Do you want to say: ''To conform to the standard, you either provide
> a very stringent infsup implementatation'' (which is what I find
> desirable from a practical point of view) ''or a very loose midrad
> implementation'' (since I believe that no implementable stringent
> midrad standard is possible, unless on prescribes the precise
> algorithms to implement).
Of course not. What I want to say is that to
conform to the standard you must provide a very
stringent explicit implimentation (which we can
specify today) or a very stringent implicit
implementation (which we cannot yet specify).
If, as you suggest, it turns out to be impossible
to characterize the behavior of implicit forms in
a reasonably reproducible way, I favor dropping
them in some future motion. And, having set them
apart from the explicits, that should be easy to
do.
However, if the mid-rad folks figure out how to
make their stuff work well from machine to machine,
I think they will have earned first class status.
If you believe that cannot be done then you agree
with the intent of motion 19 at least in so far as
you believe that will never come to pass.
But give them their shot.
>
> This is the only form of separation I can imaginge your poposal
> could possibly achieve.
>
>
> > And the mid-rad folks may or may not be able to
> > work things out, as you suggest. If they do,
> > fine. We put it in the text. If they don't,
> > also fine. Eliminating them from the standard
> > is easy to do once they are a separate object
> > with separate text to be deleted.
>
> But as it is now, the motion completely changes the form and
> content of Motion 16, introducing a terminology that only makes
> sense if they are successful (which is unlikely given what they
> produced within the last two years).
It does. New motions often modify old ones as
our understanding & approach changes. Get used
to it. It will happen a lot in the coming years.
As for the terminology, I think John's use of the
terms explicit & implicit goes well with the level
1 & 2 nature of his description & does not carry
all the implementation (& emotional) baggage of
the other terms.
So what if implicits cease to exist in the future?
If the term explicit becomes redundant with the
notion of a 1788 interval datatype (without modifier)
then we can propose some future motion to eliminate
all references to explicit. Also easy given this
motion.
>
>
> > You must not consider either Vienna or motion 16
> > as cast in stone never to be changed for all time.
>
> It is not, but both are cast much better than Motion 19.
Perhap so. If you now speak to the merits of
motion 19, that is fair. To each his own opinion.
>
>
> > At this point in our process, the nature of the
> > standard is a work in progress. We must be able
> > to change it as we learn more about our subject.
> > You have already acknowledged change in the form
> > of decorations rather than flags & modes. You
> > will see many more changes before we are done.
> >
> > Therefore, if motion 19 changes motion 16, so
> > be it. You can argue against the change on its
> > merits but not merely BECAUSE it is a change.
>
> It is a change to the worse.
>
>
> > But we get in motion 19 part of what you seek.
> > We split off all discussion of mid-rads from any
> > discussion of inf-sups.
>
> No. We get multiple idatatypes, which increases the formal
> complexity of the standard, and we get the option of midrad-only,
> which is the worst part of the motion.
Well, I think of it as separating those notions
rather than multiplying them. And each can be
considered individually much easier than both
together.
And mid-rad (or implicit) only would only be bad
if the implicits themselves turn out to be bad
in the end. If so, they can go. But I think
they deserve a shot at proving themselves.
I see you do not.
>
>
> > Is that not in keeping with your wishes?
>
> Not at all. We don't get anything of what I seek.
> But we undo Motion 16 which was in the right direction.
>
>
> > If not, what would you have us do?
>
> A possible motion text could be:
>
> The standard should not support a midrad interval format or
> nonstandard intervals, beyond providing conversion support,
> approximately to the extent specified in the Vienna Proposal.
>
Shall I make that motion for you?
May I make it "shall not support"?
Should or should not has no meaning, really.
Dan