GENERIC_CONTROLLERS OK * solve the reference problem for the algebras OK * finalize error_checker and only use them OK * rename to default_error_checker_l2_norm OK * use only with ref the algebra OK * implement the appropriate operations OK * normalization in the operations or separately? * remove error_checker_explicit OK * implement default_error_checker_max_norm (trivial from default_error_checker_l2_norm) OK * implement appropriate operations OK * implement generic_controlled_stepper_explicit_fsal OK * rename generic_controlled_stepper to generic_controlled_stepper_definition.hpp OK * implement generic_controlled_stepper_explicit_fsal in an own class OK * testing NO: * create generic_dense_output from dense_output_runge_kutta * later or never, simply rename dense_output_runge_kutta to generic_dense_output NO * generalize NO * implement dense_output_runge_kutta from generic_dense_output for backward-compatability NOOOO: later or never, simply rename dense_output_runge_kutta to generic_dense_output OK * check dense-output (dopri5, rosenbrock4) OK * implement a test case for dopri5 using dense_output_runge_kutta OK * implement rosenbrock4 in terms of generic_dense_output * check reduce and commutativity of the underlying binary operation * compare performance of reduce and inclusive_scan of thrust NO * introduce operations in controller * LATER, is not necessary now. One can implement easily another controller with appropriate operations * introduce the orders in pi_controller and stiff_controller * introduce controlled_runge_kutta and dense_output_runge_kutta for compatibility * implement reduce2, reduce3 , reduce4 for all algebras * rename reduce to reduce1 * introduce reduce2,reduce3 in array_algebra, fusion_algebra, vector_space_algebra * test the new reduce functions * documentation * check if default_operations can be inherited and the member structs can be overwritten * fork trunk * controllers * move get_value from default_algebra into the utils layer error_stepper: xerr = error( x , xold ) explicit_error_stepper: xerr = error( x , xold , dxdtold ) explicit_error_stepper_fsal: xerr = error( x , dxdt , xold , dxdtold ) default_error: xerr[i] / ( m_abs + m_eps * xold[i] ) default_error_explicit: xerr[i] / ( m_abs + m_eps * ( a_x * xold[i] + a_dtdt * dxdtold[i] ) ) rb: xerr[i] / ( m_abs + m_eps * max( x[i] , xold[i] ) ) norm: val = max_i( xerr[i] ); val = 1 / n * sum_i * xerr[i] * xerr[i]; VORSCHLAG: ein default_error_checker mit norm_policy, error_funktor; error_funktor: je nach stepper norm_policy { public: typedef Value result_type; template< class T1 , class T2 > result_type operator( T1 t1 , T2 t2 ) const { } result_type result( result_type res ) const { } }; * REFACTORING AND CLEANUP * check if everywhere static_cast< value_type > is used * check if rational number are expressed as a / b with a and b integers!, neccessary fpr gmpxx * bessere Namen für dense_output_controlled_explicit_fsal OK * check header guards OK * check copyright note OK * describe every file in the preamble OK * check spacings, not tabs * INTEGRATE FUNCTIONS * dense_output_stepper : call with reset OK * dopri5 in integrate_const does not work - FIXED OK * define EXACTLY what integrate_const and integrate_adaptive for every stepper means, documentate * integrate_adaptive() : start_time , end_time * start_time , t1 , t2 , ... , t_n-1 , end_time ? * OR start_time , t1 , t2 , ... , t_n-1 , t_n, where t_n-1 < end_time and t_n > end_time DONE * THRUST OK * test with controlled steppers (lorenz bifurcations test) * it works, but it does not make sense OK * test with dense output steppers (ensemble test) OK * it works, compare performance between rk4 and dopri5 OK * test with units * thrust will not support units OK * introduce get_value in thrust::operations::rel_error und thrust::operations::max for boost::units * no, we will not do this * check copy implementation in thrust::resize() * DOCUMENTATION OK * Tutorials * Concepts * HOWTO extend odeint OK * use gh-pages, remove html from the source control * doxygen generated reference * RECHERCHE * Hoisting * C++0x * Factory functions, does the make sense * Steppers with state, like FSAL steppers, dense output and multi-step methods * maybe one initialize( system , x0 , t0 , dt0 ) * Generalize and unify controlled steppers, for example rosenbrock controller should be more general * Generalize and unify dense output stepper, for example dense output rosenbrock * same system function interface for implicit_euler and rosenbrock4 * UNIT TEST NEARLY DONE * test operations * test vector_space_algebra, maybe with some proto lib NEARLY DONE * test copying * include controlled_error_stepper_fsal * include dense_output_explicit * inlcude dense_output_controlled_explicit_fsal * test gsl * test explicit stepper with ranges * split check_concepts into check_stepper_concept, check_error_stepper_concept, check_controlled_stepper_concept * include test/thrust in jam system, use system from * ranges and the integrate functions * symplectic intergrators and ranges * adams_moulton complete * adams_bashforth_moulton complete * check once more, if all contructor, destructors and assign-operators are present * UNIT TEST Requirements (NEW): * test stepper concepts * top level concepts (stepper, error_stepper, controlled_stepper, dense_output_stepper) * adjust_size, algebras, various versions of do_step, try_step, ... * test resizing and resize functionality * test copying (copy ctor, assign operator) * stepper results ? * stepper with ranges * stepper with units TO BE DISCUSSED: * Concept Jungle - describe problem, find solution (algebra, do_steps) * boost range enhancement: copy, construct, descruct, resize, adjust_size ... * boost::ref for system functions * algebras as Proto expression and as instances DONE: OK * INTEGRATE FUNCTIONS OK * check forwarding problem, ranges OK * check where exactly the observer will be called (before, after each step?) OK * functions without obversers OK * integrate without stepper , intelligent choice of the stepper OK * check function signatures OK * what to throw? OK * check lambdas, lambda is broken OK * move error_checker into controlled_stepper OK * finishing change of controlled_stepper to units OK * dense output for rosenbrock OK * symplecit_stepper OK * find an appropriate name, (symplectic stroemer nystroem) OK * check is the coefficients are named good OK * include do_step( system , q , p , t , dt ) OK * rename error_checker_standard to default_error_checker OK * check the order of arguments in the observer in integrate functions and initialize in dense_output_stepper OK * decrease complexity: LATER * remove construct, destruct, copy ? OK * remove the overloads solving the forwarding problem. boost::range can not be used then anymore OK * file cleanup OK * split resizing and copy/destruct/construct in different files OK * subfolder algebra, operations, util OK * change standard_operations::rel_error in order to word with units and test it OK * include implicit euler OK * call via std::pair< deriv , jacobi > OK * resizing OK * operations that fit units OK * operations that fit result_of OK * change stepper to stepper_units OK * change error_stepper to error_stepper_units OK * change dense_output to units OK * roll out dense_output_explicit_euler::calc_state() to explicit_euler::dense_output() OK * roll out dense_output_dopri5::calc_state() to explicit_error_dopri5::dense_output() OK * create dense_output_explicit OK * create dense_output_explicit_controlled_fsal OK * change resizing concept, in order to word within the implicit steppers OK * in all tests and regression test do not include odeint.hpp, only include the headers which are really needed OK * start new doc or cleanup the old project OK * unit test OK * test standard_algebra OK * test fusion_algebra OK * test, if copy construct of stepper_base is called when explicit_euler is used OK * test units with dense output OK * include rosenbrock4 in trunk * ranges: OK * test ranges in symplectic_rkn_stepper OK * dense_output OK * explicit_stepper_and_error_stepper_fsal_base OK * controlled_error_stepper OK * check comments (spelling and if the comment is true, in some versions dxdt is already const) OK * check names of the impl functions