September 2012 - Boost - lists.preview.boost.org

[graph][heap][coroutine] interruptable dijkstra shortest path function
by Alex Hagen-Zanker 05 Oct '12

05 Oct '12

[apologies for double posting, send it to wrong list before] Hi, A few months ago I posted here to gauge interest for an interruptable and resumable version of the dijkstra_shortest_path algorithm. The initial response was positive, but Jeremiah considered the proposed solution lacking compared to an algorithm object model that inverts the control over the algorithm, Additional to my original solution, I now have two implementations of the algorithm object model. 1. Visitor based interruption. This is my original approach. It separates the algorithm into an init and main function. The main function asks the visitor if it should be halted afer each iteration. After halting, the main function can be used to resume the calculation. auto dijkstra = make_dijkstra_object(graph, named_parameters); dijkstra.init_from_sources(sources); dijkstra.expand( interruptor); dijkstra.expand( other_interruptor); auto distance_map = dijkstra.get<vertex_distance_t>(); auto color_map = dijkstra.get<vertex_color_t>(); 2. Algorithm object implementation. This was suggested by Jeremiah. The algorithm object iterates from control point to control point in the algorithm. Giving at each stop access to the intermediate results of the algorithm. The two implementations are: a) Using the [Coroutine] library that is currently under review to step in and out of the function. b) Fragmenting the function into many subfunctions that are chained together and the other works by fragmenting the original algorithm into a number of small interlinked functions starting at one control point and returning at the next. The interface of a and b is exactly the same and it works like this: auto dijkstra = make_dijkstra_object(graph, sources, named_parameters); while(dijkstra.next() ) { control_point cp = dijkstra.get_control_point(); vertex u = dijkstra.get_u(); auto distance_map = dijkstra.get<vertex_distance_t>(); if(cp == cp_finish_vertex && get(distance_map, u) > 42) { cout << "far enough" << endl; break; } } auto distance_map = dijkstra.get<vertex_distance_t>(); The algorithm object offers most flexibility for interweaving multiple searches. The visitor based solution on the other hand is more efficient. The latter has no loss in performance compared to the existing dijkstra functions. The coroutine algorithm object was extremely easy to implement but it is not very efficient. Does anybody have a suggestion how that can improve? Besides these interruptable and resumable shortest path searches, there are a few more advantages to the implementation. a. All dijkstra parameters are bundled in a light-weight dijkstra_state object that is returned by algorithms, giving direct access to all results of the algorithm, for instance: auto dijkstra_state = dijkstra_shortest_paths(graph, sources, no_named_parameters() ); auto distance_map = dijkstra_state.get<vertex_distance_t>(); b. Named parameters (old style) are also used for the priority queue and the color map c. Boost.Heap mutable queues can be used with Boost.Graph via the named parameter interface. It doesn't help performance now, but may be a good base for experimentation. d. Separation of the dijkstra shortest path algorithm in init and main function makes it easier to provide custom initialization. For instance: multiple sources or only re-initializing changed vertices Can anybody use this? The latest version is here: http://people.pwf.cam.ac.uk/ahh34/dijkstra.zip Kind regards, Alex p.s. below are timings for a large graph: bimba_6M.obj... 2090 ms. Boost Graph Library 2121 ms. With interruption visitor 5601 ms. With Coroutine(*) 2621 ms. With fragmented functions (*) 2840 ms. With Boost.Heap (*) halting at all control points of the dijkstra visitor

8 21

Boost.Generic, C++0x Concepts, and C++1y Concepts
by Matt Calabrese 05 Oct '12

05 Oct '12

Hey everyone, It's been a while since I've made an appearance on this list, but I was contacted regarding the recent discussion of concepts here and Lorenzo's taking the reins of a concept library, and decided to poke my head in. First, I apologize to the community for not getting Boost.Generic on the sandbox earlier (if you are unfamiliar with Boost.Generic, see my 2011 BoostCon talk http://blip.tv/boostcon/boost-generic-concepts-without-concepts-5262126 and/or the corresponding slides https://github.com/boostcon/2011_presentations/raw/master/thu/Boost.Generic… ). I've gotten numerous emails about it since 2011 and I decided to commit the current state of Boost.Generic to the sandbox today. It is still based on the "old" concepts of C++0x with pseudo-signatures. You can find it in the "generic" subdirectory of the sandbox. That said, I'm not sure anyone even cares about Boost.Generic anymore given that the standard seems to be diverging from how it originally was approaching concepts, but here it is anyway. Similarly, I'm not sure there is any interest from people for me to continue developing Boost.Generic, so I guess this is a check for interest again. And, very briefly, without getting too political here (not that my opinion has any bearing) but I personally do not agree with some of the recent design changes for what may turn out to be C++1y concepts -- specifically I think pseudo-signatures were better overall and the C++0x form of associated types was much more useful than what is currently described, especially concerning associated type deduction, which no longer appears to be possible. But I don't think this discussion is suitable for the Boost mailing list and I don't want to ruffle too many feathers beyond that, so I'll take that elsewhere. For this reason, though, I [currently] do not have a desire to support that form of concepts in my library, though I do plan to resume work on Boost.Generic. A recap of what's gone on since my Boostcon talk, for anyone who even remembers it -- I haven't been actively developing Boost.Generic for over a year as I have been busy with other things, but coincidentally in the past couple of weeks I've gone back to it and decided to update some things due to a trick I realized I could use to get full compatibility with the C++0x working paper for explicit concept map templates (N2914's 14.10.3.2 paragraph 3 highlights why it's non-trivial, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf) Since then, I've had renewed interest in the project and have updated various facilities. Stuff that changed since my presentation back in 2011 -- it now supports variadic concepts using the syntax ,,, (see line 28 of boost/generic/std_concept/concepts/predicate.hpp for a simple example). All 135 of the concepts from N2914 are now implemented, though not all are working, especially ones that are not auto and use refinement (I'm still in the process of making the concept map backend changes). All of the std_concepts/concepts tests should be working, and same with std_concept/support_concepts tests, with GCC and Clang only failing on FreeStoreAllocatable (in slightly different ways). I'm updating some of the implementation to use the new Boost.Preprocessor variadic macro support that didn't exist when I started development, and Boost.Generic now also is starting to use Edward Diener's variadic_macro_data_library that's in the sandbox. I've only recently test on GCC 4.7 and Clang 3.1, both with libstdc++ on Windows. I don't think any other compilers will be able to handle it because of the amount of C++11 features currently in use... Visual C++ in particular will likely have no chance of compiling ANY of it, even if you use the fully preprocessed form of the library that I provided on the sandbox. Specifically, I currently require the updated C++11 SFINAE support, variadic templates, and template aliases, among other features which I don't believe Visual C++ yet supports. If you want to see how to use the library, for now you'll have to watch the talk, look at the slides, and/or go into generic/test/libs/generic/test/std_concept and examine the tests that are there (the latter will probably be the most enlightening in terms of using the predefined concepts). As for the tests, the ones you should look at if you want to understand how to use the predefined concepts are in the test directory's std_concept/concepts and std_concept/support_concepts subdirectories. If you want to see the syntax for creating your own concepts, the ones in std_concept/concepts are the best choice to look at, as they are simple and most do not require compiler intrinsics, unlike the support_concepts which rely on C++11 type_traits and the C++0x std::True concept. I also recently integrated Boost.Wave support to easily generate preprocessed versions of all of the concepts in the library. You can use the preprocessed headers, including Dave's suggested #line support, without having to run Boost.Wave yourself. To do this you just define a couple of macros when you build the tests. This decreases build times by over 50% on both Clang and GCC -- the tests for me in Clang go from over 7 minutes to just over 3 minutes if I use the preprocessed headers. To activate this support you need the two defines in the following format (easiest to just define them via the command-line) // NOTE: Do not use quotes around the path -- also realize that the path ends in the middle of the word generic, This is necessary. #define BOOST_GENERIC_PREPROCESSED_ROOT put_your_COMPLETE_path_to_boost_sandbox_here/generic/include/boost/gen // Also #define BOOST_GENERIC_USE_PREPROCESSED_HEADERS This will use completely preprocessed concepts, with errors properly pointing to the non-preprocessed headers, and effectively gets rid of all of the "from macro invocation" notes you'd see in clang and gcc 4.8 whenever you hit one of the Boost.Generic generated static_asserts in the non-preprocessed form. It is recommended that you use the preprocessed form unless you are making changes to the library-provided concepts, since compile-times are greatly reduced by using them and error messages are improved. Anyway, as I said, I do not personally like the direction that concepts seem to be going and so I do not currently have much of an interest in implementing what is currently proposed, however, buried somewhere in the source of Boost.Generic I believe is an early implementation of the library that was more similar to how concepts are specified in N3351, though I stopped maintaining it a long time ago -- it allowed for the specification of givens and arbitrary expression matching similar to the current design, with a brief demonstration given in my 2011 Boostcon talk (slide 20: https://github.com/boostcon/2011_presentations/raw/master/thu/Boost.Generic…) It might be useful to revive this now that standard concepts may be going in that direction, but again, I do not think this is a good idea and was why I was convinced by others to switch development to pseudo-signatures to begin with. -- -Matt Calabrese

3 16

Who maintains boost MPI?
by Ralf Grosse-Kunstleve 04 Oct '12

04 Oct '12

Hi, we're looking for someone to merge a simple patch: https://svn.boost.org/trac/boost/ticket/6123 Ralf

4 4

[spirit] Symbols parser with overlapping symbols
by Andrey Semashev 01 Oct '12

01 Oct '12

Hi, I wonder how qi::symbols parser behaves when it contains partially overlapping symbols. For example: qi::symbols< char, int > syms; syms.add("a", 1); syms.add("aaa", 2); What will this parser return when "aaa" is passed as input? I couldn't find it in the docs.

2 1

[1.52.0] [request permission to merge to release] Changeset 80790
by Jeffrey Lee Hellrung, Jr. 30 Sep '12

30 Sep '12

As I was updating the Release Notes for 1.52.0, I thought about a recently introduced restriction on function_input_iterator (due to addressing ticket #5825 [1] in [2]) that could be relaxed. trunk changeset is here: https://svn.boost.org/trac/boost/changeset/80790 I think it's pretty benign but given that the release branch is closed tomorrow (Monday) and the beta rc is just a few days after that, I figured that whether and when this gets merged to release is up to the release managers. Please advise, - Jeff [1] https://svn.boost.org/trac/boost/ticket/5825 [2] https://svn.boost.org/trac/boost/changeset/80467

1 1

Inspection tool run
by Paul A. Bristow 30 Sep '12

30 Sep '12

I've been trying to get Boost.Math off the Sinners List on the Inspection Report at http://boost.cowic.de/rc/inspect-trunk.html#math. It last ran 25 July 12, so I can't see if I have succeeded yet. When can I expect it to run again? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

8 12

[website] Latest version of page links
by Daniel James 30 Sep '12

30 Sep '12

Hello all, I finally got round to finishing off the links from old documentation to the latest version. It's a little hacked in so the markup isn't wonderful, and it only works for libraries whose documentation is altered by the site's php scripts. That's usually the documentation with no frames and the green header (some libraries put the green header in themselves, it won't work for them). At the moment it's just on the beta site, for example: http://beta.boost.org/doc/libs/1_49_0/libs/phoenix/doc/html/index.html Not all pages have a page in the same location in the most recent version, so for some pages you will just get a link to the latest documentation list: http://beta.boost.org/doc/libs/1_41_0/doc/html/boost/units/si/constants/cod… This will go live soonish. I might tweak it a little first, maybe change the wording on the notices, but it's pretty much done for now. Please try it out with your favourite documentation to check I haven't made too much of a mess. thanks, Daniel

2 2

Review Wizard Status Report for September 2012
by Ronald Garcia 29 Sep '12

29 Sep '12

============================================== Review Wizard Status Report for September 2012 ============================================== News ==== 1. Boost 1.51.0 Released. New Libraries: 1) Context 2. Multiprecision Accepted 3. Type Erasure Accepted 4. Contract Reviewed 5. Coroutine Reviewed 6. ODEInt Reviewed 7. Contract Accepted 8. Polygon Extensions integrated into Polygon Open Issues =========== The following libraries have review managers, but have not yet been scheduled for review: * Range Extensions - added May 2012; review manager: Neil Groves. The following libraries have been reviewed and await reports from their review managers: * Predef - reviewed February 2012; review manager: Joel Falcou. * Coroutine - reviewed September 2012; review manager: Hartmut Kaiser. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak. * GIL.IO - accepted January 2011; author: Christian Henning. * Contract - accepted September 2012; author: Lorenzo Caminiti. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Atomic - accepted July 2011; author Helge Bahmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. * Lockfree - accepted August 2011; author: Tim Blechmann. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Endian - accepted provisionally November 2011; author: Beman Dawes. * Log - accepted provisionally March 2010; author: Andrey Semashev. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Range Extensions * Nowide (M) * Array (M) * TypeIndex (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: https://github.com/boost-vault/Miscellaneous/blob/master/Pimpl.zip :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: This library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Polygon: Voronoi Extensions --------------------------- :Author: Andril Sydorchuk :Review Manager: Lucanus Simonson :Download: http://svn.boost.org/svn/boost/sandbox/gtl/ :Description: This library extends Boost.Polygon with the following features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). Coroutine --------- :Author: Oliver Kowalke :Review Manager: Hartmut Kaiser :Download: http://gitorious.org/boost-dev/boost-dev/archive-tarball/coroutine :Description: This library is an implementation of coroutines and generators using Boost.Context. Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. Array ----- :Author: Brian Smith :Review Manager: Needed :Download: https://github.com/BrianJSmith/Array :Description: The array class is a C++11 compatible implementation of static multidimensional arrays. TypeIndex --------- :Author: Antony Polukhin :Review Manager: Needed :Download: https://github.com/apolukhin/type_index :Description: TypeIndex is an extended C++11 type_index library, that * works with disabled RTTI * can store const-volatile-reference info about types (if user requested it) * has all the functionality of std::type_index * has portable across compilers and platforms functionality for getting demangled type names * works across modules/shared libraries * does not require C++11 to work Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

3 5

[Review] ODEInt review starts today, September 19, ends September 28
by Steven Watanabe 28 Sep '12

28 Sep '12

AMDG The review of Karsten Ahnert and Mario Mulansky's ODEInt library starts today September 19th and will end on September 28. -------------------------------------- About the library: odeint provides routines for numerically solving Ordinary Differential Equations, a task heavily required when approaching scientific problems numerically. In odeint we have implemented the most common algorithms in a modern, generic way which provides several advantages over existing implementations. The main focus of odeint is to separate algorithms from the underlying basic computation unit. This allows for example to easily use the power of modern GPUs via CUDA or OpenCL to speed up computational heavy simulations. Features: - provides most of the standard algorithms, including step size control, dense ouput and extrapolation routines - symplectic routines for Hamiltonian systems - implicit routines based on boost::ublas (MTL4 in progress) - high level integrate functions - interchangeable computation backend with existing bindings to CUDA and OpenCL - native support of ODEs defined for complex values - support of Boost.Units in most of the algorithms - support of arbitrary precision types You can download the library and view the documentation here: zip: http://github.com/headmyshoulder/odeint-v2/zipball/master github: http://headmyshoulder.github.com/odeint-v2/ docs: http://headmyshoulder.github.com/odeint-v2/doc/index.html -------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? In Christ, Steven Watanabe

6 8

Contributing a thread pool class
by BOLTON Gawain 28 Sep '12

28 Sep '12

Hello, It seems that boost's "thread" library does not have a thread pool class. It does have a thread_group class but this class is has the following limitations: 1. It does not limit the number of threads created. 2. Threads added are not managed and raw pointers are used exposing the developer to memory leaks. 3. The API deals with threads and not "tasks" to be executed by a thread. As such I have developed a thread pool class which allows for: · A maximum number of "worker" threads to configured. · Arbitrary "tasks" to be submitted by any thread and executed by one of the worker threads. o Worker threads are created as and when needed. · Worker threads can terminate after being idle a configurable amount of time. o They will be re-created if needed afterwards. The amount of code is quite small (< 500 lines including blank lines, API usage document in the header file and comments) and just uses standard C++ and boost thread functionality. My question is, would the boost community be interested in such a contribution to the thread library? I apologize in advance if this is the Nth time such a contribution has been proposed and rejected. I have developed this while working for my employer (a French bank called Société Générale). I have my manager's support and am in the process of obtaining agreement from my employer to get permission to submit the thread pool class developed. Cheers, Gawain Bolton Domino Development ITEC/CTT/GEF/TED 17 cours Valmy 92 800 Puteaux France Telephone : +33 1 42 13 52 43 ************************************************************************* This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************ Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. *************************************************************************

3 2