Re: Constructors motion
> Subject: Re: Constructors motion
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: Tue, 27 Dec 2011 11:47:29 +0000
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dan, Nate, P1788
>
> (Written while full of Christmas turkey, before looking at the =
> subsequent postings on this topic)
(Replied to on the morning of the 27th, after playing
with my toys, my favorite of which is a Kindle. :-)
>
> On 17 Dec 2011, at 10:29, Dan Zuras Intervals wrote:
> > (John Pryce wrote:)
> >> ... Kaucher
> >> intervals are different. I had always assumed (I think this is =
> explicit
> >> in some of our correspondence right at the start of the project) that
> >> there will be a separate clause of P1788 called something like
> >> "Extensions and changes to the standard for Kaucher intervals".
> >
> > So is it well understood at this point that excluding
> > Kaucher intervals (at this point) is a GOOD thing?
> >
> > If they are excluded ONLY for the lo <= hi thing, can
> > they not be included by a Kaucher decoration which
> > reverses that?
>
> A "Kaucher decoration" is a design choice I hadn't thought of. I had =
Actually, I mentioned it in passing in the early days of
the discussions which led to the notion of decorations.
I also mentioned things like continuous & unbounded which
went away over time.
> always assumed one is computing EITHER in normal interval mode, OR in =
> Kaucher mode, and that the two modes have separate libraries. Your idea =
> seems to incur an overhead because dispatching of operations must, =
> potentially, be done at run time instead of compile time. And then there =
> is the semantics of mixed-mode operations to consider ...
Were there a Kaucher decoration, this would be true.
However, Nate convinced me that one can do without a
decoration & still do both normal & Kaucher for no
more than the cost of normal. See below & some of
the followup notes.
>
> I think we need to decide this soon. At first glance I do NOT like this =
> way of doing things.
Yeah, neither did Nate. And I think you are both right.
>
> John=
John,
I threw it out there thinking that the rules governing both
Kaucher & normal intervals seemed the same so long as you
knew which was which. Thus, a Kaucher decoration to store
that information.
But in our subsequent private (as I recall) conversations
on the subject, Nate convinced me that I was wrong on
several fronts.
First, it is not necessary to tell the constructor which
kind of interval was being constructed. It is sufficient
to have two constructors: one for normal intervals & one
for Kauchers.
Nate went on to tell me that the run time work required
of a routine that handled both Kaucher & normal intervals
(what I called Kaucher-savvy) was typically no more than
a similar routine for normals only (Kaucher-naive).
I will let Nate discuss that but it suggested to me that
we could consider the normal portion of our standard as
being a proper subset of a Kaucher standard. It suggests
that a conforming implementation could either conform at
the level of normal intervals or be augmented to include
those things that are needed to conform at the level of
Kaucher intervals.
Indeed, it suggests that we need not have a normal-only
level of conformance at all. That a user may use Kaucher
intervals or not, as is appropriate to the task at hand.
However, I hesitate to suggest that on ground of political
controversy within our group.
Therefore, I merely suggest that we make sure that there
is nothing required of the normal conformance of our
standard that is inconsistent with or contradicts a
Kaucher extension. Simply stated, the behavior at the
normal level is a strict subset of the behavior at the
Kaucher level.
Nate argues that this is both possible & of comparable
run time efficiency. I will let him make that case.
But if we find we can approach the standard in this way,
it greatly simplifies our task.
Don't you think?
Dan