
-----Original Message----- From: Hicham Mouline [mailto:hicham@mouline.org] Sent: 08 February 2009 01:02 To: 'boost-users@lists.boost.org' Subject: RE: [Boost-users] proto: analytical-only math functions -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Eric Niebler Sent: 07 February 2009 17:47 To: boost-users@lists.boost.org Subject: Re: [Boost-users] proto: analytical-only math functions Hicham Mouline wrote:
The grammar of the LHS function definition seems correct. The compilation takes too long however (using here intel/msvc libs). See the main.cpp and includes below.
Any ideas how to speed compile time up?
<snip> There are ways to speed up Proto grammars, but the result is less terse and fungible. I wouldn't worry too much about compile times right now. From what I can tell, you're still in the early phases of your DSEL design. An expressive, agile DSEL definition will give you freedom to experiment. Once things are working to your satisfaction, you can think about replacing some of the complicated composite transforms with custom primitive transforms, as described here: http://boost-sandbox.sf.net/libs/proto/doc/html/boost_proto/users_guide/back _end/expression_transformation/primitives.html HTH, --------------------------------------------
Thank you,
Re my constants definitions (my constant terminals are defined as proto::terminal< constant_tag<24> >::type c24; ), the allowed syntax is : c24 = const_expression; // const_expression cannot include c24
a loose EBNF for my const_expression is:
const_expression :: integer-literal e.g. 7 | floating-literal e.g. 5.4 | integer-type runtime variable e.g. int x, long y (known only at runtime) | fp runtime variable e.g. float r, double q (known only at runtime) | my DSEL constants | - const_expression | const_expression + const_expression | const_expression - const_expression | const_expression * const_expression | const_expression / const_expression | const_expression % const_expression | basic_function( const_expression ) | function( const_expression, ..., const_expression ) // respect the dimensionality
I don't see I am missing anything obvious?
The concept of const_expression here is not meant that the value of the expression is known at compile-time. It only means that on taking the derivatives of my functions wrt to my DSEL variables, the const_expression disappears.
In order to exclude the constant being defined from the = RHS, I need to define the grammar wholly for LHS and RHS of = at the same time, I couldn't define RHS grammar alone because I need to exclude c24, right?
----------------------------------- By the way, I can't find unary_minus<> in proto, how come? rds,