On 2 June 2011 19:07, Anders Logg <l...@simula.no> wrote: > On Thu, Jun 02, 2011 at 04:17:19PM +0100, Garth N. Wells wrote: >> >> >> On 02/06/11 16:05, Anders Logg wrote: >> > On Thu, Jun 02, 2011 at 03:53:18PM +0100, Garth N. Wells wrote: >> >> >> >> >> >> On 02/06/11 15:52, Anders Logg wrote: >> >>> On Thu, Jun 02, 2011 at 03:31:31PM +0100, Garth N. Wells wrote: >> >>>> >> >>>> >> >>>> On 02/06/11 15:21, Benjamin Kehlet wrote: >> >>>>> On 2 June 2011 14:59, Garth N. Wells <gn...@cam.ac.uk> wrote: >> >>>>>> >> >>>>>> >> >>>>>> On 02/06/11 12:10, Benjamin Kehlet wrote: >> >>>>>>> On 2 June 2011 11:51, Anders Logg <l...@simula.no> wrote: >> >>>>>>>> On Thu, Jun 02, 2011 at 10:46:29AM +0100, Garth N. Wells wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> On 02/06/11 10:26, Anders Logg wrote: >> >>>>>>>>>> On Thu, Jun 02, 2011 at 10:07:59AM +0100, Garth N. Wells wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On 01/06/11 23:46, Anders Logg wrote: >> >>>>>>>>>>>> Have you checked that there is no performance penalty? >> >>>>>>>>>>> >> >>>>>>>>>>> I just have - evaluating a Legendgre polynomial 10k times at the >> >>>>>>>>>>> same >> >>>>>>>>>>> point is just noise with both methods (of the order 10^-5 - >> >>>>>>>>>>> 10^-4 s). >> >>>>>>>>>> >> >>>>>>>>>> It may be noise for some applications, but not for others. I'm not >> >>>>>>>>>> sure this is a bottle-neck for the ODE code (Benjamin will know) >> >>>>>>>>>> but >> >>>>>>>>>> we need to evaluate Legendre polynomials of degree > 100 many >> >>>>>>>>>> times >> >>>>>>>>>> and then it may not be noise. >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> For very high degree (e.g. 200) Boost is marginally faster. >> >>>>>>>> >> >>>>>>>> Sounds promising then. >> >>>>>>>> >> >>>>>>>>>>> The Boost code is slightly slower because it doesn't cache the >> >>>>>>>>>>> values >> >>>>>>>>>>> (which is nice not to do), but may be faster if the call is >> >>>>>>>>>>> inlined. >> >>>>>>>>>>> It's not possible to inline it at the moment because of clashes >> >>>>>>>>>>> between >> >>>>>>>>>>> tr1:tuple and boost::tuple (Boost bug, I suspect). Old and new >> >>>>>>>>>>> are the >> >>>>>>>>>>> same when evaluating at different points. >> >>>>>>>>>> >> >>>>>>>>>> Let's wait for Benjamin to comment. >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> The speed is about the same (with scope to improve the speed for >> >>>>>>>>> Boost) >> >>>>>>>>> for unique values. The caller should be responsible for caching, if >> >>>>>>>>> desired, since it can lead to memory blow out. >> >>>>>>>>> >> >>>>>>>>> Legendre does not appear in the ode code. It only appears in the >> >>>>>>>>> computation of quadrature schemes. >> >>>>>>>> >> >>>>>>>> True, but the quadrature schemes are used in the ode code. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> Garth >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>>> Garth >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>>> Benjamin has >> >>>>>>>>>>>> worked quite hard on optimizing some of the basic math routines >> >>>>>>>>>>>> (in >> >>>>>>>>>>>> some cases by many many orders of magnitude). >> >>>>>>>>>>>> >> >>>>>>>>>>>> Benjamin, can you take a look that it still works? >> >>>>>>> >> >>>>>>> Yes, the performance seems to be about the same, but I'm unable to >> >>>>>>> compile it with support for GMP. >> >>>>>>> >> >>>>>>> /usr/include/boost/math/special_functions/legendre.hpp:178: >> >>>>>>> instantiated from ‘typename boost::math::tools::promote_args<RT, >> >>>>>>> float, float, float, float, float>::type boost::math::legendre_p(int, >> >>>>>>> int, T, const Policy&) [with T = __gmp_expr<__mpf_struct [1], >> >>>>>>> __mpf_struct [1]>, Policy = >> >>>>>>> boost::math::policies::policy<boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy, >> >>>>>>> boost::math::policies::default_policy>]’ >> >>>>>>> /usr/include/boost/math/special_functions/legendre.hpp:185: >> >>>>>>> instantiated from ‘typename boost::math::tools::promote_args<RT, >> >>>>>>> float, float, float, float, float>::type boost::math::legendre_p(int, >> >>>>>>> int, T) [with T = __gmp_expr<__mpf_struct [1], __mpf_struct [1]>]’ >> >>>>>>> /home/benjamik/fenics/dolfin-wells_gmp/dolfin/math/Legendre.cpp:42: >> >>>>>>> instantiated from here >> >>>>>>> /usr/include/boost/math/special_functions/legendre.hpp:167: error: no >> >>>>>>> matching function for call to ‘pow(__gmp_expr<__mpf_struct [1], >> >>>>>>> __gmp_binary_expr<long int, __gmp_expr<__mpf_struct [1], >> >>>>>>> __gmp_binary_expr<__gmp_expr<__mpf_struct [1], __mpf_struct [1]>, >> >>>>>>> __gmp_expr<__mpf_struct [1], __mpf_struct [1]>, >> >>>>>>> __gmp_binary_multiplies> >, __gmp_binary_minus> >, >> >>>>>>> __gmp_expr<__mpf_struct [1], >> >>>>>>> __gmp_binary_expr<__gmp_expr<__mpf_struct >> >>>>>>> [1], __mpf_struct [1]>, long int, __gmp_binary_divides> >)’ >> >>>>>>> /usr/include/bits/mathcalls.h:154: note: candidates are: double >> >>>>>>> pow(double, double) >> >>>>>>> /usr/include/c++/4.4/cmath:358: note: float >> >>>>>>> std::pow(float, float) >> >>>>>>> /usr/include/c++/4.4/cmath:362: note: long double >> >>>>>>> std::pow(long double, long double) >> >>>>>>> /usr/include/c++/4.4/cmath:369: note: double >> >>>>>>> std::pow(double, int) >> >>>>>>> /usr/include/c++/4.4/cmath:373: note: float >> >>>>>>> std::pow(float, int) >> >>>>>>> /usr/include/c++/4.4/cmath:377: note: long double >> >>>>>>> std::pow(long double, int) >> >>>>>>> [...] >> >>>>>>> >> >>>>>>> boost::math::legendre seems to rely on std::pow which is not >> >>>>>>> templated, only implemented with the most common types. >> >>>>>>> >> >>>>>> >> >>>>>> Looks like some tweaks are required to work with GMP: >> >>>>>> >> >>>>>> http://www.boost.org/doc/libs/1_43_0/libs/math/doc/sf_and_dist/html/math_toolkit/using_udt/use_mpfr.html >> >>>>> >> >>>>> That's not a bad solution, but it requires changing the >> >>>>> multi-precision type from mpf (provided by GMP) to mpfr (which is a >> >>>>> library that extends the floating point functionality in GMP). For >> >>>>> floating-point arithmetic MPFR is much better than pure GMP. I think >> >>>>> CGAL depends on MPFR, so it wouldn't even introduce new dependencies. >> >>>>> The problem is that MPFR doesn't ship with a C++-wrapper (as opposed >> >>>>> to GMP). Although several independent wrappers exists, none of them >> >>>>> are avalilable in Debian/Ubuntu through apt. The one Boost requires is >> >>>>> not updated since 2008 (MPFR has gone from version 2.3 to 3.0.1 since >> >>>>> then). >> >>>>> >> >>>> >> >>>> I've just plonked a copy of gmpfrxx in the DOLFIN dirs to test - it's >> >>>> licensed under GPL. >> >>> >> >>> That won't work. We need LGPL. >> >>> >> >> >> >> I meant LPGL. >> > >> > Good. Does it have the "or any later version"? Otherwise it's still a >> > problem. >> > >> >> No. It's LGPL 2.1. Why is that a problem? > > As far as I understand it would force DOLFIN to be LGPL 2.1 only > (but I hope I'm wrong). > > We just went through a big trouble to secure license agreements from > everyone and it would not be good to restrict those agreements to a > specific version. Furthermore, the agreements say v3 or later so no > one has agreed to 2.1.
This is hard to understand: The README file in gmpfrxx says LGPL v 3 or later. The COPYING file in gmpfrxx lists GPL (sic!) version 3. In the header of the file gmpfrxx.h it says LGPL v 2.1 or any later version (but this may be inherited from the file gmpxx.h from GMP since gmpfrxx.h is a rewrite of gmpxx.h from GMP). Benjamin > > -- > Anders > > >> Garth >> >> >> Garth >> >> >> >>>>> (Another option would be to take the same approach as Boost ourself: >> >>>>> Implement the few functions that are required (pow() plus possibly a >> >>>>> few more) and place it in the global namespace before including >> >>>>> boost::mat::legendre), but GMP does not provide pow() when the >> >>>>> exponent is a floating point number, so this is not straight forward >> >>>>> without switching to MPFR). >> >>>>> >> >>>>> So I guess the question is whether we want to switch to MPFR now, to >> >>>>> get rid of the few lines of code in Legendre.cpp (which performs >> >>>>> reasonably well), when the code is likely to be thrown out pretty soon >> >>>>> anyway. I vote for "no", but I have no problems with moving the entire >> >>>>> ODE solvers to a separate project, then adding it back (without >> >>>>> supporting extended precision) later in the form of code generation >> >>>>> for time dependent problems. >> >>>>> >> >>>> >> >>>> There are a few issues here - even if the ODE code is moved out, I think >> >>>> that we should retain the polynomial and quadrature code in DOLFIN. >> >>>> >> >>>> Garth >> >>>> >> >>>>> Benjamin >> >>>>> >> >>>>>> >> >>>>>> Garth >> >>>>>> >> >>>>>> >> >>>>>>> Benjamin >> >>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>> Mailing list: https://launchpad.net/~dolfin >> >>>>>>>>>>> Post to : dolfin@lists.launchpad.net >> >>>>>>>>>>> Unsubscribe : https://launchpad.net/~dolfin >> >>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> Mailing list: https://launchpad.net/~dolfin >> >>>>>>>> Post to : dolfin@lists.launchpad.net >> >>>>>>>> Unsubscribe : https://launchpad.net/~dolfin >> >>>>>>>> More help : https://help.launchpad.net/ListHelp >> >>>>>>>> >> >>>>>> >> >>>>>> >> >>>> >> >> >> > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
