Dear Marc, Thank you for your answer, I also tried to contact Mr.Gubenko, have no information about other maintainers. Please, excuse my bad English, I will try to explain in more detail, please, ask in something will be uncertain. Boost interval library was planned as extension of mathematical functions on float/double/double long or other singe numeric values to operations on intervals. The problem is that intervals have some specific. For example, if float value can be either > either < or = some other float value (statement ! (a>b) == (a <= b) is always true), for intervals it is not correct. Intervals can also overlap. That means that it is not possible for pair of overlapping intervals to say certainly which of them are greater than other. It is the intermediate situation, which is impossible with original single float values. And boost interval class has comparison operators and user can expect that they will behave in similar way with usual float comparison operators. For that reason, the behaviour of that comparison operators was made changeable and depends on some kind of policy, defined by user. Default behaviour is to throw exception when such intermediate situation (not possible for single float values) takes place. That was very wise solution, especially useful in very probable case, when some programmer will try to adapt some existing code with float calculation just changing type of value to boost interval. He will get exception in than exceptional situation - when usual float comparison operator is not applicable any more. That is OK. But as well boost interval class defines mathematical functions and operators. And user can expect that they also will behave similarly to usual float comparison operators. But great disappointment and multiple possible errors which is hard to locate is waiting for him here. Because it is not so. Arithmetic operators behave in completely different manner. Let's look on of most basic operator =/ and see what it is doing. But before let's see what is division of intervals and what is it's result. Boost interval class has two function - division_part1() and division_part2(). It is correct as when you divide one interval with another, the result will be single interval or a pair of intervals. The last situation takes place when in statement A / B, interval B cross a zero. That is not normal for intervals to have a pair of intervals as a result of division, but it is exceptional for single float numeric division. Now let's get back to /= operator and watch what he will do in such case. Let A = [1,2] and B = [-1, 1] and let's see what we will get after A /= B and what we should get. The true result of division in that case will be a union of pair of intervals [-infinity, -1] and [2, -infinity] Interval /=  operator, naturally, must return one interval. It is, obviously, impossible in this case - to return one of two. Again intermediate situation, not applicable to single float calculations. Again, throwing exception must be a result to let user know that he does not know what he are really doing. The same behaviour, as comparison operators. But it is not so. Instead of such natural behaviour, /= operator of boost interval class are doing impossible thing. It silently decides for itself which one of two parts of whole result to return and kill another part of whole solution somewhere under the scene. The result of A /= B will be [-infinity, -1]. Not correct result - as it is not complete. One of to parts is missing. Very very bad operator behaviour. User get not correct result and even does not know that it is so. It will be hard to find when this error is located, and when it will be done, library user will not think that he should know better what he are doing and learn some basics of interval arithmetic - no, he will accuse boost interval as part and boost as whole for bugs in libraries implementation. U nfairly , of course, but who cares. To correct it, at least, arithmetic operators and functions of interval class must behave similarly to comparison operators - throw exception in situations, not applicable for single float calculations. That is what I meant when said: "The difference in behaviour of comparison operators and basic arithmetic operators looks as probable misconception." I know, it is hard to understand, especially because bad English, but I hope it is important and hope it will help. Best regards, Pavel Wed, 14 Jan 2015 12:16:56 +0100 (CET) от Marc Glisse <marc.glisse@inria.fr>:

On Tue, 13 Jan 2015, Павел Кудан wrote:

...

The difference in behaviour of comparison operators and basic arithmetic operators looks as probable misconception.

Default and changeable behaviour of comparison operators consists in throwing exception in intermediate situation (intersecting intervals, ! (a>b) == (a <= b) is not applicable). Great decision for correct migration from float numeric code.

The only and unchangeable behaviour of arithmetic operators consists in silent returning only one of possible intervals in intermediate situation (possible return is not single, multiple interval result). The source of mistakes and undesired behaviour at migration from float numeric.

At least, throwing exception by arithmetic operators at intermediate situation would provide behaviour unity of comparison and arithmetic operators and functions.

Hello,

I have a hard time understanding your post. Could you try explaining it again, maybe with more concrete examples of what boost is doing, what you would like instead and why?

(I don't think this code is maintained, at least the email addresses of all the maintainers are outdated)

-- Marc Glisse

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

P. Coodan

(you seem to have missed the content of my previous reply, so warning: my reply is in the middle of your message, top-posting is considered wrong on this list) On Wed, 14 Jan 2015, Павел Кудан wrote:

Simple example.

Say, we are trying to estimate some physical value with interval calculation depending on some measured values (as values are measured, they are not exact, known to us as some ranges of possible values, it's quite natural to use interval calculations here).

Let it be some mass.

A = [1,2] B = [-1, 1]

M = A / B

Calculated result with boot interval is [-infinity, -1].

It gives [-inf,+inf] for me. If you get something different, please file a bug report in https://svn.boost.org/trac/boost/ with a compilable example and as much information as you can so we can reproduce your result.

OK, but mass cannot be negative...

Correct part of answer [1, infinity] which means that we have at least estimation of minimum for calculated value is lost...

-- Marc Glisse

On Wed, 14 Jan 2015, Павел Кудан wrote:

You are wrong that time but where right last time (in the answer which I did not initially noticed), when give another answer ' Actually, [-inf,-1][1,+inf]'.

Now you can see on own and mine example how special is interval arithmetic. Float arithmetic experience almost absolete here. I calculated - and make mistake in one value and typo in another ( [2, -infinity] instead of [1, infinity] ). You tried twice - and got complitely different results (one is correct, another not). Boost interval class must be perfectly behavioured to protect user from mistakes.

But problem not in values of bounds. The problem is that documented behaviour of boost interval / operator in that case will be to return [-inf, -1] and silently kill [1, inf]. But it must throw exception in such case.

On the other hand, interval boost acting here fully according its documented concept. That behaviour is documented. But not correct. So it is not bug. It is misconception.

That is why I tried to find its maintainers here to disscuss...

I tried the following program: #include <boost/numeric/interval.hpp> #include <iostream> typedef boost::numeric::interval<double> I; int main(){ I a(1,2); I b(-1,1); std::cout << lower(a) << ',' << upper(a) << std::endl; std::cout << lower(b) << ',' << upper(b) << std::endl; a/=b; std::cout << lower(a) << ',' << upper(a) << std::endl; } and it prints: 1,2 -1,1 -inf,inf and not -inf,-1 as you claim. If you have code showing a different result, please post it. I can't see anything in the documentation that supports your claim. [-inf,inf] is the smallest interval containing all possible values for the quotient, so it makes a lot of sense to return that. Now, if I understand correctly, you would like to add a policy so that anytime an operation has a disconnected image, instead of bridging the gap, boost would throw. That would be useless in my applications (well, maybe a shortcut since once I get [-inf,inf] somewhere it tends to propagate, eventually to a comparison that will throw), but maybe it makes sense for yours... In any case, it doesn't look like it would hurt boost to add such an optional policy. So if you want to prepare a patch, someone might be willing to review and pull it. -- Marc Glisse

On Thu, 15 Jan 2015, Павел Кудан wrote:

...

I tried the following program:

#include <boost/numeric/interval.hpp> #include <iostream>

typedef boost::numeric::interval<double> I; int main(){    I a(1,2);    I b(-1,1);    std::cout << lower(a) << ',' << upper(a) << std::endl;    std::cout << lower(b) << ',' << upper(b) << std::endl;    a/=b;    std::cout << lower(a) << ',' << upper(a) << std::endl; }

and it prints:

1,2 -1,1 -inf,inf

and not -inf,-1 as you claim. If you have code showing a different result, please post it. I can't see anything in the documentation that supports your claim.

[-inf,inf] is the smallest interval containing all possible values for the quotient, so it makes a lot of sense to return that. Now, if I understand correctly, you would like to add a policy so that anytime an operation has a disconnected image, instead of bridging the gap, boost would throw. That would be useless in my applications (well, maybe a shortcut since once I get [-inf,inf] somewhere it tends to propagate, eventually to a comparison that will throw), but maybe it makes sense for yours... In any case, it doesn't look like it would hurt boost to add such an optional policy. So if you want to prepare a patch, someone might be willing to review and pull it.

In that case [-inf, inf] should be a result of any operation in the world :) As it is universal :)))

Note the word "smallest" in my explanation.

2 + 2 == [-inf, inf], is it true? :)

Of course - as it is somewhere between :)

Not true? Of course, not.

2 + 2 !=  [-inf, inf] and [-inf, inf] != [-inf, 1] U [1, inf]

[-inf,inf] is the smallest interval containing both [-inf, 1] and [1, inf]. It isn't possible to return a smaller interval that still contains all possible values.

Let's see presentation about boost interval and interval arithmetic.

https://www.lri.fr/~melquion/doc/03-rnc5-expose.pdf

On page 11: Functions can also be used to compute a pair of intervals: [1, 2] ÷ [−1, 1] = [−∞, −1] ∪ [1, +∞]. (that is not boost interval operator / yet, it is basic arithmetic operation for interval. That is what should be a result)

also, on page 5: [a, b] × [c, d] = [min(ac, bc, ad, bd), max(ac, bc, ad, bd)], [a, b] ÷ [c, d] = [a, b] × [1 ÷ d, 1 ÷ c] if 0 NOT ∈ [c, d]

(that is not boost interval operator / yet, but it is the way its result is calculated when zero is not inside of [c, d] interval (by the way, typo here - must be 'if 0 NOT ∈ (c, d)). And here official boost interval documentation

http://www.boost.org/doc/libs/1_37_0/libs/numeric/interval/doc/interval.htm

The operators / and /=  will try to produce an empty interval if the denominator is exactly zero. If the denominator contains zero (but not only zero), the result will be the smallest interval containing the set of division results; so one of its bound will be infinite, but it may not be the whole interval.

So, official documented result of / operator for that case is [-inf, 1] as it is smallest interval (the result of division_part1() function of boost interval class). And this result is not correct as it is not full.

Language barrier. You are grossly misunderstanding the documentation. "The set of division results" is [-inf,-1] union [1,inf]. "The smallest interval containing" this set is [-inf,inf]. It is NOT the same thing as the smallest connected component of the set. -- Marc Glisse

On Thu, 15 Jan 2015, Павел Кудан wrote:

...

Language barrier. You are grossly misunderstanding the documentation. "The set of division results" is [-inf,-1] union [1,inf]. "The smallest interval containing" this set is [-inf,inf]. It is NOT the same thing as the smallest connected component of the set.

Good news. In that case there is no bag in implementation of misconception.

But misconception still exist.

Yes, yours.

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. 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.

May be we could find a way to contact to class maintainers?

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. 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. -- Marc Glisse

My main aim is to help improving boost interval class as boost is proposal for C++ standard and interval calculations are important, although underestimated yet. And standard is not matter of mine or yours mathematical preferences, implementation must be perfect to be standard. It must be correct and free of any mistakes. If you are still ready to listen to me, I can prove to you, that documented behaviour: The operators / and /=  will try to produce an empty interval if the denominator is exactly zero. If the denominator contains zero (but not only zero), the result will be the smallest interval containing the set of division results; so one of its bound will be infinite, but it may not be the whole interval. contains one more misconception then I already reported. But before it I would like to ask you if you are agree that the fact that statement [-inf, inf] IS NOT EMPTY is true?

That's not what the defintion that boost uses, boost gives you the smallest single interval in which the value will be. You are sugesting a "multi-interval". Not completely true.

I just suggest that arithmetic function does not return not correct results. And throw exception in the case when single interval cannot be returned - in same manner with boost interval comparison operators (default behaviour) in similar intermediate situation. To let user know that result is incorrect and he may use 'native' interval boost class functions (divide_part1(), divide_part2() in this case) to get correct result, as operator is not applicable to such situation any more.

The definition is very clear: it's the smallest *single interval* in which the value of the computation will be in. What you want is a multi-interval that excludes intervals where you know the value will never be in? That's a complete different definition, and it has a costs. I claim that kind of behaviour as 'misconception' for that reason. Current behaviour is wrong but is in full accordance to class documentation (as it was proved by Mark).

By the way, I think you will agree, that it is not important which is the cost of operation it's result are NOT CORRECT.

E.g. th eboost definition places a box around the Madelbrot set, what you want is and infinite set of boxes with mutual inclusions and exclusions that exactly capture the Mandelbrot set. When I do interval arithmic I don't want that, I want a single interval and that's what I expect from the documentation. Anything other will cause my computation to be slow and it will consume exponential memory. The problem you want single interval as a result of interval operation may be connected the details of class implementation. Single-interval-oriented design of functions force you to think that a result is single interval. But it is not true. In general case a result of interval operation is really the set of intervals. That is not misconception here, of course, that is just implementation detail, convenient for its authors.  But still.

Moreover, you have full right to expect single interval as a result of some operation, moreover again - some operators like /= by its design must return single interval. The simple question is that this single interval MUST BE correct or exception must be thrown to indicate

You are aware that there are different definitions of intervals, no? You want a different definition and call it a bug, but you should say that you want a multi-interval lib. Boost interval claims to be general purpose solution, expandable to many classes of intervals with its policies. And boost itself is claimed as C++ standard proposal. So there is no space here to cover mistakes and misconfiguration with answer 'It was a sly plan". Mistakes (which may exist in any code) must be found and corrected.

But it *can* return a single interval. Always. And that's the correct result given the definition being used: a single interval that encapsulated the value. You are looking for a different definition, one of many possible definitions.

But, please, tell are you agree that [-inf, inf] IS NOT [-inf, -1] U [1, inf] The hull of intervals (mentioned in documentation in some misleading way as a return value) is not intervals itself. In other case you must confess that 2 + 2 == [-inf, inf], as it is similar statement with [-inf, inf] == [-inf, -1] U [1, inf]

Comparison is different, you can't always return True or False when there is partial overlap of intervals. You can however have various comparison definitions that *do* result in always True or False, e.g. the comparison "guaranteed to be be *always* smaller". The problem is than there is no difference with comparison. Comparison throws exception in intermediate situation (operator not applicable due to intervals overlaping, certain comparison not possible). And arithmetic functions must also throw exception in intermediate situation (operator or function is not applicable due to not single interval result).

By the way, you just touched another behaviour properties of comparison operators of boost interval class - 'certain' and 'possible' comparison modes. Not sure that 'possible' mode adds some functionality, but definitely, its hard to locate error of comparison operator if comparison operator behaviour depends on namespace used :) But at any comparison mode arithmetic functions must return correct result. 'Certain' result, if you like, using term of boost comparison operators descriptor. Or throw exception, as comparison operators do.

There is no U decompositionin boost interval

As well a unite operation :) But the question is simpler - does statement  [-inf, inf] IS( [-inf, -1] U [1, inf])  have any sense from mathematical point of view. And another simple question is can class which pretending on inclusion in C++ have bad behaviour and return corrupted results instead of correct?

You can say

OR( [-inf, -1], [1, inf] ) -> [-inf, inf]

and also

 [-inf, inf] == OR( [-inf, -1], [1, inf] )

but there is no operator that decomposes and interval into subintervals.

But mathematics, nevertheless, is not limited to someone's conceptions or misconceptions. It even not is limited by lacks of some operators in someone's classes. Or we can state that 2 + 2 == [-inf, inf] and do no calculations :)

You are using a multi-interval argument to evaluate a single-interval library. That's wrong. A multi interval is not the same as a single interval, but we all know that...

OK, you say it wrong. But why doing this is wrong for me, and right for boost interval class? May be this class some kind of god - to make wrong things right? 'A multi interval is not the same as a single interval', as you just said. OK, but that is enough to conclude that  [-inf, inf] IS( [-inf, -1] U [1, inf]) is not true and this operator returns not correct result, no matter is the way it corrupts own result documented or not. And we all know that... having operator which silently returns not correct result leads to multiple other hardly located mistakes.

Thu, 15 Jan 2015 13:16:19 +0100 от "Thijs (M.A.) van den Berg" <thijs@sitmo.com>:

...

OK, but that is enough to conclude that [-inf, inf] IS( [-inf, -1] U [1, inf]) is not true and this operator returns not correct result, no matter is the way it corrupts own result documented or not.

No, you are wrong here again, you claim so much but demonstrate nothing. You seem to lack the ability to reason precisely and mix up set theory with numerical interval computations.

You should stick to pen and paper math, learn about logical inference

(A and NOT(A))->proves the earth is flat

 ,lean about numerical representation theory (like floats) and don't touch a computer or post in forums until you do that!

What in your opinion is the value of "d" in the following statement?

double d=1/3;

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

I would like you say me first that you really think that [-inf, inf] IS EMPTY, as I asked first. But, still, OK, double d=1/3 will contain a result of int operator/ as values you are dividing are int. So what? Next question you will ask will be a result of  'double d=1%3;' ???!

Since we are discussin boost interval, I'm going to use that definition of interval and not some irrelevant set theoretical definition.

 [-inf, inf] thus means: a computation using boost intervals as arguments returned another boost interval, and thus the value must be somewhere in that interval.

If not certain result is good, you must also be ready to accept [-inf, inf] as a result of 2 + 2 operation. As it is almost as exact as [-inf, inf] == [-inf, -1] U [1, inf] In both cases we have some inclusion. The not important difference is [-inf, inf] is not 'smallest' for 2 + 2 result. But we all know that... that what? ... hmmmm, probably, that we all have some shortages. So let's forgive it as well as we are forgiving boost interval for its obvious misconceptions? To be in interval and to be same interval is complete different things.

Don't you dare returning with a non-boost interval definition interval argument! (something involving set theory, multi-interval arguments, or Banach–Tarski )

My arguments are obvious, that is not my fault you are not going to lessen. That is strange.

  What *would* boost interval do in case of 2+2,.... and is that correct or not? I really do not know what exactly you decide to be correct for classes you create :) But as well as you are satisfied with not certain results for intervals, you may be satisfied as well with a result 2 + 2 == 5  for some kind of applications :)

On Thu, Jan 15, 2015 at 3:45 PM, Павел Кудан <coodan@mail.ru> wrote:

As who cares - it is somewhere in [-inf, inf], after all :)

Again you come up with hypothetical behaviour and then make fun of yourself. bah. You are wasting our time. Please post a C++ code ofexample and point out where the result deviated form the specs in the docs. If you can't then that means you're just trolling us.

What kind of arguments you would like after all? Do you really want to discuss misconception of the mathematical class it it's misconcepted terms?!

Thu, 15 Jan 2015 15:40:22 +0100 от Thijs van den Berg <thijs@sitmo.com>:

On Thu, Jan 15, 2015 at 3:18 PM, Павел Кудан < coodan@mail.ru > wrote:

...

What kind of arguments you would like after all?

Do you really want to discuss misconception of the mathematical class it it's misconcepted terms?!

No, that's irrelvant, we need to stick to the definitions of interval that boost interval claims to use, and discuss if the code adheres to those specs. I.e. way library users will expect and rely upon.

Generic set theoretical discussions are off-topic imo.

Ideally you'd post C++ code and show that it doesn't do what you expected based on the documentation, and not based on what you incorrectly think boost interval should be (a set algebra lib)

Not a set. Just 'certain' interval calculation with certain results. If result is single interval - return. If not - throw as it is not certain. That is simple. But you are right that it is not misconception of boost interval class, that is details of implementation, and, so, it is mine misconception. At least, IEEE Interval Standard Working Group lets developers to silently return [-inf, inf] in similar situations as one of multiple possible variants. These one is not best one for my taste, but it exists. Let's see what will be in final standard revision. I am still disagree with practice when functions silently return subset of result instead of true result, as it is bad practice. Very difficult to locate and debug. Till the moment interval calculation will be included in some form into C++ standard, I will prefer for basic interval operations my own simple interval class over boost's one. It may be naive and uses containers to return all results of native interval operation, but I do not see any problem in this approach.

On February 5, 2015 6:53:03 AM EST, Daniel Duffy <dduffy@datasim.nl> wrote:

Interval Arithmetic is well-defined (read Moore). I even had a chapter in it in Volume II of my Boost C++ books.

It's a big pity about these flames and the reactions. It would seem that Thijs vd Bergh has a normal question regarding this library? It should be possible to give an answer?

Is it not possible to discuss this without flames?

My recollection of the exchange is that the two principles eventually understood one another and the objection was withdrawn. The one seemed obtuse and the other highly frustrated during the exchange, but there was closure. As for your concern over flaming, if you read the full exchange, you'll see that the flames did not occur until related attempts to clarify the library's approach fell on deaf ears and began to suggest that the OP understood less than necessary to opine on the issue. Having made that excuse, I agree that it was overly harsh. ___ Rob (Sent from my portable computation engine)

On 15.01.2015 12:22, Павел Кудан wrote:

But at any comparison mode arithmetic functions must return correct result.

This[1] article mentions the following: "There is, however, no consensus on interval division. In most expositions, interval division, X/Y , is only defined under the condition that 0 not be contained in Y." "Interval computation involving division has to be a compromise between information gain, computational efficiency, and program complexity." "For efficiency in computation, one may choose to represent sets of reals by a single closed interval. This can be simply achieved by replacing <a, b> / <c, d> by the least interval con- taining it. For the example above this would yield the inter- val <−∞, +∞>. Another choice would be to represent this quotient as a finite union of closed intervals, which would result in more information but also a greater cost in storage and processing for the operation. For the example above, this would yield <−∞, 0> ∪ <1, +∞>, which captures all infor- mation except for the openness of the right endpoint of the first interval." I'm not very familiar with interval arithmetics, but I do work with some algorithms where it could be useful and as such have been looking into it some. A policy for how to handle divisions seems like a good compromise if it's not too difficult to implement, ie current behavior vs throw in cases where the result should technically be a union of intervals. [1]: http://fab.cba.mit.edu/classes/S62.12/docs/Hickey_interval.pdf - Asbjørn

On 15.01.2015 13:59, Павел Кудан wrote:

Please, tell our opinion. Can [-inf, inf] be empty?

I fail to see how that is relevant to the discussion of how interval division should be handled. - Asbjørn

On 15.01.2015 15:01, Павел Кудан wrote:

Now see:

[-1.0, 1.0] / .0

What is the correct result? Of course, [-inf, inf]

The way I understand interval arithmetics, the result is the set {x / 0 for all x in [-1, 1]}. Now, x/0 is undefined for all x in [-1, 1], so returning an empty set seems logical to me. - Asbjørn

On Thu, 15 Jan 2015, Asbjørn wrote:

On 15.01.2015 15:01, Павел Кудан wrote:

...

Now see:

[-1.0, 1.0] / .0

What is the correct result? Of course, [-inf, inf]

The way I understand interval arithmetics, the result is the set {x / 0 for all x in [-1, 1]}.

Now, x/0 is undefined for all x in [-1, 1], so returning an empty set seems logical to me.

For IEEE double, 1./0 is well defined as +inf, and -1./0 as -inf, so I agree that returning an empty set (apparently creating an empty set throws, with the default policy) is questionable, it depends on your application whether you want empty or [-inf,+inf]. I did not check if boost provides a policy to change that behavior. -- Marc Glisse

Sorry for misconception, in my turn. [-1, 1] / 0 cannot be [-inf, inf] as by standard for IEEE float the result of 0/0 is NaN. So, [-1, 0] / [0, 0] is empty is OK. Really sorry.

There is also another kind of misconception in description (and behaviour) of same /= operator of boost interval class. I can prove it if you will agree that [-inf, inf] is not empty interval at any rate :)

From mathematical point of view, of course. I does not try to estimate how much boost interval conflicts with own conception (although it does conflict - one politics for comparison and completely different for arithmetic). I am trying to show errors making whole boost interval obsolete in real interval applications. And what we are talking about (misconception in one of basic operators) is important thing of that kind. As without real applications, this class will be dead as unusable. So I would like that you confess that statement [-inf, inf] IS EMPTY is obviously not correct from the point of view of mathematics. Really obvious thing. Please, tell, what is your opinion on this simple subject? Thu, 15 Jan 2015 12:21:20 +0100 от "Thijs (M.A.) van den Berg" <thijs@sitmo.com>:

...

On 15 Jan 2015, at 12:04, Павел Кудан < coodan@mail.ru > wrote:

There is also another kind of misconception in description (and behaviour) of same /= operator of boost interval class.

I can prove it if you will agree that [-inf, inf] is not empty interval at any rate :)

The meaning of [-inf,inf] as the interval in which the answer will be requires that there is an answer in the first place.

You should no use a different definition other than the boost definition if you want to validate the boost implementation. If you don't then there is a bug in your way of thinking.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

P. Coodan

What does [a, b] mean in your opinion? In boost interval it means that the resulting value of a computation involving intervals is somewhere in that range. That is quite universal statement. Problem is boost interval itself conflicts with it.

As on that example value in interval [-inf, -1] U [1, inf] cannot be in the range (-1, 1). And boost interval class tells it can (on the example suggested by mine and implemented as test example by Mark)

It's not set theory, it's not multi-inverval. You can different results if you do operations in differen order... that's all fine because it's not about math but about numerical computations. So please stick to the boost definition is you want to discuss that. If you do that then I'll reply. That is the reason for function not able to return correct result MUST throw exception and MUST NOT return corrupted result instead. What kind of boost definition you need to discuss such an obvious practice?

Sorry for typo: [-inf, -1]