Re: [Boost-users] proto: analytical-only math functions

Subject: Re: [Boost-users] proto: analytical-only math functions
From: Hicham Mouline (hicham_at_[hidden])
Date: 2009-02-07 20:02:29

-----Original Message-----
From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Eric Niebler
Sent: 07 February 2009 17:47
To: boost-users_at_[hidden]
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?