Fwd: Comments on decoration ill, intersection and union
Nate
Getting back to work after Christmas, I see that my misinterpretation of your intersection/union formula seems to come from Jürgen, see the exchange below which you may have missed. Plus my revised wording.
However I reiterate: my view is that each flavor should define its own decoration system. So I look forward to a Kaucher flavor with decorations along the lines you propose.
I've made clear that (and I hope, why) I oppose decorated intersection/union for *general purpose* use. But if I understand right, in your applications Bezier splines and similar piecewise functions are workhorses that are evaluated many (hundred?) millions of times a day, and you know in advance that they are "dac". Then any way to reduce clock cycles is fair, especially if done on special-purpose hardware. In that context, decorated intersection/union that achieve this are a good idea.
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> Date: 20 December 2012 11:59:03 GMT
> To: Jürgen Wolff von Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Cc: nh@xxxxxxxxxxxxxxxxx, 'Vincent Lefevre' <vincent@xxxxxxxxxx>, 'stds-1788' <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Comments on decoration ill, intersection and union
>
> Folk
>
> On 18 Dec 2012, at 09:54, Jürgen Wolff von Gudenberg wrote:
>> There seems to be agreement that decorations concern point functions. And that union and intersection have no corresponding point operation.
>> But there seems to be agreement how to use them to define piecewise defined continuous functions.
>> So what do you think, if we offer this as an option
>> "An implementation may define propagation of decorations (for
>> piecewise defined continuous functions) in the way that
>> intersection propagates the max and union propagates the min" ?
>> That makes it more complicated and invokes the danger of misuse
>> but it may help to end this dead-ended discussion
>
> Something like that looks reasonable. How about
> "An implementation may define additional operations:
> intersectionDec(xx_dx,yy_dy) is as intersection(xx_dx,yy_dy),
> except that it decorates the result with max(dx,dy).
> and
> convexHullDec(xx_dx,yy_dy) is as convexHull(xx_dx,yy_dy),
> except that it decorates the result with min(dx,dy).
> A language may make either the standard operations, or these operations, its default operations for intersection and convexHull."
But Nate actually wrote on 2012/12/01, 17:19 GMT:
> ... decorated intersection provides the weakest decoration of the input operands according to the linear propagation order (much like an arithmetic operation); and decorated union provides the "tightest" decoration containing both of the input operands.
So it seems "max(dx,dy)" for intersectionDec should be "min(dx,dy)"; and "min(dx,dy)" for convexHullDec should be "the tightest decoration containing dx and dy in the containment order". (I assume by "weakest" you mean the min, because you say it is like an arithmetic operation.)
John Pryce