- Boost - lists.boost.org

FW: [Lambda] find_if + vector of arrays
by Sohail Somani 31 Jul '06

31 Jul '06

Hi, I'm forwarding this here as I didn't get a reply on the users list. > -----Original Message----- > From: Sohail Somani > Sent: Tuesday, July 25, 2006 2:19 PM > To: 'boost-users(a)lists.boost.org' > Subject: [Lambda] find_if + vector of arrays > > Hi, > > Why can't lambda figure out the return type of operator[] for > array? Does it know about vectors? I know I can fix the > compile error by using bl::ret<double>(bl::_1[0])... But for > obvious reasons, I'd much rather not! > > #include <vector> > #include <algorithm> > > #include <boost/array.hpp> > #include <boost/lambda/lambda.hpp> > > int main() > { > namespace bl=boost::lambda; > using std::vector; > using boost::array; > > array<double,3> cpy = {1}; > vector<vector<double> > a(10,vector<double>(3,1)); > vector<array<double,3> > b(10,cpy); > > std::find_if(a.begin(),a.end(),bl::_1[0]==5); > std::find_if(b.begin(),b.end(),bl::_1[0]==5); > } > > Thanks! > > Sohail >

1 0

Re: [boost] Computational Geometry Library
by Arash Partow 31 Jul '06

31 Jul '06

Mateusz Loskot wrote: >>Yes, there were a few discussions on the list. >>Here is a list of threads I've saved: >> >>This is one of the latest and very interesting: >>http://lists.boost.org/Archives/boost/2002/09/36142.php >> >>and other: >>http://lists.boost.org/Archives/boost/2004/06/66736.php >>http://lists.boost.org/Archives/boost/2001/08/16400.php >>http://lists.boost.org/Archives/boost/2000/11/6612.php >> >>Also, there are some prototypes: >>http://www.boost-consulting.com/vault/index.php?direction=0&order=&director… I've had a read of articles, and I like some of the ideas that have been presented and proposed. Its a shame that some of the better ideas haven't come to fruition as of yet. But heres hoping that will change sometime soon. >>I have no knowledge about any other efforts than listed above. >>I'm very interested in robust computational geometry library >>in Boost. So, I'd be also interested in some constributions. >> >>For last 6 months, I was working on the GEOS library: >>http://geos.refractions.net/ I had a look and it seems you've made a lot of progress, it would be good to begin integrating things at some point soon for an initial review submission. >>which is a *direct* port of JTS: >>http://www.vividsolutions.com/jts/jtshome.htm >>Unfortunately, GEOS follows JTS design and implementation almost step by >>step, so performance is not good. >>Note, GEOS is a library for GIS and it follows the OpenGIS Simple >>Features specification (www.opengeospatial.org/docs/99-049.pdf) >> >>I think, this specification may be interesting to read about >>"The Dimensionally Extended Nine-Intersection Model - DE-9IM" >>as a nice model of spatial/geometric relation operators. I had a quick read, isn't this all just some glorified minkowski difference thing? >>> > As for a preliminary library design I propose the following: >>> > >>> > * primitive geometric structures 2D/3D only >>> > (point,line,segment,triangle...) >>> > * operations between primitives (intersection, distance, inclusion...) >>> > * higher level algorithms in a structured fashion similar to BGL: >>> > * hulls, rotating caliper >>> > * triangulation (point sets, polygons) >>> > * boolean operations over polygons >> >> >>Boolean operations could be provided for every geometry type, >>see DE-9IM. Some geometric operations just don't make sense for certain pairs of types, hence not all geometric operations can be defined, all one can do is define/implement operations that do make sense. >>> > * precision related issues to be dealt with mainly by user >>> > specified floating point type, and partially at the algorithm level >> >> >>JTS and GEOS have quite good example of precision model. looked at it, seems like standard epsilon/fuzzy arithmetic - nothing special there. I believe one either needs to go down the path of "exact arithmetic" or to delegate the precision issues to the type the "user" chooses. From a "good library design" POV I believe that for the majority of things precision should be delegated to the users choice of type, and to hence maintain the simplicity of the calculation/algorithm's implementation. Say for example the closest point on a line from an external point is merely the dot product of the tangent from the external point and line, which is a very trivial thing. If one were to go down the path of exact arithmetic and you fall into problems such as determining the machine's FPU, its floating point precision etc... why not let the type take care of that, for most things double and float will be more than enough, for other things people may decided to use their own extended or arbitrary precision number types, such as the various rational and integer kernel types that come with CGAL, I believe the BOOST mathematics library will some day have its own extended precision real, rational and integer (bigint) types. >>Good idea. >> >>How about creating segments and linestrings (string of segments)? >>I imagine it could be also possible to pass range of std:: containers >>with iterators. >>But I also think about avoiding copying data from std:: containers to >>segments. May be it could be possible to have segments-view over >>standard containers or sth like that (views in terms of >>http://www.zib.de/weiser/vtl/) >>Extension idea: >>I'd also have an idea about extension for data (de)serialization. >>In GIS, there are two major formats to save/read geometries WKT - >>Well-Known Text and WKB - Well-Known Binary. >>Both have been invented by OpenGIS Consortium. >> >>Here are good examples of WKT: >>http://dev.mysql.com/doc/refman/5.1/en/gis-wkt-format.html >>and WKB: >>http://dev.mysql.com/doc/refman/5.1/en/gis-wkb-format.html >> >>I have some prototype of Spirit based parser to read WKT. Anything is possible, it just requires that knowledgeable people in the field be willing to chip-in. Arash Partow ________________________________________________________ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net

2 1

[statistics] design/interface reprise
by John Maddock 31 Jul '06

31 Jul '06

An updated overview of how I think the statistical test / distribution library interface might proceed is now available here: http://www.johnmaddock.co.uk/proposal/index.html As ever comments and suggestions welcomed. Thanks, John.

4 5

Numerical integration library?
by Frederick Akalin 31 Jul '06

31 Jul '06

I notice numerical integration was one of the items listed in the ExpandedMathematicsLibrary entry under WantedLibraries in the Wiki. Has anyone done any work on this? I've been looking into this problem space lately; I had the germ of an idea that, with the magic of templates, most ODE solvers (e.g. Euler, Runge-Kutta, etc.) could be written in a container-agnostic format and in a form closely resembling that which you would find in a textbook. (I can post some proof-of-concept code if this isn't clear.) I've looked around and haven't seen anything similar, but I'm no expert on scientific programming. Anyone else interested or have comments? Fred

5 4

Re: [boost] Numerical integration library?
by Wang Weiwei 31 Jul '06

31 Jul '06

>I notice numerical integration was one of the items listed in the >ExpandedMathematicsLibrary entry under WantedLibraries in the Wiki. Has >anyone done any work on this? I've been looking into this problem space >lately; I had the germ of an idea that, with the magic of templates, >most ODE solvers (e.g. Euler, Runge-Kutta, etc.) could be written in a >container-agnostic format and in a form closely resembling that which >you would find in a textbook. (I can post some proof-of-concept code if >this isn't clear.) I've looked around and haven't seen anything similar, >but I'm no expert on scientific programming. > >Anyone else interested or have comments? Yes, I have keen interest in it and am looking forward to have a feel. > >Fred >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > >

1 0

Interest in Barton-Nackman's fallible<T>?
by Gennaro Prota 31 Jul '06

31 Jul '06

Hi guys, I don't know how and how much boost:optional<> overlaps with this (last time I checked it was different, but I know there's a proposal in which the template has been changed), anyway: is there interest for a Barton-Nackman's fallible<T> template? Basically the idea is (warning: not compiled): #include <assert.h> template<typename T> class fallible { public : fallible(); explicit fallible(const T & value); bool is_valid() const; const T& value() const; operator T() const; const T& else_default_to(const T& default_value) const; void invalidate(); void validate(const T& value); // alternative to operator= private : T m_value; bool m_valid; }; template<typename T> fallible<T>::fallible() : m_valid(false) { } template<typename T> fallible<T>::fallible( const T& v ) : m_value(v), m_valid(true) { } template<typename T> bool fallible<T>::is_valid() const { return m_valid; } template<typename T> const T& fallible<T>::value() const { assert(m_valid); // <--- return m_value; } template<typename T> fallible<T>::operator T() const { return value(); } template<typename T> const T& fallible<T>::else_default_to(const T& default_value) const { return is_valid() ? static_cast<const T&>(value()) : static_cast<const T&>(default_value); } template<typename T> void fallible<T>::invalidate() { m_valid = false; } template <typename T> void fallible<T>::validate(const T& value) { m_value = value; m_valid = true; } -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

4 7

Interest in O(log n) linear list?
by Stephen Dolan 30 Jul '06

30 Jul '06

The STL contains vector, which has O(1) lookup and O(n) insertion. It also has list, which has O(n) lookup and O(1) insertion. There is also a third type of container, which doesn't exist in the STL, which has O(log n) lookup and O(log n) insertion. (For those who have read Knuth's TAOCP, it's a balanced tree with the RANK field). AFAIK, there is no well-known name for this structure, but a linear list with both operations fairly fast seems a useful item to have. Any interest? Thanks, Stephen Dolan

6 13

Boost regression notification (2006-07-30 [RC_1_34_0])
by Douglas Gregor 30 Jul '06

30 Jul '06

Boost Regression test failures Report time: 2006-07-30T10:46:58Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 257 failures in 23 libraries algorithm/string (1) concept_check (1) filesystem (4) graph (5) io (1) iostreams (10) mpl (6) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (22) program_options (2) python (84) random (1) rational (4) regex (1) serialization (24) signals (16) spirit (1) test (2) tr1 (51) typeof (8) utility (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |filesystem| mbcopy: sun-5.8 operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport wide_test: sun-5.8 |graph| adjacency_matrix_test: vc-7_0 csr_graph_test: sun-5.8 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 compose_test: borland-5_6_4 example_test: vc-6_5-stlport filtering_stream_test: msvc-8.0 vc-7_1-stlport gzip_test: msvc-7.1 msvc-8.0 zlib_test: msvc-7.1 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 vector_c: sun-5.8 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |parameter| basics: borland-5_6_4 borland-5_8_2 duplicates: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 preprocessor: borland-5_6_4 borland-5_8_2 sun-5.8 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |program_options| unicode_test_dll: borland-5_8_2 variable_map_test_dll: borland-5_8_2 |python| andreas_beyer: sun-5.8 args: sun-5.8 auto_ptr: sun-5.8 back_reference: sun-5.8 bases: gcc-3_4_4_tru64 gcc-4_0_3_tru64 sun-5.8 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 borrowed: sun-5.8 callbacks: sun-5.8 const_argument: sun-5.8 crossmod_exception: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 dict: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exception_translator: sun-5.8 exec: darwin-4.0.1 gcc-3_4_4_tru64 gcc-4_0_3_tru64 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 extract: sun-5.8 implicit: sun-5.8 indirect_traits_test: sun-5.8 injected: sun-5.8 iterator: sun-5.8 keywords: sun-5.8 list: sun-5.8 long: sun-5.8 minimal: sun-5.8 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: sun-5.8 object: sun-5.8 object_manager: sun-5.8 opaque: sun-5.8 operators: sun-5.8 pearu1: sun-5.8 pickle1: sun-5.8 pickle2: sun-5.8 pickle3: sun-5.8 pickle4: sun-5.8 pointee: gcc-3_4_4_tru64 gcc-4_0_3_tru64 sun-5.8 pointer_type_id_test: gcc-3_4_4_tru64 gcc-4_0_3_tru64 sun-5.8 pointer_vector: sun-5.8 polymorphism: sun-5.8 polymorphism2: sun-5.8 polymorphism2_auto_ptr: sun-5.8 properties: sun-5.8 raw_ctor: sun-5.8 return_arg: sun-5.8 select_arg_to_python_test: sun-5.8 select_from_python_test: darwin-4.0.1 sun-5.8 select_holder: sun-5.8 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 str: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: sun-5.8 tuple: sun-5.8 upcast: gcc-3_4_4_tru64 gcc-4_0_3_tru64 sun-5.8 vector_indexing_suite: sun-5.8 virtual_functions: sun-5.8 voidptr: sun-5.8 wrapper_held_type: sun-5.8 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 |regex| object_cache_test: darwin-4.0.1 |serialization| test_class_info_load_text_warchive: vc-6_5 test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |signals| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |spirit| mix_and_match_trees: sun-5.8 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |tr1| run_random: sun-5.8 std_run_complex_overloads: sun-5.8 std_run_random: sun-5.8 std_test_bind: sun-5.8 std_test_complex: sun-5.8 std_test_function: sun-5.8 std_test_hash: sun-5.8 std_test_mem_fn: sun-5.8 std_test_random: sun-5.8 std_test_reference_wrapper: sun-5.8 std_test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp vc-7_1-stlport std_test_result_of: sun-5.8 std_test_shared_ptr: sun-5.8 std_test_tuple: sun-5.8 std_test_tuple_tricky: sun-5.8 std_test_type_traits: sun-5.8 test_boost: vc-7_1-stlport test_hash: vc-7_1-stlport test_random: sun-5.8 vc-7_1-stlport test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_regex: vc-7_1-stlport test_type_traits: sun-5.8 tr1_tky_function_type_test: sun-5.8 |typeof| function_binding_emulation: sun-5.8 function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 template_tpl_emulation: sun-5.8 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

Re: [boost] interest in sorted vector containers?
by Lewis Hyatt 30 Jul '06

30 Jul '06

> Boost.Interprocess (formerly known as Boost.Shmem) already > provides these containers under the names flat_[multi]set, > flat_[multi]map, see http://tinyurl.com/m4beq . > > Joaqu?n M L?pez Mu?oz > Telef?nica, Investigaci?n y Desarrollo OK, great, I think it'll be excellent to have them in there. I hadn't seen that library, it looks like it will be useful for a lot of people! -lewis

2 1

Re: [boost] interest in sorted vector containers?
by JOAQUIN LOPEZ MU?Z 30 Jul '06

30 Jul '06

On 7/29/06, Lewis Hyatt <lhyatt(a)princeton.edu> wrote: > Is there any interest in providing Boost container classes > with the same functionality as set/map implemented with > sorted vectors? Boost.Interprocess (formerly known as Boost.Shmem) already provides these containers under the names flat_[multi]set, flat_[multi]map, see http://tinyurl.com/m4beq . Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0