___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thomas Wenisch wrote:
> Hi,
Hi Thomas,
First of all, thanks for the report.
>
> for_each seems to be unable to deal with empty lists, or lists that
> are built by push_front on an empty list. However, vectors work
> fine. Here is code which demonstrates the problem. Replacing list with
> vect
Hi Beman,
- Mensaje Original -
[...]
> * The "multiindex_set" name seems awkward to me. Maybe
> "indexed_set" or
> "set_index"?
I don't like the name either, and would be happy if someone comes
with something better. Nevertheless, I don't think indexed_set is a
good choice: when pickin
> Above form wouldn't should
> mismatched values and this is most important.
I meant: Above form wouldn't *show* mismatched values and this is most
important.
Gennadiy.
-
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boos
> A half-way solution is to have something like:
>
> BOOST_CHECK_EQUAL_NUMBERS(x,y,IsEqual)
>
> and let users specify their own Preciates.
There is BOOST_CHECK_PREDICATE
> By default, the Test library could provide
> a straight-forward ABSOLUTE-ERROR comparator:
By default, the Test library p
> >What's most of the time needed is relative precision.
> >
> >So, numerical gurus: how can one express "a equals b within
> 0.1%" over >the whole range of floating point numbers? If
> that can be done, it would >be a nice useful routine. >
> >bool approximately_equal(double lhs, double
I've updated the current Boost.Random CVS to the interface
contained in the C++ library TR proposal:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html
The boost documentation has not yet been updated, I hope to be able
to do that later this week. Reading the TR proposal should g
Beman Dawes <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> At 02:22 PM 7/7/2003, Rozental, Gennadiy wrote:
>
> >I could probably prohibit usage of CHECK_CLOSE with number of rounding
> >errors provided.
> >Is there any other general recommendations how to choose the tolerance
to
>
At 03:15 PM 7/7/2003, Joaquín Mª López Muñoz wrote:
>Please find some preliminary documentation for multiindex_set
>at:
>
>http://groups.yahoo.com/group/boost/files/multiindex.zip
Hi Joaquín,
I took a quick look at multiindex.html, and found it quite interesting. It
appears to meet a common need
John Maddock wrote:
Looking at the boost regression test results, it seems that Intel on linux
defines _WCHAR_T (which is what the EDG front-end documentation specifies
for wchar_t support), so I used that as the test - should be in cvs now -
can you check that it does the right thing?
integer_tra
At 02:22 PM 7/7/2003, Rozental, Gennadiy wrote:
>I could probably prohibit usage of CHECK_CLOSE with number of rounding
>errors provided.
>Is there any other general recommendations how to choose the tolerance to
>FP computation correctness checking?
There has been some recent discussion on com
Hi Fernando (and all others)
Please find some preliminary documentation for multiindex_set
at:
http://groups.yahoo.com/group/boost/files/multiindex.zip
The documentation is far from complete, but a reasonably complete
rationale is given which hopefully will guide the reader through the
design co
> Let t be tmp and e? be error values (smaller than ulp/2).
>
> rounded(rounded(t*t) - t)
> = ((t*t) * (1+e1) - t) * (1+e2)
> = t*t - t + t*t * (e1+e2+e1*e2) - t*e2
>
> So how much is the relative error? For example, if e1=ulp/2
> and e2=0, the absolute error reaches t*t*ulp/2 = 0.605*ulp.
Hi,
for_each seems to be unable to deal with empty lists, or lists that
are built by push_front on an empty list. However, vectors work
fine. Here is code which demonstrates the problem. Replacing list with
vector makes the code compile.
#include
#include
#include
#include
#include
#inclu
"Joel de Guzman" <[EMAIL PROTECTED]> writes:
> Alexander Nasonov <[EMAIL PROTECTED]> wrote:
>
>>> From user point of view it's easy. Every class is described using intuitive
>> class-decl-like style:
>>
>> void describe_Driver(descriptor& class_)
>> {
>> class_("Driver").derived_from()
>>
Fernando Cacciola <[EMAIL PROTECTED]> wrote:
> Fernando Cacciola <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> Thanks to Gabriel we may have an is_nan() right now.
>>
> Oops!
> It was Joel de Guzman who offered his is_nan() implementation.
>
> Sorry Joel :-)
No problem. I
Fernando Cacciola <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Thanks to Gabriel we may have an is_nan() right now.
>
Oops!
It was Joel de Guzman who offered his is_nan() implementation.
Sorry Joel :-)
Fernando
___
Unsubscribe &
IMHO, the problem with test_fp_comparisons is that it is
fundamentally flawed.
As Guillaume said, ULPs just don't add.
The approach of trying to bound the relaive error based
on the number of roundings, which is what is intended,
just doesn't work, and it won't work no matter how
you try the adjust
Jon Biggar said:
> There is actually one case that needs a semaphore that has no reasonable
> alternative in pthreads. The only pthread synchronization operation
> that is asynch-reentrant safe (i.e. can be called from a signal handler)
> is signaling a pthread semaphore.
>
> It would be nice
> I found a problem with the intel configuration for Linux.
> For that compiler the macro BOOST_NO_INTRINSIC_WCHAR_T
> gets defined although the compiler has an intrinsic wchar_t.
>
> Neither _WCHAR_T_DEFINED nor _NATIVE_WCHAR_T_DEFINED is
> defined on Linux. __WCHAR_TYPE__ is defined to int. Never
Alexander Nasonov <[EMAIL PROTECTED]> wrote:
>> From user point of view it's easy. Every class is described using intuitive
> class-decl-like style:
>
> void describe_Driver(descriptor& class_)
> {
> class_("Driver").derived_from()
> [
> member(&Driver::licence_id, "licence_id"),
Jon Biggar wrote:
[...]
> There is actually one case that needs a semaphore that has no reasonable
> alternative in pthreads. The only pthread synchronization operation
> that is asynch-reentrant safe (i.e. can be called from a signal handler)
> is signaling a pthread semaphore.
There's no such
This framework might be interested to those who wishes to read and write
members of classes using member-names. Stuff like serialization, messaging,
automatic binding of class members with GUI/Web forms and OODBs (although
they have ODMG C++ binding).
>From user point of view it's easy. Every c
Jeff Garland wrote:
In date-time there are several 'to_string' functions that provide
different ouput formats so a single 'str()' method isn't going
to be enough. As for c_str(), you can use this once you have
std::string. From my view there is no point in trying to force
fit this functionality
Hi Csaba,
> Iteration macros did not work without some 'using' directives because it
> uses functions from boots but actually without the boost:: qualifier.
>
> E.g. BGL_FORALL_VERTICES(v,g,graph_t) did not compile unless you have using
> namespace boost or using namespace boost::vertices before th
Hi,
Iteration macros did not work without some 'using' directives because it
uses functions from boots but actually without the boost:: qualifier.
E.g. BGL_FORALL_VERTICES(v,g,graph_t) did not compile unless you have using
namespace boost or using namespace boost::vertices before the invocation o
26 matches
Mail list logo
