Dear developers, the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well. To decide, whether it's design, implementation and overall usefulness is sufficient to be accepted in the boost libraries collection is now up to you. In the last round of refactoring I concentrated on efficiency and optimization issues. The implementation of the itl's interval containers is still based on std::set and std::map, but algorithms are now exploiting hinted insert and are manipulating intervals and values in place instead of copying in many instances. This way, it has been possible to improve performance significantly. Along the way of implementing optimizations I have documented the complexity guarantees for all important functions of the library's interface. Please note that the original ITL as presented in May 2008 has been split into 3 parts and only the *first* part is submitted for review: itl : Core library, interval containers, SUBMITTED FOR REVIEW Additional parts are: itl_xt : Extensions like histories and generalized crosstables validate: The law based test automaton (LaBatea). A validation tool using laws aka axioms. *itl* is a complete library containing all required ingredients particularly a separate test suite (NOT using LaBatea) and the quickbook documentation. The code is successfully compiled and tested with gcc-3.4.4, 4.1.0, 4.3.2 and msvc-8.0, 9.0. I have uploaded the review version as itl_3_1_0.zip to the vault in section containers. http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_1_0.zip&directory=Containers Another file itl_plus_3_1_0.zip contains all three parts (itl, itl_xt and validate). http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_plus_3_1_0.zip&directory=Containers Reviewers interested in the law based testing part may have to refer to this file to examine those tests. The law base testing examples compile and run with gcc-4.3.2, msvc-8.0 and 9.0. LaBatea does not compile with gcc-4.1.0 or older. The quickbook generated documentation is included in the zip files and is also available online at http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html Sources are also available form the sandbox: https://svn.boost.org/svn/boost/sandbox/itl/ To close my request for review, let me take the opportunity to do some advertisement ;-) focusing on some of the itl's highlights. * The Itl emerged out of real world software development extracting generic functionality from numerous use cases of the date time problem domain. (http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/exa...) But the need for the same data structures occurs in other fields as well. E.g. Zachary Turner uses a compressed_bitmap similar to an itl::interval_set to manage very large file system allocation bitmaps and gives more use cases here (http://lists.boost.org/Archives/boost/2009/06/152817.php). * Aggregation on overlap not only provides a useful feature to compute aggregation results on interval_maps like statistics, it also leads to a generalized addition operation on maps that exhibits interesting semantical properties. E.g. (http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/semanti...) * The itl's design is based on sets of laws (aka axioms) that are described in the documentation. (http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/semanti...) These law sets not only are giving a formal specification of the library. Using the law based testing tool (LaBatea) (https://svn.boost.org/svn/boost/sandbox/itl/boost/validate) allows to validate the library code for every specified law. * For the itl, 18 laws have been validated on the 7 container templates with varying instantiation types for template parameters, running a total of 719 different law instances (each of them for large numbers of randomly generated test data). (https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/) This gives everyone a method to check semantical properties of the library in a way that is more powerful than traditional unit tests. To get the 'complete picture' of the library's interface you may want to refer to the synoptic function table first (http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/int...) before looking at more specific topics. Hoping to have quickened your appetite to take a closer look at this library before and during the review process. best regards Joachim Faulhaber
Joachim Faulhaber <afojgo <at> googlemail.com> writes:
Dear developers,
the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well.
Actually I am very unlucky with the name "itl". 1. Any boost library is using templates, so using "Template" in the library name is somewhat redundant. Same with "Library". All boost components are libraries, except Boost.Build and Boost.Book Remains "Interval" which is already in use: http://www.boost.org/doc/libs/1_40_0/libs/numeric/interval/doc/interval.htm Can you please take the time to explain the difference in math and aim of the lib compared to Boost.Interval? 2. ITL is already in use for the iterative template library http://www.osl.iu.edu/research/itl/ which has functionality that should enter boost within the next decade - IMHO. (Where its name will be "iterative"? or "krylov_subspace_methods"? ...) My plea: Try to find a unique name, not something that gives you 4.710.000 hits on google. Besides that I find your library promising and will try to use it in a future project. best regards, Markus
2009/9/21 Markus Werle <numerical.simulation@web.de>:
Joachim Faulhaber <afojgo <at> googlemail.com> writes:
the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well.
Actually I am very unlucky with the name "itl".
1. Any boost library is using templates, so using "Template" in the library name is somewhat redundant. Same with "Library". All boost components are libraries, except Boost.Build and Boost.Book
isn't it amazing how much redundancy can be put into such a short name ;-) Joking aside -- you are addressing a good point. Names should be concise. The *tl naming fashion is surely widespread and carries unnecessary redundancy. Yet it is very tempting for an author of a generic library to follow the footsteps of the giant ancestor (stl). Itl is a working title for me and after using it for more than two years now in postings and titles like in my talk in the boostcon09 it has gathered some recognition, so I am not going to change it lightly. But I agree, there may be other suitable names that can be precise and more appropriate.
Remains "Interval" which is already in use: http://www.boost.org/doc/libs/1_40_0/libs/numeric/interval/doc/interval.htm
Can you please take the time to explain the difference in math and aim of the lib compared to Boost.Interval?
There are two major differences between boost::numeric::intervals and itl::intervals. (1) A numeric::interval from the boost Interval Arithmetic Library works on intervals of (floating point) numbers. An itl::interval can be instantiated with numeric and non numeric data types. The only requirement for an itl::interval<T> is that there is a strict weak ordering on T. So an itl::interval can be instantiated with floating point numbers, intergral numbers, std::strings and many types more. (2) boost::numeric::intervals are always closed: They contain their lower and upper bound. Itl::intervals can have open or closed bounds. This property is decisive for the design of the itl, because we want to combine e.g. intervals [0.0, 1.0) and [1.0, 2.0] and decide if those intervals are combinable to single new interval, if they abut without intersecting e.t.c. Boost::numeric::interval and itl::interval can coexist nicely, because of their different scopes and purposes. While boost::numeric::interval implements interval arithmetic itl::interval does not aim to implement interval arithmetic at all. The aim of itl::intervals is to model sets of values that occur between a lower and upper bound w.r.t. a given order.
2. ITL is already in use for the iterative template library http://www.osl.iu.edu/research/itl/ which has functionality that should enter boost within the next decade - IMHO. (Where its name will be "iterative"? or "krylov_subspace_methods"? ...)
My plea: Try to find a unique name, not something that gives you 4.710.000 hits on google.
I am not worrying about the number of hits. Yet I am going to consider your plea because your arguments are justified.
Besides that I find your library promising and will try to use it in a future project.
Good! Let me know about your experiences, critics and suggestions. Cheers Joachim
Joachim Faulhaber wrote:
the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well.
Actually I am very unlucky with the name "itl".
The aim of itl::intervals is to model sets of values that occur between a lower and upper bound w.r.t. a given order.
I'd suggest naming it either Interval Set--boost::interval_set or Interval Set Library--boost::isl. Regards, Luke
2009/9/21 Simonson, Lucanus J <lucanus.j.simonson@intel.com>:
Joachim Faulhaber wrote:
the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well.
(Markus Werle) Actually I am very unlucky with the name "itl".
I'd suggest naming it either Interval Set--boost::interval_set or Interval Set Library--boost::isl.
after pondering for a while I tend to prefer this name Compact Associative Containers boost::compass I think this name is appropriate with respect to scope and level of abstraction. * The lib provides containers * It implements sets and maps which are known as associative containers. * It implements them exploiting a compact representation (intervals) * The central requirements of the compact representations is that key elements of the containers are LessThan *comp*arable. So the acronym compass can also express that the domain_type of the *ass*ociative containers has to be *comp*arable. * The name omits 'interval' which prevents one of the most frequent misunderstandings that the library's interval_sets are sets of intervals or that interval_maps map intervals to values. Instead they are associative containers of elements in a compact implementation *using* intervals. Thoughts? -- Joachim
Joachim Faulhaber wrote:
2009/9/21 Simonson, Lucanus J <lucanus.j.simonson@intel.com>:
Joachim Faulhaber wrote:
the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well.
(Markus Werle) Actually I am very unlucky with the name "itl".
I'd suggest naming it either Interval Set--boost::interval_set or Interval Set Library--boost::isl.
after pondering for a while I tend to prefer this name
Compact Associative Containers boost::compass
That's a highly creative name which I don't foresee its conflicting with other libraries. My only concern would be that there's no mention of "container" in that name. There's precedent for this -- Spirit, Wave, and Xpressive -- but the preponderance of library names are named directly for the functionality or are acronyms of it. How about Minimal (or Minimized) Associative Containers (MAC)? Packed Associative Containers (PAC)? None of those names, however, reveals the interval behaviors of your containers which are their raison d'être. Interval-Based Associative Containers (IBAC)? Is "associative" necessary in the name: Interval-Based Containers (IBC)? Compact Interval-based Associative Containers (CIAC or CIBAC)? (Associative) Containers of Intervals ((A)CI or (A)COI)? Compact Associative Containers of/for Intervals (CACI)? Packed Associative Interval Containers (PAIC)? Of all these ideas, I rather like CACI. The acronym is pronounceable (like khaki), and the full name is highly descriptive. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Wed, Sep 23, 2009 at 8:42 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Joachim Faulhaber wrote:
2009/9/21 Simonson, Lucanus J <lucanus.j.simonson@intel.com>:
Joachim Faulhaber wrote:
the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well.
(Markus Werle) Actually I am very unlucky with the name "itl".
I'd suggest naming it either Interval Set--boost::interval_set or Interval Set Library--boost::isl.
after pondering for a while I tend to prefer this name
Compact Associative Containers boost::compass
That's a highly creative name which I don't foresee its conflicting with other libraries.
Except a compass library for handling built in compasses of various smart phones. :-)
How about Minimal (or Minimized) Associative Containers (MAC)? Packed Associative Containers (PAC)?
None of those names, however, reveals the interval behaviors of your containers which are their raison d'être.
Interval-Based Associative Containers (IBAC)? Is "associative" necessary in the name: Interval-Based Containers (IBC)? Compact Interval-based Associative Containers (CIAC or CIBAC)? (Associative) Containers of Intervals ((A)CI or (A)COI)? Compact Associative Containers of/for Intervals (CACI)? Packed Associative Interval Containers (PAIC)?
Of all these ideas, I rather like CACI. The acronym is pronounceable (like khaki), and the full name is highly descriptive.
I would leave 'compact' out of it, and 'interval' in. I'm sure there are other ways to compact a container; this library chose intervals. And NOT just as an implementation detail. Intervals are very much forefront in the design and API. Furthermore, there may be other ways to compact interval sets even more. (ie with generating functions - ie how would this interval library handle the Cantor Set!?). The word 'interval' may conflict with other uses of the word, but they both derive from the same mathematical concept - a range of numbers. Hey, we could use the word 'range'. Oh wait, also already taken. (Or are these concepts actually the same and using boost::range as an interval makes sense at times. I think so...). Could the library be expanded to 2D or more? If so, then 'region' might be a more applicable word. Or is there another mathematical word we are forgetting about? Maybe something in the field of topology? Might the library be expanded to other containers (ie besides associative ones)? interval_vector? Or is that less interesting? Given the ordering requirement, is there any difference between an interval_vector and an interval_set (in general terms, not specific properties such as amortized allocation, etc). ie should 'associative' be part of the name? So, to me, that leaves 'interval' and 'container'. icl. Although I like the sound of 'isl' (Set) better. But really, we should avoid TLAs. Did that help? Probably not. ------ So anyhow, I should also say that after years of working on video editing applications (ie Adobe Premiere Pro), I was considering writing a similar library. (To handle the range of time for each video clip on a timeline, etc). Thanks for beating me to it! As an example usage, with your library, how would you write a 'for a given interval_set, is this time-range [a, b) empty' function? Tony
2009/9/24 Gottlob Frege <gottlobfrege@gmail.com>:
On Wed, Sep 23, 2009 at 8:42 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Joachim Faulhaber wrote:
2009/9/21 Simonson, Lucanus J <lucanus.j.simonson@intel.com>:
Joachim Faulhaber wrote:
> the Interval Template Library is now in a state > where I think it does conform the requirements > and guidelines for boost libraries fairly well.
(Markus Werle) Actually I am very unlucky with the name "itl".
I'd suggest naming it either Interval Set--boost::interval_set or Interval Set Library--boost::isl.
after pondering for a while I tend to prefer this name
Compact Associative Containers boost::compass
That's a highly creative name which I don't foresee its conflicting with other libraries.
Except a compass library for handling built in compasses of various smart phones. :-)
How about Minimal (or Minimized) Associative Containers (MAC)? Packed Associative Containers (PAC)?
None of those names, however, reveals the interval behaviors of your containers which are their raison d'être.
Interval-Based Associative Containers (IBAC)? Is "associative" necessary in the name: Interval-Based Containers (IBC)? Compact Interval-based Associative Containers (CIAC or CIBAC)? (Associative) Containers of Intervals ((A)CI or (A)COI)? Compact Associative Containers of/for Intervals (CACI)? Packed Associative Interval Containers (PAIC)?
Of all these ideas, I rather like CACI. The acronym is pronounceable (like khaki), and the full name is highly descriptive.
These are highly creative acronyms too ;-) Obviously, like Luke above and Tony below, you would vote to preserve 'Interval' as a part of the libs name. I like the pronounceable CACI but also the more simple COI for it's reminiscence to the ornamental fish 'Koi'.
I would leave 'compact' out of it, and 'interval' in. I'm sure there are other ways to compact a container; this library chose intervals. And NOT just as an implementation detail. Intervals are very much forefront in the design and API.
Most people that looked at my lib seem to share this view. Yet my efforts were very much directed towards a design that makes the core API independent from Intervals (http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/con...) I have called those core parts the *abstract aspect* (http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/con...) The library implements the abstract aspect for interval containers *and* containers of elements. I define all formal laws that forms the major semantics of the library on that core signatures for both interval and element containers. (http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/sem...) And all of the automated law validation is done for interval containers *and* containers of elements for identical laws that all abstract from intervals. But yes, on the other hand there is the more implementation oriented part called *iterative aspect* on interval containers, one could also say *sequence of intervals revealing* part, that is accessible through the API. I did this, because of the usefulness of those functions. The iterative aspect could be removed (used only privately) without damaging the core functions of the *abstract aspect*.
Furthermore, there may be other ways to compact interval sets even more. (ie with generating functions - ie how would this interval library handle the Cantor Set!?).
Good point.
The word 'interval' may conflict with other uses of the word, but they both derive from the same mathematical concept - a range of numbers.
in the itl a range of StrictWeakComparable objects, which may be not in line with the mathematical notion of an interval but makes the library's scope more general.
Hey, we could use the word 'range'. Oh wait, also already taken. (Or are these concepts actually the same and using boost::range as an interval makes sense at times. I think so...).
Interesting point.
Could the library be expanded to 2D or more? If so, then 'region' might be a more applicable word.
In the extended part of my lib currently called itl_xt, I have pursued ideas similar to those from interval_maps, for tuple maps, in order to model generalized crosstables or cubes. I used the same philosophy: Defining a generalized addition operation and using that for computing aggregates. In this part of my lib there are no intervals at all but the same strategy of generalizing addition on maps. Because this is may be more fundamental to the design of my generic stuff than other aspects, I tried to find a name for that, but so far nothing really convincing came to my mind.
Might the library be expanded to other containers (ie besides associative ones)? interval_vector? Or is that less interesting?
You already are able to use an interval_map<unsigned int, double, total_absorber> infi_vec; as an infinite or at least very large vector, which is defined for the complete range of unsigned ints.
should 'associative' be part of the name?
might be an obstacle for future extensions, but I have no plans or ideas to go beyond that scope now.
So, to me, that leaves 'interval' and 'container'. icl. Although I like the sound of 'isl' (Set) better.
But really, we should avoid TLAs.
Did that help? Probably not.
Yes it did :) You discussed a lot of interesting and important aspects. Considering all that I agree that ICL is a good and kind of an essential acronym.
------ So anyhow, I should also say that after years of working on video editing applications (ie Adobe Premiere Pro), I was considering writing a similar library. (To handle the range of time for each video clip on a timeline, etc). Thanks for beating me to it!
sorry, I had all the fun ;-)
As an example usage, with your library, how would you write a 'for a given interval_set, is this time-range [a, b) empty' function?
I am not sure if I understand exactly what you mean here ... but // This code checks if an interval_set is empty within a range. interval_set<time> some_times; some_times += ...; time a = ..., b = ...; if(intersects(some_times, interval<int>::rightopen(a,b))) ; // Within the range [a,b) some_times is not empty Cheers Joachim
2009/9/24 Joachim Faulhaber <afojgo@googlemail.com>:
2009/9/24 Gottlob Frege <gottlobfrege@gmail.com>:
As an example usage, with your library, how would you write a 'for a given interval_set, is this time-range [a, b) empty' function?
I am not sure if I understand exactly what you mean here ... but
// This code checks if an interval_set is empty within a range. interval_set<time> some_times; some_times += ...; time a = ..., b = ...; if(intersects(some_times, interval<int>::rightopen(a,b))) ; // Within the range [a,b) some_times is not empty
Correction: must be interval<time> of course // This code checks if an interval_set is empty within a range. interval_set<time> some_times; some_times += ...; time a = ..., b = ...; if(intersects(some_times, interval<time>::rightopen(a,b))) ; // Within the range [a,b) some_times is not empty
On Thu, Sep 24, 2009 at 10:13 AM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
2009/9/24 Joachim Faulhaber <afojgo@googlemail.com>:
2009/9/24 Gottlob Frege <gottlobfrege@gmail.com>:
As an example usage, with your library, how would you write a 'for a given interval_set, is this time-range [a, b) empty' function?
I am not sure if I understand exactly what you mean here ... but
// This code checks if an interval_set is empty within a range. interval_set<time> some_times; some_times += ...; time a = ..., b = ...; if(intersects(some_times, interval<int>::rightopen(a,b))) ; // Within the range [a,b) some_times is not empty
Correction: must be interval<time> of course
// This code checks if an interval_set is empty within a range. interval_set<time> some_times; some_times += ...; time a = ..., b = ...; if(intersects(some_times, interval<time>::rightopen(a,b))) ; // Within the range [a,b) some_times is not empty
That's exactly what I meant, and expected something like that, but just thought I'd check. Thanks. In my code-base, writing yet-another IsEmpty(starttime, endtime) member function is what made me realize that it should be a general library with reusable algorithms. I take it I could make the intersects() algorithm (and all the others) work with my existing data structures (the same way stl algorithms work with anything that has the right iterators)? (And then possibly move to interval_sets later?) Tony
Hi Joachim, Joachim Faulhaber wrote:
Dear developers,
the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well.
I'm working with CodeWarrior version 9.x (yep I'm stuck with this): The trailing ';'s on member function definitions cause warnings in boost\itl\type_traits\unon.hpp template <> inline std::string unon<std::string>::value() { return std::string(" "); }; template <class Type> inline Type unon<Type>::value() { return succ(neutron<Type>::value()); }; Also Ambiguous use of partial specialization Errors in is_combinable.hpp for the typedef's in: template<class Type> struct is_interval_set_derivative<Type, typename Type::interval_type> { typedef is_interval_set_derivative<Type, typename Type::interval_type> type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); }; template<class Type> struct is_interval_map_derivative<Type, typename Type::interval_mapping_type> { typedef is_interval_map_derivative<Type, typename Type::interval_mapping_type> type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); }; template<class Type> struct is_interval_map_derivative<Type, typename Type::value_type> { typedef is_interval_map_derivative<Type, typename Type::value_type> type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); }; Any thoughts on fixing these? Thanks, Jeff
Jeff Flinn wrote:
Hi Joachim,
Joachim Faulhaber wrote:
Dear developers,
the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well.
I'm working with CodeWarrior version 9.x (yep I'm stuck with this):
That's version 9.4.
Also Ambiguous use of partial specialization Errors in is_combinable.hpp for the typedef's in:
template<class Type> struct is_interval_set_derivative<Type, typename Type::interval_type> { typedef is_interval_set_derivative<Type, typename Type::interval_type> type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); };
So isn't this comparable: template<class Type> struct is_interval_set_derivative<Type, typename Type::interval_type> { typedef is_interval_set_derivative type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); }; Isn't the unadorned name is_interval_set_derivative within the context of this struct definition the same as if it had the template parameters specified? Modifying is_combinable in this fashion compiles in cw9.4. I haven't checked yet with MSVC or gcc. Jeff
2009/9/24 Jeff Flinn <TriumphSprint2000@hotmail.com>:
Jeff Flinn wrote:
Hi Joachim,
Joachim Faulhaber wrote:
Dear developers,
the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well.
I'm working with CodeWarrior version 9.x (yep I'm stuck with this):
That's version 9.4.
Also Ambiguous use of partial specialization Errors in is_combinable.hpp for the typedef's in:
template<class Type> struct is_interval_set_derivative<Type, typename Type::interval_type> { typedef is_interval_set_derivative<Type, typename Type::interval_type> type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); };
So isn't this comparable:
template<class Type> struct is_interval_set_derivative<Type, typename Type::interval_type> { typedef is_interval_set_derivative type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); };
Isn't the unadorned name is_interval_set_derivative within the context of this struct definition the same as if it had the template parameters specified?
Modifying is_combinable in this fashion compiles in cw9.4. I haven't checked yet with MSVC or gcc.
Hi Jeff, thank you for checking this. It looks like gcc and msvc are happy with your code change. I am going to run a few more tests tomorrow before committing the code to the sandbox (it's 1am in Berlin ;) Good night Joachim
Joachim Faulhaber wrote:
2009/9/24 Jeff Flinn <TriumphSprint2000@hotmail.com>:
Jeff Flinn wrote:
Hi Joachim,
Joachim Faulhaber wrote:
Dear developers,
the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well. I'm working with CodeWarrior version 9.x (yep I'm stuck with this): That's version 9.4.
Also Ambiguous use of partial specialization Errors in is_combinable.hpp for the typedef's in:
template<class Type> struct is_interval_set_derivative<Type, typename Type::interval_type> { typedef is_interval_set_derivative<Type, typename Type::interval_type> type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); }; So isn't this comparable:
template<class Type> struct is_interval_set_derivative<Type, typename Type::interval_type> { typedef is_interval_set_derivative type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); };
Isn't the unadorned name is_interval_set_derivative within the context of this struct definition the same as if it had the template parameters specified?
Modifying is_combinable in this fashion compiles in cw9.4. I haven't checked yet with MSVC or gcc.
Hi Jeff, thank you for checking this. It looks like gcc and msvc are happy with your code change. I am going to run a few more tests tomorrow before committing the code to the sandbox (it's 1am in Berlin ;) Good night Joachim
Thanks for putting in the late night on this! :-) So the next issue is in map.hpp. I'm getting redefined errors on map::add(const std::parit<const _T0, _T1>&) and map::add(std::map<_T0, _T1, _T3<_T0>, _T6<const std::pair<const _T0, _T1>>>iterator, const std::pair<const _T0, _T1>&) This is via merely #including <boost/itl/split_interval_map.hpp>. It looks like similar issues with map::subtract as well. Hmm, this sounds similar to other problems defining a template methods out of line? Thanks, Jeff
2009/9/25 Jeff Flinn <TriumphSprint2000@hotmail.com>:
So the next issue is in map.hpp. I'm getting redefined errors on map::add(const std::parit<const _T0, _T1>&) and map::add(std::map<_T0, _T1, _T3<_T0>, _T6<const std::pair<const _T0, _T1>>>iterator, const std::pair<const _T0, _T1>&)
This is via merely #including <boost/itl/split_interval_map.hpp>. It looks like similar issues with map::subtract as well. Hmm, this sounds similar to other problems defining a template methods out of line?
I don't have a CodeWarrior compiler installed on my machine (yet), so I hope you can figure out the details. I have committed the code changes according to your former posting to the sandbox. Concerning the redefine errors I suspect that your battlesome compiler is not satisfied with the attempt to declare the member function map& map::add(const value_type&); and then an overloaded member function template private: template<class Combiner> map& map::add(const value_type&); so I changed the names of those private member function templates adding a leading underscore '_add'. The code looses some simplicity but it compiles and works with msvc and gcc. I hope this works for the warrior too and he can be appeased soon ;-) Cheers Joachim
Joachim Faulhaber wrote:
2009/9/25 Jeff Flinn <TriumphSprint2000@hotmail.com>:
So the next issue is in map.hpp. I'm getting redefined errors on map::add(const std::parit<const _T0, _T1>&) and map::add(std::map<_T0, _T1, _T3<_T0>, _T6<const std::pair<const _T0, _T1>>>iterator, const std::pair<const _T0, _T1>&)
This is via merely #including <boost/itl/split_interval_map.hpp>. It looks like similar issues with map::subtract as well. Hmm, this sounds similar to other problems defining a template methods out of line?
I don't have a CodeWarrior compiler installed on my machine (yet), so I hope you can figure out the details.
I have committed the code changes according to your former posting to the sandbox. Concerning the redefine errors I suspect that your battlesome compiler is not satisfied with the attempt to declare the member function
map& map::add(const value_type&);
and then an overloaded member function template
private: template<class Combiner> map& map::add(const value_type&);
so I changed the names of those private member function templates adding a leading underscore '_add'. The code looses some simplicity but it compiles and works with msvc and gcc.
I hope this works for the warrior too and he can be appeased soon ;-)
Yep, that worked for both add & subtract private methods. I now get a complete compile, of course that's just with the #include <boost/itl/split_interval_map.hpp>. Now to actually instantiate some code. :-). Jeff
Jeff Flinn wrote:
Joachim Faulhaber wrote:
...
map& map::add(const value_type&);
and then an overloaded member function template
private: template<class Combiner> map& map::add(const value_type&);
so I changed the names of those private member function templates adding a leading underscore '_add'. The code looses some simplicity but it compiles and works with msvc and gcc.
I hope this works for the warrior too and he can be appeased soon ;-)
Yep, that worked for both add & subtract private methods. I now get a complete compile, of course that's just with the #include <boost/itl/split_interval_map.hpp>. Now to actually instantiate some code. :-).
Ok, I get an "ambiguous use of partial specialization" compiler error when I add the last line below: { typedef boost::itl::interval_map<int, int> OverlapCounterT; OverlapCounterT overlap_counter; boost::itl::interval<int> itv; itv = boost::itl::interval<int>::rightopen(4,8); overlap_counter += std::make_pair(boost::itl::interval<int>::rightopen(4,8), 1); } the compiler error text is: Error : ambiguous use of partial specialization (point of instantiation: 'CoverageGraphIntervalsTest::testTopology()') (instantiating: 'boost::enable_if<boost::itl::is_intra_derivative<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>, std::pair<boost::itl::interval<int, std::less>, int>>, boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>>') (instantiating: 'boost::itl::is_intra_derivative<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>, std::pair<boost::itl::interval<int, std::less>, int>>') (instantiating: 'boost::mpl::or_<boost::mpl::and_<boost::itl::is_interval_set<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>>, boost::itl::is_interval_set_derivative<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>, std::pair<boost::itl::interval<int, std::less>, int>>, boost::mpl::bool_<true>, boost::mpl::bool_<true>, boost::mpl::bool_<true>>, boost::mpl::and_<boost::itl::is_interval_map<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>>, boost::itl::is_interval_map_derivative<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>, std::pair<boost::itl::interval<int, std::less>, int>>, boost::mpl::bool_<true>, boost::mpl::bool_<true>, boost::mpl::bool_<true>>, boost::mpl::bool_<false>, boost::mpl::bool_<false>, boost::mpl::bool_<false>>') (instantiating: 'boost::mpl::aux::or_impl<false, boost::mpl::and_<boost::itl::is_interval_map<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>>, boost::itl::is_interval_map_derivative<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>, std::pair<boost::itl::interval<int, std::less>, int>>, boost::mpl::bool_<true>, boost::mpl::bool_<true>, boost::mpl::bool_<true>>, boost::mpl::bool_<false>, boost::mpl::bool_<false>, boost::mpl::bool_<false>>') (instantiating: 'boost::mpl::and_<boost::itl::is_interval_map<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>>, boost::itl::is_interval_map_derivative<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>, std::pair<boost::itl::interval<int, std::less>, int>>, boost::mpl::bool_<true>, boost::mpl::bool_<true>, boost::mpl::bool_<true>>') (instantiating: 'boost::mpl::aux::and_impl<true, boost::itl::is_interval_map_derivative<boost::itl::interval_map<int, int, boost::itl::partial_absorber, std::less, boost::itl::inplace_plus, boost::itl::inplace_et, boost::itl::interval, std::allocator>, std::pair<boost::itl::interval<int, std::less>, int>>, boost::mpl::bool_<true>, boost::mpl::bool_<true>, boost::mpl::bool_<true>>') and.hpp line 28 > Jeff
2009/9/25 Jeff Flinn <TriumphSprint2000@hotmail.com>:
Jeff Flinn wrote:
Ok, I get an "ambiguous use of partial specialization" compiler error when I add the last line below:
{ typedef boost::itl::interval_map<int, int> OverlapCounterT;
OverlapCounterT overlap_counter; boost::itl::interval<int> itv; itv = boost::itl::interval<int>::rightopen(4,8);
overlap_counter += std::make_pair(boost::itl::interval<int>::rightopen(4,8), 1); }
the compiler error text is:
Error : ambiguous use of partial specialization (point of instantiation: 'CoverageGraphIntervalsTest::testTopology()') (instantiating: 'boost::enable_if<boost::itl::is_intra_derivative<boost::itl::interval_map<int, . . .
well I have studied the tiny error message. As far as I can see the instantiations that are given are correct, they should lead to the right instantiation result and there is no hint from the warrior what exactly is ambiguous to him. It's a little depressing to see how much compilers can disagree, specifically in this enable_if SFINAE minefield. In other words, I don't have a quick fix that I can offer here. What you can try, to get the example running, is to apply member function add overlap_counter.add(std::make_pair(boost::itl::interval<int>::rightopen(4,8), 1)); instead of the overloaded operator +=. Regards Joachim
Joachim Faulhaber wrote:
2009/9/25 Jeff Flinn <TriumphSprint2000@hotmail.com>:
So the next issue is in map.hpp. I'm getting redefined errors on map::add(const std::parit<const _T0, _T1>&) and map::add(std::map<_T0, _T1, _T3<_T0>, _T6<const std::pair<const _T0, _T1>>>iterator, const std::pair<const _T0, _T1>&)
This is via merely #including <boost/itl/split_interval_map.hpp>. It looks like similar issues with map::subtract as well. Hmm, this sounds similar to other problems defining a template methods out of line?
I don't have a CodeWarrior compiler installed on my machine (yet), so I hope you can figure out the details.
I have committed the code changes according to your former posting to the sandbox. Concerning the redefine errors I suspect that your battlesome compiler is not satisfied with the attempt to declare the member function
map& map::add(const value_type&);
and then an overloaded member function template
private: template<class Combiner> map& map::add(const value_type&);
so I changed the names of those private member function templates adding a leading underscore '_add'. The code looses some simplicity but it compiles and works with msvc and gcc.
Ahh, where are the refs to the newly named _add & _subtract private methods? Thanks, Jeff
2009/9/25 Jeff Flinn <TriumphSprint2000@hotmail.com>:
Joachim Faulhaber wrote:
so I changed the names of those private member function templates adding a leading underscore '_add'. The code looses some simplicity but it compiles and works with msvc and gcc.
Ahh, where are the refs to the newly named _add & _subtract private methods?
do you mean refs in the docs or refs in the code?
Joachim Faulhaber wrote:
2009/9/25 Jeff Flinn <TriumphSprint2000@hotmail.com>:
Joachim Faulhaber wrote:
so I changed the names of those private member function templates adding a leading underscore '_add'. The code looses some simplicity but it compiles and works with msvc and gcc. Ahh, where are the refs to the newly named _add & _subtract private methods?
do you mean refs in the docs or refs in the code? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I mean refs in the code. All I did to get to compile with only the header include was to rename the private declaration and definition of _add and _subtract. I didn't change any calls to these private methods, I wasn't sure which to the non-underline-prefixed calls should really be calling the _add/_subtract. Thanks, Jeff
2009/9/25 Jeff Flinn <TriumphSprint2000@hotmail.com>:
Joachim Faulhaber wrote:
Ahh, where are the refs to the newly named _add & _subtract private methods?
do you mean refs in the docs or refs in the code?
I mean refs in the code. All I did to get to compile with only the header include was to rename the private declaration and definition of _add and _subtract. I didn't change any calls to these private methods, I wasn't sure which to the non-underline-prefixed calls should really be calling the _add/_subtract.
I thought you'd update the code from the boost sandbox ... wouldn't that be easier? Here are the applications of _add and _subtract member function templates. I am afraid though that those corrections won't help with the ambiguous partial spec problem applying operator += HTH Joachim --------------- the line numbers might be changed slightly. itl\interval_base_map.hpp(964): section.that()->template _add<codomain_intersect>(value_type(common_interval, sectant.second)) itl\interval_base_map.hpp(974): section.that()->template _add<codomain_combine>(value_type(common_interval, sectant.second)); itl\interval_base_map.hpp(1474): object.template _add<inplace_max>(*elem_); itl\map.hpp(242): return _add<codomain_combine>(value_pair); itl\map.hpp(249): return _add<codomain_combine>(prior, value_pair); itl\map.hpp(257): this->template _add<inverse_codomain_combine>(value_pair); itl\map.hpp(259): this->template _subtract<inverse_codomain_combine>(value_pair); itl\map.hpp(523): section.template _add<codomain_intersect>(sectant); itl\map.hpp(525): section.template _add<codomain_combine>(sectant); itl\map.hpp(573): section.template _add<codomain_intersect>(*sec_); itl\map.hpp(575): section.template _add<codomain_combine>(*sec_);
Joachim Faulhaber wrote:
2009/9/25 Jeff Flinn <TriumphSprint2000@hotmail.com>:
Joachim Faulhaber wrote:
...
I thought you'd update the code from the boost sandbox ... wouldn't that be easier?
Yes it certainly is. I've been able to get what I currently need of the itl to compile/link and pass tests under CodeWarrior 9.4 on windows and Mac. The attached patch file clears up the ambiguous template definition errors I was getting. The culprit was the use of 'using base_type::insert' in boost/itl/map.hpp. CodeWarrior sees both std::map::insert(const value_type&) and itl::map::insert(const value_type&) because of the using declaration unhiding all overloads of std::map::insert. I'm not sure what the standard says about this. So I removed the 'using base_type::insert' and provide an explicit forwarding function to insert(iterator, value_type). This is probably the case for other classes that privately derive from std::containers. There also were two add_front function bodies that didn't use the co_val argument, so I commented out those args to quiet warnings. Jeff Index: boost/itl/split_interval_map.hpp =================================================================== --- boost/itl/split_interval_map.hpp (revision 56475) +++ boost/itl/split_interval_map.hpp (working copy) @@ -229,7 +229,7 @@ template <typename DomainT, typename CodomainT, class Traits, ITL_COMPARE Compare, ITL_COMBINE Combine, ITL_SECTION Section, template<class,ITL_COMPARE>class Interval, ITL_ALLOC Alloc> inline void split_interval_map<DomainT,CodomainT,Traits,Compare,Combine,Section,Interval,Alloc> - ::add_front(const interval_type& inter_val, const CodomainT& co_val, iterator& first_) + ::add_front(const interval_type& inter_val, const CodomainT& /*co_val*/, iterator& first_) { // If the collision sequence has a left residual 'left_resid' it will // be split, to provide a standardized start of algorithms: Index: boost/itl/map.hpp =================================================================== --- boost/itl/map.hpp (revision 56475) +++ boost/itl/map.hpp (working copy) @@ -170,7 +170,7 @@ using base_type::key_comp; using base_type::value_comp; - using base_type::insert; + //using base_type::insert; using base_type::erase; using base_type::find; using base_type::count; @@ -272,6 +272,11 @@ else return base_type::insert(value_pair); } + + iterator insert(iterator position, const value_type& value_pair) + { + return base_type::insert(position, value_pair); + } /** With <tt>key_value_pair = (k,v)</tt> set value \c v for key \c k */ map& set(const element_type& key_value_pair) Index: boost/itl/interval_map.hpp =================================================================== --- boost/itl/interval_map.hpp (revision 56475) +++ boost/itl/interval_map.hpp (working copy) @@ -330,7 +330,7 @@ template <typename DomainT, typename CodomainT, class Traits, ITL_COMPARE Compare, ITL_COMBINE Combine, ITL_SECTION Section, template<class,ITL_COMPARE>class Interval, ITL_ALLOC Alloc> inline void interval_map<DomainT,CodomainT,Traits,Compare,Combine,Section,Interval,Alloc> - ::add_front(const interval_type& inter_val, const CodomainT& co_val, iterator& first_) + ::add_front(const interval_type& inter_val, const CodomainT& /*co_val*/, iterator& first_) { // If the collision sequence has a left residual 'left_resid' it will // be split, to provide a standardized start of algorithms:
2009/9/30 Jeff Flinn <TriumphSprint2000@hotmail.com>:
I've been able to get what I currently need of the itl to compile/link and pass tests under CodeWarrior 9.4 on windows and Mac.
good news :-)
The attached patch file clears up the ambiguous template definition errors I was getting. The culprit was the use of 'using base_type::insert' in boost/itl/map.hpp. CodeWarrior sees both std::map::insert(const value_type&) and itl::map::insert(const value_type&) because of the using declaration unhiding all overloads of std::map::insert. I'm not sure what the standard says about this. So I removed the 'using base_type::insert' and provide an explicit forwarding function to insert(iterator, value_type).
which is better than the combination of 'using' and redefinition.
This is probably the case for other classes that privately derive from std::containers.
I have checked this. I have found no more flaws of this kind.
There also were two add_front function bodies that didn't use the co_val argument, so I commented out those args to quiet warnings.
Jeff, thank you again for contributing work on portability for the itl. I have integrated your patch and checked the code for more flaws of this kind. I have compiled and tested the changes with gcc and msvc and committed the code to the sandbox. Best regards Joachim
Joachim Faulhaber wrote:
2009/9/30 Jeff Flinn <TriumphSprint2000@hotmail.com>:
I've been able to get what I currently need of the itl to compile/link and pass tests under CodeWarrior 9.4 on windows and Mac.
good news :-)
One more warning in interval.hpp, the enum BoundedTypes last value has an inappropriate trailing ','. Not sure why this only showed up on 1 of 6 CodeWarrior target compilations.
The attached patch file clears up the ambiguous template definition errors I was getting. The culprit was the use of 'using base_type::insert' in boost/itl/map.hpp. CodeWarrior sees both std::map::insert(const value_type&) and itl::map::insert(const value_type&) because of the using declaration unhiding all overloads of std::map::insert. I'm not sure what the standard says about this. So I removed the 'using base_type::insert' and provide an explicit forwarding function to insert(iterator, value_type).
which is better than the combination of 'using' and redefinition.
I should clarify that I still get compilation errors/warnings using split_interval_map::operator+=, but rather I'm using the add method.
This is probably the case for other classes that privately derive from std::containers.
I have checked this. I have found no more flaws of this kind.
There also were two add_front function bodies that didn't use the co_val argument, so I commented out those args to quiet warnings.
Jeff, thank you again for contributing work on portability for the itl. I have integrated your patch and checked the code for more flaws of this kind.
I have compiled and tested the changes with gcc and msvc and committed the code to the sandbox.
Cool! Thanks, Jeff
2009/10/1 Jeff Flinn <TriumphSprint2000@hotmail.com>:
One more warning in interval.hpp, the enum BoundedTypes last value has an inappropriate trailing ','.
trailing ',' deleted ;-)
I should clarify that I still get compilation errors/warnings using split_interval_map::operator+=, but rather I'm using the add method.
I'm afraid this is more difficult. Currently I don't have the time (and compiler) to deal with this. But if you'd find a patch, I would be happy to integrate it. Thanks Joachim
Joachim Faulhaber wrote:
2009/10/1 Jeff Flinn <TriumphSprint2000@hotmail.com>:
One more warning in interval.hpp, the enum BoundedTypes last value has an inappropriate trailing ','.
trailing ',' deleted ;-)
I should clarify that I still get compilation errors/warnings using split_interval_map::operator+=, but rather I'm using the add method.
I'm afraid this is more difficult. Currently I don't have the time (and compiler) to deal with this. But if you'd find a patch, I would be happy to integrate it.
It's not high on my list either, as add works. I was just wanting to be more accurate with what was compilable. More importantly, I'd like to be able to use std::inserter of std::back_inserter with std::copy or std::transform to fill the split_interval_map from my domain data. I see there is an insert method, but I'm not sure just how it differs from add. I'd like to see the public interface paired down and just expose the more std::map like interface. Thanks, Jeff
2009/10/1 Jeff Flinn <TriumphSprint2000@hotmail.com>:
More importantly, I'd like to be able to use std::inserter of std::back_inserter with std::copy or std::transform to fill the split_interval_map from my domain data.
Thanks Jeff for raising this issue. The current version did not work so I fixed the code. If you update the code from the sandbox, std::copy should work now with std::inserter for interval_maps.
I see there is an insert method, but I'm not sure just how it differs from add.
(1) For integral domain_types the behavior of 'insert' on interval maps is identical to 'insert' on maps of elements. You could say it has std::insert semantics. Or more formalized: For M: interval_map or split_interval_map of integral domain_types m: itl::map (that implements std::insert semantics) f: atomize: Transforms interval containers into containers of elements. p: interval value pair p': set of element value pairs this diagram commutes insert (M,p) -------> M | | |f = |f | | V Insert V (m,p') ------> m or as a formula: For all M y, p r: f(y.insert(r))==Insert(f(y), f(r)) where capitalized 'Insert' iterates over the set of element value pairs f(r) and then applies member function 'm::insert' on map f(y) for the element level. (2) Member function 'add' does not provide 'std::insert' semantics (in general). It performs an aggregation on associated values, if intervals overvlap or elements collide (aggregate on overlap). Addition (via operator += on codomain_type) is the default, but you can customize via template parameter 'Combine'. see also: http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/con... (3) Both 'insert' and 'add' can be expressed by a more general member function template _add<Combiner> (that has been suffixed by '_' to make life easier for the CodeWarrior ;-) M::insert == M::_add<itl::inplace_identity> M::add == M::_add<itl::inplace_plus> 'inplace_plus' propagates += to aggregate associated values on overlap. 'inplace_identity' propagates the identity function to aggregate values, which leaves them unchanged.
I'd like to see the public interface paired down and just expose the more std::map like interface.
I think that the characteristics of interval containers sets certain limits to the pervasive and powerful use of iterators and algorithms that is known from stl::containers. IMO it makes no sense to try to iterate an interval_set<double>, interval_set<string>, interval_set<rational<int> > etc. on the level of *elements*. Only for interval containers of integral domain_types a completely std conform element iterator can be implemented. But still this would be a permanent invitation to produce inefficient code particularly for cases where the granularity of your intervals is very fine. HTH Joachim
Jeff Flinn wrote:
Jeff Flinn wrote:
template<class Type> struct is_interval_set_derivative<Type, typename Type::interval_type> { typedef is_interval_set_derivative<Type, typename Type::interval_type> type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); };
So isn't this comparable:
template<class Type> struct is_interval_set_derivative<Type, typename Type::interval_type> { typedef is_interval_set_derivative type; BOOST_STATIC_CONSTANT(bool, value = (is_interval_container<Type>::value)); };
Isn't the unadorned name is_interval_set_derivative within the context of this struct definition the same as if it had the template parameters specified?
Yes (and much simpler to type and read, to boot). _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (6)
-
Gottlob Frege -
Jeff Flinn -
Joachim Faulhaber -
Markus Werle -
Simonson, Lucanus J -
Stewart, Robert