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

Re: min / max and empty intervals (was: Friendly amendment to Motion 25)



All

On 6 Jun 2011, at 16:42, Vincent Lefevre wrote:
> On 2011-05-28 17:44:36 -0700, Dan Zuras Intervals wrote:
>>> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
>>> To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
>>> Subject: Re: Friendly amendment to Motion 25 
>>> Date: Sat, 28 May 2011 18:25:23 -0500
> [...]
>>> From discussions I've witnessed between you and Nick, I gather
>>> that in IEEE 754 the correctness of such a result is topic of a
>>> longstanding debate. I'm not taking sides as it pertains to IEEE
>>> 754. In regards to IEEE 1788, though, this would certainly lead to
>>> failure of certain important interval algorithms. So just to be
>>> clear: the description given in Motion 25 is really designed to
>>> ensure the result of interval min and max is empty if at least one
>>> operand is empty, just as it is for addition.
>> 
>> 	I understand but disagree.
>> 
>> 	Still, that might not be a problem.  Given that it has
>> 	no relation to the rest of your motion, may I suggest you
>> 	remove references to min & max so that we may have this
>> 	discussion at some later date & avoid needless conflict
>> 	with the rest of your motion.
> 
> I completely agree with Nate here. I think that min and max should
> first be seen as functions over the real numbers (thus necessarily
> 2-ary, at least with a fixed ariness).

I agree with Nate too. This discussion seems to have introduced extraneous ideas such as treating NaN and Empty as on the same level as real point-values. Such ideas were removed by motions early in our work.

There's no reason to object to max(x,y) and min(x,y) being ordinary point-functions of _real_ arguments and having interval extensions defined in the normal way as Nate and Vincent write.

BTW Arnold points out they should allow any number of arguments, as in Fortran. I have included this in the current draft v03.2 out shortly.

This is nothing to do with handling lists of intervals. It simply means max represents an (in principle infinite) family of functions
   max(x1,x2), max(x1,x2,x3), max(x1,x2,x3,x4), ...
each being of fixed arity known at compile time. No big deal.

John