[no subject]
On (Fri, 14 Nov 2008 21:05:30 -0100), Siegfried Rump wrote:
> - some computation is performed,
> - maybe flags are cleared,
> - some variable x is computed, and
> - now x is transformed into an interval variable y by type cast.
Ok, we are indeed "on the same page" now.
I can easily believe that your approach works in (nearly?) all
practical cases, as the situations I have described as "possible"
may not been seen in practice -- or lead to much more severe
problems so that the fine point under discussion here is the
least of the troubles.
I am however of the persuasion that even edge cases never seen in
practice have to be covered by a proper interface design, and that
is the issue here.
You did not comment on Arnold's new realHull(x,x) vs intval(x), where
the programmer will have a choice. As I said earlier, that only leaves
the issue of implicit conversion. The latter happens to be what you
are most concerned about, I think. So perhaps we should let amateur
programmers get the practical results they expect, and let professionals
use explicit conversions with control over applicable rules.
> > One more point I'd like to make in favour of intval(Inf)=Empty:
> > It preserves the relation isIn(x,intval(x)) for all floats x
> > (in the model where the underlying range is Non-extended Reals).
>
> Do you mean "for all finite floats x"? Otherwise (in Arnold's proposal)
> x=inf is not a member of intval(x)=Empty.
I was indeed careless here; Arnold Neumaier put it much better:
xx = number2interval(x) implies isIn(x,xx)=isEmpty(xx).
I agree that this works for finite floats under your model too,
but the implication above holds for Inf and NaN as well.
> I don't like flags. I think any arithmetic including IA should be
> usable for casual users - who may not even know about the existence
> of such a flag.
That's a valid concern -- but strategically-placed tests for Empty
should work quite well too.
Michel.
Sent: 2008-11-14 23:12:52 UTC