mirror of
https://github.com/boostorg/interval.git
synced 2026-01-30 20:02:14 +00:00
957a3ff2d7
From Guillaume Melquiond Tue Dec 5 10:13:03 2006 X-Apparently-To: ahd6974-boostorg -at- yahoo.com via 68.142.206.151; Tue, 05 Dec 2006 10:13:22 -0800 X-Originating-IP: [140.77.167.16] Return-Path: <guillaume.melquiond -at- ens-lyon.fr> Authentication-Results: mta300.mail.re4.yahoo.com from=ens-lyon.fr; domainkeys=neutral (no sig) Received: from 140.77.167.16 (EHLO pilet.ens-lyon.fr) (140.77.167.16) by mta300.mail.re4.yahoo.com with SMTP; Tue, 05 Dec 2006 10:13:22 -0800 Received: from localhost (localhost [127.0.0.1]) by pilet.ens-lyon.fr (Postfix) with ESMTP id 129B515BBB3 for <ahd6974-boostorg -at- yahoo.com>; Tue, 5 Dec 2006 19:13:21 +0100 (CET) Received: from pilet.ens-lyon.fr ([127.0.0.1]) by localhost (pilet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23702-21 for <ahd6974-boostorg -at- yahoo.com>; Tue, 5 Dec 2006 19:13:16 +0100 (CET) Received: from [140.77.13.110] (unknown [140.77.13.110]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by pilet.ens-lyon.fr (Postfix) with ESMTP id 61C6E15BB8B for <ahd6974-boostorg -at- yahoo.com>; Tue, 5 Dec 2006 19:13:16 +0100 (CET) Subject: Re: [boost] Need your permission to correct license & copyright issues From: "Guillaume Melquiond" <guillaume.melquiond -at- ens-lyon.fr> Add to Address Book Add Mobile Alert To: ahd6974-boostorg -at- yahoo.com [Edit - Delete] In-Reply-To: <20061204155943.25677.qmail@web33503.mail.mud.yahoo.com> References: <20061204155943.25677.qmail@web33503.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 05 Dec 2006 19:13:03 +0100 Message-Id: <1165342383.8556.52.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ens-lyon.fr Content-Length: 787 Le lundi 04 décembre 2006 à 07:59 -0800, Andreas Huber a écrit : > Hello Sylvain & Guillaume > > Quite a while ago it was decided that every file that goes into the > 1.34 release of the Boost distribution (www.boost.org) needs uniform > license and copyright information. For more information please see: > > <http://www.boost.org/more/license_info.html> I know about this page. But it does not seem clear to me that the license is fine for documentation files (they are the only ones missing a license statement, the code is fine). Especially as the first question of the FAQ only speaks about "source and header files". Anyway, I will let you judge of whether the license is adapted or not; and I give you permission to do the following on the files of the documentation: > 1. Replace the old license text with: > > "Distributed under the Boost Software License, Version 1.0. (See > accompanying file LICENSE_1_0.txt or copy at > http://www.boost.org/LICENSE_1_0.txt)" > > 2. (Optional) Run all html through HTML Tidy <http://tidy.sf.net> Best regards, Guillaume PS: you may want to take a look at your mail server, as your mails are categorized as spam because of the following checks: - DNS_FROM_RFC_ABUSE Envelope sender in abuse.rfc-ignorant.org - DNS_FROM_RFC_POST Envelope sender in postmaster.rfc-ignorant.org - DNS_FROM_RFC_WHOIS Envelope sender in whois.rfc-ignorant.org [SVN r36507]
205 lines
8.3 KiB
HTML
205 lines
8.3 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/html4/loose.dtd">
|
|
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Language" content="en-us">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
|
<link rel="stylesheet" type="text/css" href="../../../../boost.css">
|
|
|
|
<title>Comparisons</title>
|
|
</head>
|
|
|
|
<body>
|
|
<h1>Comparisons</h1>
|
|
|
|
<p>As was said before, the definition of the comparison operators induces a
|
|
slight problem. There are many ways to define them, depending of the return
|
|
type or the expected order. It is the reason why the meaning of the
|
|
operators is not fixed once and for all.</p>
|
|
|
|
<p>The way the operators are defined could have been influenced by a
|
|
policy, as it is already the case for the rounding and the checking.
|
|
However, comparisons are more an external property of the the class rather
|
|
than an internal one. They are meant to be locally modified, independantly
|
|
of the type of the intervals.</p>
|
|
|
|
<p>The operators <code><</code>, <code><=</code>, <code>></code>,
|
|
<code>>=</code>, <code>==</code>, <code>!=</code> are defined each time;
|
|
and like the arithmetic operators they can take an argument of the base
|
|
type. However, due to technical limitations, this base type can only be the
|
|
second argument; so the operators are unfortunately not fully symmetric.
|
|
The return type is not always <code>bool</code>, since some interesting
|
|
results can be achieved by using a tri-state return type. So here is the
|
|
common signatures of the operators:</p>
|
|
<pre>
|
|
template<class T, class Policies1, class Policies2>
|
|
return_type operator== (const interval<T, Policies1>&, const interval<T, Policies2>&);
|
|
|
|
template<class T, class Policies>
|
|
return_type operator== (const interval<T, Policies>&, const T&);
|
|
</pre>
|
|
|
|
<h2>vided comparisons</h2>
|
|
|
|
<h3>Default comparison</h3>
|
|
|
|
<p>If nothing is specified, the meaning of the comparison operators are an
|
|
extension of the operator on the base type. More precisely, if one of the
|
|
argument is invalid or empty, an exception is thrown. If the arguments are
|
|
valid, the following rules are applied to determine the result of
|
|
[<i>a</i>,<i>b</i>] <code>op</code> [<i>c</i>,<i>d</i>] (just consider
|
|
<i>c</i> <code>==</code> <i>d</i> if the second argument is of type
|
|
<code>T</code>):</p>
|
|
|
|
<ul>
|
|
<li>if ∀ <i>x</i> ∈ [<i>a</i>,<i>b</i>] ∀ <i>y</i>
|
|
∈ [<i>c</i>,<i>d</i>] <code>(</code><i>x</i> <code>op</code>
|
|
y<code>)</code>, then <code>true</code></li>
|
|
|
|
<li>if ∀ <i>x</i> ∈ [<i>a</i>,<i>b</i>] ∀ <i>y</i>
|
|
∈ [<i>c</i>,<i>d</i>] <code>!(</code><i>x</i> <code>op</code>
|
|
y<code>)</code>, then <code>false</code></li>
|
|
|
|
<li>otherwise throw an exception.</li>
|
|
</ul>
|
|
|
|
<p>This comparison allows to replace base types by interval types without
|
|
changing the meaning of a program. Indeed, if no exception is thrown, the
|
|
result is the same as before; and if an exception is thrown, the previous
|
|
comparison was unsure and should have been rewritten.</p>
|
|
|
|
<h3>Other comparisons</h3>
|
|
|
|
<p>The other comparisons are selected by using a namespace. These
|
|
namespaces are located under
|
|
<code>boost::numeric::interval_lib::compare</code> and are invoked by:</p>
|
|
<pre>
|
|
using namespace boost::numeric::interval_lib::compare::the_comparison_to_select;
|
|
</pre>
|
|
|
|
<p>After this line, the default meaning of the operators will have been
|
|
replaced by the meaning located in the namespace. Please note that because
|
|
of C++ lookup rules, it is not possible to use two namespaces one after
|
|
another and they must be used in different block hierarchies. Otherwise the
|
|
compiler will complain about ambiguous operators. To summarize:</p>
|
|
<pre>
|
|
// example 1: BAD
|
|
using namespace compare1;
|
|
...
|
|
using namespace compare2;
|
|
...
|
|
|
|
// example 2: GOOD
|
|
{ using namespace compare1;
|
|
... }
|
|
{ using namespace compare2;
|
|
... }
|
|
|
|
// example 3: BAD
|
|
using namespace compare1;
|
|
...
|
|
{ using namespace compare2;
|
|
... }
|
|
</pre>
|
|
|
|
<p>Now comes the list of the provided comparisons. They all are located in
|
|
their respective header files under
|
|
<code><boost/numeric/interval/compare/...></code>. And as for the
|
|
default comparison, the operators will generally complain by throwing an
|
|
exception if feed by invalid values.</p>
|
|
|
|
<ul>
|
|
<li><code>certain</code>: this comparison is equivalent to the default
|
|
scheme with the exceptional case mapped to <code>false</code>. So these
|
|
operators answer <code>true</code> only when the comparison is verified
|
|
for all pairs of elements.</li>
|
|
|
|
<li><code>possible</code>: this time, the exceptional case is mapped to
|
|
<code>true</code>. The operators answer <code>true</code> as soon as the
|
|
comparison is verified for a pair of elements.<br></li>
|
|
|
|
<li><code>lexicographic</code>: the lexicographic order (the lower bounds
|
|
are first compared, and if it is not enough to know the result, the upper
|
|
bounds are then compared). This order does not have a meaning in interval
|
|
arithmetic. However, since it is the natural total order on pair of
|
|
(totally ordered) numbers, it may be handy in some cases.</li>
|
|
|
|
<li><code>set</code>: the set inclusion partial order. This time, an
|
|
empty interval is not considered to be invalid (but an invalid number is
|
|
still invalid). <code><=</code> and <code><</code> are the subset
|
|
and proper subset relations; and <code>>=</code> and <code>></code>
|
|
are the superset and proper superset relations.</li>
|
|
|
|
<li><code>tribool</code>: this comparison relies on the Boost tristate
|
|
boolean library and changes the default operators so that an explicit
|
|
indeterminate value is returned in the third case instead of throwing an
|
|
exception.</li>
|
|
</ul>
|
|
|
|
<h3>Exception</h3>
|
|
<pre>
|
|
namespace boost {
|
|
namespace numeric {
|
|
namespace interval_lib {
|
|
|
|
class comparison_error: std::runtime_error; // "boost::interval: uncertain comparison"
|
|
|
|
} // namespace interval_lib
|
|
} // namespace numeric
|
|
} // namespace boost
|
|
</pre>
|
|
|
|
<h2>Explicit comparison functions</h2>
|
|
|
|
<p>In some situation, you may want to perform direct comparisons on the
|
|
bounds and avoid the indeterminate case that appears with default
|
|
operators. Some functions are provided for this purpose. They expect their
|
|
arguments to be valid and return a result after only one comparison. Their
|
|
names are composed by <code>cer</code> (for "certain", if the default
|
|
comparison is true, the result is true) or <code>pos</code> (for
|
|
"possible", if the default comparison is false, the result is false)
|
|
followed by <code>lt</code>, <code>le</code>, <code>gt</code>,
|
|
<code>ge</code>, <code>eq</code> or <code>ne</code>. They are located in
|
|
<code><boost/numeric/interval/compare/explicit.hpp></code>. Each of
|
|
these functions takes two parameters and returns a boolean; the parameters
|
|
are expected to be valid, undefined behavior may result otherwise. For
|
|
example, the definition of the "certainly less than" comparison is:</p>
|
|
<pre>
|
|
namespace boost {
|
|
namespace numeric {
|
|
namespace interval_lib {
|
|
|
|
template<class T, class Policies1, class Policies2>
|
|
bool cerlt(const interval<T, Policies1>& x, const interval<T, Policies2>& y);
|
|
|
|
template<class T, class Policies>
|
|
bool cerlt(const interval<T, Policies>& x, const T& y);
|
|
|
|
template<class T, class Policies>
|
|
bool cerlt(const T& x, const interval<T, Policies>& y);
|
|
|
|
} // namespace interval_lib
|
|
} // namespace numeric
|
|
} // namespace boost
|
|
</pre>
|
|
<hr>
|
|
|
|
<p><a href="http://validator.w3.org/check?uri=referer"><img border="0" src=
|
|
"http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional"
|
|
height="31" width="88"></a></p>
|
|
|
|
<p>Revised
|
|
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%Y-%m-%d" startspan -->2006-12-24<!--webbot bot="Timestamp" endspan i-checksum="12172" --></p>
|
|
|
|
<p><i>Copyright © 2002 Guillaume Melquiond, Sylvain Pion, Hervé
|
|
Brönnimann, Polytechnic University<br>
|
|
Copyright © 2003 Guillaume Melquiond</i></p>
|
|
|
|
<p><i>Distributed under the Boost Software License, Version 1.0. (See
|
|
accompanying file <a href="../../../../LICENSE_1_0.txt">LICENSE_1_0.txt</a>
|
|
or copy at <a href=
|
|
"http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</i></p>
|
|
</body>
|
|
</html>
|