Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Motion 11 questions & comments...



	Marco,

	I will give you my comments more in the form of questions
	& suggestions rather than criticisms.


	In your definitions section, Corollary 1 states that the
	3-op form of an reverse operation is equivalent to the
	expression (B (rev-op) C) \intersect X.

	Given that this is so, do we really need to define 3-op
	forms in the standard?

	It is common today to have expressions like a*b + c
	recognised by the compiler & replaced with the 3-op form
	of fused multiply add when it is supported in hardware.

	If it is your desire to see the 3-op forms of reverse
	operations in hardware as well, I'm sure it is a simple
	matter for compilers to recognise the associated
	expression & compile to them.

	In 754, we went ahead & defined a fused multiply add (FMA).
	The reason for that is that FMA is formally different than
	the expression a*b + c & we needed to pin the meaning down
	lest imaginative things happen in the future.

	But, here, you formally define the 3-op form as equivalent
	to the expression.  Thus it seems we have no need to pin
	anything down with a definition of that form.  We might
	note the equivalence in an informative note but we really
	need nothing more.


	I am confused about the definitions of reverse operations
	in sections 3 & 4.  But this may be due to my confusion
	about reverse operations in general.

	Please be patient for a bit while I explain my confusion.

	I have noticed that in the ordinary forward addition of
	A + B = C we have that width(A) + width(B) = width(C).
	Also, in subtraction A - B = C we have width(A) + width(B)
	= width(C).  So widths add in the forward add & subtract
	operations.  Things can get wider but not narrower.

	And yet in sections 3 & 4 you define reverse add &
	subtract to be formally equivalent to subtract & add
	(respectively).  The widths must add again.

	But in reverse operations shouldn't the widths get narrower
	not wider?  Indeed, is that not the whole point of such
	operations?

	That is, if I am trying to solve the equation A + B = C
	for B by using the expression B = C - A, I get a B that
	is wider than the interval that solves the equation.

	The reason for this is that there is no additive inverse
	for non-zero width intervals among the ordinary intervals.
	A + (-A) is not [0,0] in general.

	So in the reverse add needed to solve for B do I not need
	a definition of the form reverse-add(C,A) = {all b such
	that for all a in A there exists c in C such that a + b
	= c}?

	I grant that the definition you have appears equivalent
	to the third line &, thus, equivalent to ordinary forward
	subtract.

	But how can that be?  If I am using the reverse add to
	solve for B in A + B = C (for which width(A) + width(B)
	= width(C)), I need a B such that width(B) = width(C) -
	width(A).  But if I use B = C - A I have that width(B)
	= width(C) + width(A).

	It seems to me I had this discussion with John & Nate
	about a year ago & Nate's solution involved using both
	'there exists' & 'for all' quantifiers.

	I may have this wrong.  Perhaps Nate can help here.


	In each of Tables 1 & 2, the reverse multiplication,
	there are 6 entries that contain zero in the interior
	of the A operand that produce results that are the union
	of two disjoint intervals.  Similarly for 12 entries in
	Tables 3 & 4, reverse divide 1, for zero in the interior
	of operand B.  And many entries in Tables 5 & 6, reverse
	divide 2.

	But since your definitions of reverse multiplication &
	division use the hull operator, should not these entries
	be the hull of those disjoint intervals?

	If the answer to this is yes, then these many entries can
	be fixed & there is no further problem.

	But if the answer to that is no, we are now in the realm
	of defining operations whose result is not an interval
	but something else.

	I think that will require much discussion all on its own.


	Well, that's all I can think of at the moment.

	I understand from your postings that you are already
	working on another version of this proposal.

	I hope my comments have come along in time to be
	considered for that proposal.

	Thanks,

				Dan