Re: [boost] boost interval arithmetic

Subject: Re: [boost] boost interval arithmetic
From: Павел Кудан (coodan_at_[hidden])
Date: 2015-01-15 04:44:47

>> But misconception still exist.
>
>Yes, yours.

Not agree as my minor misconceptions on what is a value which boost class is going to return you are discovered and clarified. But main misconception of boost interval class is still here. Your very critical revision of this statement is good concept prove to statement that it is really true.
>
>> As a result of one of basic operator are still wrong.
>>
>> [-inf, inf] IS NOT [-inf, -1] U [1, inf]
>
>It doesn't claim to be. We could have a class union_of_intervals so we can 
>represent [1,2]U[3,4]U[5,6] for instance. But that would be super 
>expensive. What interval does is maintain one interval that contains all 
>possible values. It never claims that all values in this interval can 
>actually be achieved. It is a good compromise. And it goes as long as it 
>can. [-inf,inf] is still a valid interval. The one case where it *has* to 
>stop is when doing an uncertain comparison (or more precisely, when 
>converting such a comparison result to a bool). Returning true would be 
>wrong, and so would returning false, so it throws. For division, it has a 
>valid way to keep going: [-inf,+inf] so it uses it.

But misconceptions that it have to claim to be.

Every calculation is expensive. We again come to suggestion to decide 2 + 2 == [-inf, inf]. Are you agree to that suggestion? That is very good and cheap to not calculate anything. But if we claim that we are calculating something, the result must be exact at any price of throwing exception must be a result.

No, it is not. Moreover, it is misleading practice to give not correct result in a calculation.

And it is incorrect as essential information (upper bound of negative interval and lower bond of positive interval) is lost.

And there is at any rate a compromise it hiding essential exception from the library user.

If no correct result can be return, throwing exception must take place.

>
>Again, the meaning of an interval is that the correct value has to be in 
>that interval. The interval is not equal to the set of possible values, it 
>is a superset that can be determined cheaply. It tries to keep that 
>superset small, but only as long as it is cheap.

That is not a reason to give not correct return. Exception must be thrown in the case when correct return is not possible. There is no place for compromise here as correctness of result is not a matter of compromise.

Another problem you just mentioned is that native functions of interval class is oriented to give a set (probably, with some kind of order) of intervals and not to give a single interval as it is now. That is not, of course, misconception, that is just a way to implement this functionality. But still it points a developer mind to not very good direction - to think that a result of interval operation is really single interval. But it is not. In fact, generically, the result is a set. And it is normal for interval operations.

Result must not be cheap as there is no cheapest way than have no calculations at all. Result must be correct.

>As I said, I believe they have all moved to other projects and are not 
>interested anymore (though they are of course welcome to prove me wrong). 
>This list is as good as it gets.
Excuse me, I did miss something. Initially you said that they e-mails are not accessible any more, it may be caused by other reasons than lost interest in project participation... Sad news.

Any suggestion on new boost interval maintainers as strong as previous?

>It would be really helpful, if you intend to pursue this, to stop 
>considering that other people have no idea what interval arithmetic is. 
>There are several possible variants, see 
>http://grouper.ieee.org/groups/1788/ for the group working on 
>standardizing intervals. If you want a different one than what boost 
>provides, it may make sense, but that doesn't mean that everything else is 
>broken.
You now are suggesting to me do not explain obvious errors in concept of boost interval class to improve this class and to get rid of its mistakes. Statement that [-inf, inf] IS NOT [-inf, -1] U [1, inf], to my knowledge, is quite obvious. Does you really want to me stop reporting this mistakes?