Re: [Boost-users] [Boost-MPI][Boost-ODEINT] Running odeint within MPI-context without using mpi_state
So, there is no communication between the threads about the step size, and each thread can choose their own step size? Thanks, regards, Roland Am 19.01.21 um 09:52 schrieb Ilja Honkonen: > Hello >> Therefore, is the general idea correct at all, or am I doing something >> wrong here by neglecting a possible communication between the different >> threads within odeint? > > You probably must only use steppers where you decide the step size and > which don't adjust their step size dynamically. Otherwise I guess > you'd have to modify the dynamic step size code to synchronize step > sizes between different mpi processes, etc. > Ilja ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
[Boost-users] [Boost-MPI][Boost-ODEINT] Running odeint within MPI-context without using mpi_state
Hei, I am currently using the odeint-solver for calculating the right hand side of a non-linear equation. For speeding up the calculation of the right hand side, I decided to test the MPI-implementation. Now, after I would prefer to keep the code backwards compatible, I did not want to replace state_type with mpi_state, and instead split up the initial vector by hand before calling odeint without telling odeint that I am operating within an MPI context. I take care of all communications which involve the vectors, and therefore I assumed that this approach should work (especially after it worked correctly in small test programs). Nevertheless, I encountered the issue that after a certain amount of steps the step size between the different threads starts to differ by a small amount, even though I am in the same iteration. As example: step number rank step size n 1 0.00025 n 0 0.00025 //Ok n + 1 1 0.00051152 n + 1 0 0.000511523 //Not ok I checked my program with valgrind for possible memory leaks/corruption which could overwrite something, but nothing relevant came up. The problem is repeatable. Therefore, is the general idea correct at all, or am I doing something wrong here by neglecting a possible communication between the different threads within odeint? Thanks! Regards, Roland ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
[boost] Re: Imminent Code Breakage
David Abrahams wrote: The permutation iterator in particular is *really* easy. Off-the-cuff: template class ElementIterator, IndexIterator [...] }; I'm just guessing. Why don't you put this through its paces, then contribute revised documentation and tests for the new library? Done. No documentation yet, but header file plus test. Should I commit it, and if so, where to? - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Library Proposal: Event-Driven Values
Dear Nicolas,
sorry for the late reply. Some other projects try to keep me busy.
First, I'd like to mention that in German-speaking countries, EDV
is a very common acronym for Elektronische Datenverarbeitung
(electronic data processing), hence the library name might be
somewhat confusing.
I think that your ideas lead into two rather different directions,
depending on whether these event-driven values
(a) actively update their related values whenever changed, or
(b) are passive and do nothing until their value is fetched.
Let me explain this point using your sum example:
concrete_valueint i(4), j(6);
sum_valueint sum(i, j); // sum now equal to 10
i = 6; // sum now equal to 12
Yeah, right, sum is 12 now - but who cares? It might be 13 or 14
or 2893457923 - you wouldn't notice the difference only until the
value of sum is actually fetched. Oh wait, somebody did just that
some lines later:
sumsum = 2 * sum;
Only here the value of sum gets visible to the outer world, and only
here there is any need to re-calculate its value - a technique called
lazy evaluation (for obvious reasons).
If you intend to follow that path - lazy evaluated values - what
you are really doing is symbolic math: forming expressions out
of operators (+, -, ==) and variables (i, j, sum) which might or
might *not* represent a numeric value.
Most major mathematical software distributions work in just that
way and allow you to do something like this:
sum = i + j; // sum evaluates to i + j, because neither i nor j are
// yet bound to a numerical value
i = 6;// sum evaluates to 6 + j
j = pi; // sum evaluates to 6 + pi, or 9.14159.
For a symbolic math package in C++, I'd point you to http://www.ginac.de
I guess, however, that your main interest lies in variant (a),
event-driven (opposed to lazy evaluated) values, that is, in
implementing some special form of the Subject/Observer pattern,
based on boost::signals.
For reasons I pointed out above, this would just make sense if your
main focus is *not* on updating other values, but on triggering some
action, like this:
void print_me( int i )
{
std::cout i std::endl;
}
valueint i( 6, print_me );
i = 42; // Prints 42 to stdout.
In other words, valueType would be some type where construction,
assignment, and maybe destruction would call some signals. This might
include, but is not limited to, updating other values.
Such a class might indeed be helpful, because notifications often occur
if a value has changed; so this would simplify things. However, I doubt
whether it pays off to invent all those sum_, diff_, sync_, and_so_on_value's
in an event-triggers-update-of-values way.
- Roland
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Determining interest in combining_iterator
Hi Thomas, some time ago I was in the very same situation that I needed an iterator of tuples - or a tuple of iterators, which virtually is the same IMO. My solution then was to extend tuple functionality, i.e. to add everything that a good iterator requires, such as dereference, operator++() etc., to a tuple type (not boost:tuple, but a 'tupple' type of my own. Hm.) About three months ago, I released that stuff to Boost Sandbox, where it sits (in directory 'tupple') rather unnoticed (lack of marketing, I guess), Thanks for your kind words. I'll play with the sanbox stuff. Is the main purpose there to incorporate better iterator categories? Anyway, I won't take any further action until all that has settled down. so if you play with the sandbox stuff, you might as well check it out. (Hint: open boost/tupple/detail/container_tupple_part_spec.hpp and search for 'iterator_tuple'. Don't blame me for indentation, this is generated code.). I don't really know which approach - iterator of tuples vs. tuple of iterators - is better, but comparing the two approaches might yield some insight. I'd be really interested in an exchange of ideas, - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Review: variant iterators
Rozental, Gennadiy wrote: 1. I found this name a bit misleading. At first I though that it some king of iteration through variant types Uhm, what would be a better name? 2. From quick glance on your code it seems that visit_helper class unnessesarilly parameterized with T0 and T1. It's far from perfect, and I'll consider this one; however, I don't want to go too deep into such issues as long as the variant library interface is not (?) stable. - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] tokenizer: Feature request: keep quotes with escaped_list_separator
Dear all, I need to split a string into tokens, and split the resulting tokens again in a second pass. Currently, I do this with boost::tokenizer initialized with an escaped_list_separator. The problem is that all the quote characters are swallowed during the first pass, which makes things rather ugly at the second time. One workaround I thought of, namely to use two different (sets of) quote characters, is inacceptable in our case. Are there any other? If not, it would be rather nice to have a switch to tell escaped_list_separator whether it should drop quotes or keep quotes. - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Broken links in multi_array docs
In multi_array's reference manual, Table 2, the three links in the sentence Otherwise it models _Random Access Traversal Iterator_, _Readable Iterator_, and _Writable Iterator_. seem to be broken. - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] permutation_iterator and MSVC
Hi,
as mentioned in the docs, it is necessary to tell MS VC++
all template parameters of an iterator_adaptor *explicitly*.
Unfortunately, it seems one cannot do that for a permutation_iterator,
since permutation_iterator_generator just takes ElementIterator
and IndexIterator as its template parameters.
I propose extending the code like this:
template typename ElementIterator, typename IndexIterator,
// Reasonable default, but can be passed explicitly for MSVC:
typename ValueType = boost::detail::iterator_traitsElementIterator::value_type
// etc.
struct permutation_iterator_generator
{
typedef boost::iterator_adaptor
ElementIterator,
permutation_iterator_policies IndexIterator ,
ValueType
// etc.
type;
};
in order to write something like
typedef permutation_iterator_generator
element_range_type::iterator,
index_type::iterator,
element_range_type::value_type // tells MSVC++ the value_type
::type
to keep MSVC quiet.
I'm not sure, but I think I saw the same trick for some other
iterator adaptors. Comments?
- Roland
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: The Wonder of Tuples
There has been some out-of-list discussion about this, and some work is being done. There's a PP based tuple implementation (mostly written by Joel) in Spirit's CVS that conforms to the Tuple speicification in the TR. Where is it? Do you refer to the files under spirit/spirit/boost/preprocessor/tuple, or is there something else? - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: The Wonder of Tuples
David A. Greene wrote:
The fundamental problem is that it's inconvenient to iterate through a
tuple. All we have is the get template to access tuple elements.
Iterating is again conceptually simple -- just increment an index.
But the fact that get is a template implies the index must be a
compile-time constant, meaning we need a compile-time loop (or, if
you prefer, programmer-controlled loop unrolling) to iterate.
Iteration through a tuple is indeed not so simple, but *recursion*
is, and you can do that at runtime.
All you need is to get the head and the tail out of a tuple, and,
in turn construct a tuple out of head and tail. Boost.Tuple provides
that: get_head() and get_tail(), although it is not mentioned
in the docs (why?).
I'm not sure whether I completely understand what you need (did I?),
but here is how I'd do it. Anyway, the idea of iterating through
a tuple - and also the spanning_iterator thing - sounds interesting.
- Roland
#include iostream
#include functional
#include boost/tuple/tuple.hpp
using namespace boost::tuples;
// Executes op() on the first member of tuple t if that meets cond(),
// recurses into the tail of t otherwise.
templateclass TupleT, class OpT, class CondT
TupleT do_if_first( TupleT t, OpT op, CondT cond )
{
typedef cons typename TupleT::head_type,
typename TupleT::tail_type cons_type;
if( cond( t.get_head() ) )
{
return TupleT( cons_type( op( t.get_head() ), t.get_tail() ) );
}
else
{
return TupleT( cons_type( t.get_head(), do_if_first( t.get_tail(), op, cond ) ) );
}
}
// Stops recursion.
templateclass OpT, class CondT
tuplenull_type do_if_first( null_type t, OpT op, CondT cond )
{
return tuplenull_type();
}
void main()
{
tupledouble,char,int t1( 3.14, 'a', -5 );
std::cout t1.get_head() std::endl
t1.get_tail().get_head() std::endl
t1.get_tail().get_tail().get_head() std::endl std::endl;
tupledouble, char, int t2 =
do_if_first( t1, bind2nd( multipliesdouble(), -2.0 ), bind2nd(lessdouble(), 0) );
std::cout t2.get_head() std::endl
t2.get_tail().get_head() std::endl
t2.get_tail().get_tail().get_head() std::endl;
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Tupples released to sandbox
Dear all, today I imported another set of files to Sandbox CVS, this time something I'd like to call 'tupples' (yes, two p's). + What is it? You all know Boost.Tuples (with one 'p'), right? Well, tupples is almost the same, only different. There are two major differences: 1) I wanted to use tuples of (STL) containers and iterators such that a tuple of containers appears as a container of tuples, etc. For all of you who are familiar with views: that's necessary to implement a generalization of zip_view. 2) The mechanism behind the scene is completely different. While Boost.Tuples relies on tricky template-metaprogramming, the code for tupples is generated with the help of the Boost.Preprocessor library. That's a brute-force approach, and by the way the reason for the double 'pp'. Apart from that, I tried to design the whole library to be as close as possible to Boost.Tuple. + What next? David A. Greene recently brought up the issue of iterating through all elements of a tuple. Might be worth some thoughts ... Comments are appreciated, as always. - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Views a.k.a. container_adaptors released to sandbox
Dear all, I would like to announce that I finally imported the first set of Boost.View classes to the Boost-Sandbox CVS. + What is it? A view is a light-weight, immutable decorator to some existing data. Usually, it will provide the same interface as a STL container. In much the same way as an iterator adaptor wraps a dumb STL iterator and adds functionality, a container adaptor or view wraps a STL container and attaches some further functionality. The topic recently has been discussed following news://news.gmane.org:[EMAIL PROTECTED] + History? The first to introduce a view library was Jon Seymour back in 1995, http://www.zeta.org.au/~jon/STL/views/doc/views.html The most complete implementation of views so far was (and still is) the View Template Library by Gary Powell and Martin Weiser, http://www.zib.de/weiser/vtl/ In contrast to these implementations, Boost.View relies on iterator_adaptors, which made implemention much easier. + What next? Some further views (zip_view etc) are on the way; however, since these require an extended tuple type (tuples for iterators, containers etc), I intend to commit such a tuple type first. Rumors have it that iterator_adaptors is redesigned from scratch. I'd like to hear any news... + Platforms? Boost.View was tested with + gcc 2.95.3-6 (mingw special), gcc 3.2 (cygwin prerelease) and Boost 1.29.0 + MSVC 7 and Boost 1.28.0 - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Views a.k.a. container_adaptors released to sandbox
Does this mean a view is mutable? For example, using Boost.View, can I write a boundedstd::list that automatically drops the last element on push_front if size() is at some upper limit value before adding the new element? This is the sort of thing I No. A view is not mutable; sometimes the underlying data is. Methods for inserting and removing elements, however, are typically *not* part of a view's interface. - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] lexical_cast and bool
Dear all, just a minor issue for the upcoming(?) lexical_cast in 1.30.0: lexical_castbool( true ) returns false, since std::ios::boolalpha is not set by default. How about changing this? - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
