-----Original Message-----
From: boost-users-bounces@lists.boost.org Sent: 09 February 2009 17:25 To: boost-users@lists.boost.org Subject: Re: [Boost-users] proto: analytical-only math functions Hicham Mouline wrote:
Hello, I pasted the code I have so far in http://codepad.org/gk9KoR31 a really cool tool indeed. First, let me recap my objective 1. I have a mathematical functions DSEL which accepts "constants", "variables", "basic functions" and "functions". "constants" are so in the mathematical sense in that not in the computational sense. f(x) = x +c24; // meaning f depends on 1 variable only x, and deriving f wrt to x will give 1 "constants" are predeclared by the library. The grammar allows only c24= const-expression; // Assignment operator, takes a const expression tree RHS "variables" are predeclared by the library. They cannot be assigned values. They serve for derivation, integration and in other equation systems. "basic functions" are c++03 cmath defined functions ( I shall make them lazy functions like in the user guide ), of which derivatives and integrals are known. "functions" are user defined functions, the EBNF of which is to be defined later. Not predeclared by the library. My questions (please refer to the code): 1. Templating constant_tag with unsigned int, will it be recognized in the grammar by terminal< constant_tag< _ > > ? 2. I declared a constants_domain tag, which I don't know how to define. The grammar is an inner type of the expression wrapper constant_wrapper to make it easy in the grammar to exclude the constant being assigned to. What should constants_domain inherit from proto::domain< constants_domain, ????? > 3. I'm taking the idea for constant_wrapper from the user guide. The 2nd arg of proto::extends is constant_tag<subscript>, the expression being wrapped, while the templ arg of constant_wrapper in "unsigned int" ? 4. Does convertible<double> describe all integer and floating literals as well as integer and floating runtime variables? 5. I make operator= returns just c24 itself, so that if an expression tree meets ( c24=.... ), the whole thing is replaced by c24, right? Based on your experiences with defining DSEL, would this make sense? 6. constdef_rhs_grammar is an inner type grammar for the RHS of =. The LHS of = is simply constdef_lhs_grammar Should constdef_grammar just be the commented code? 7. The biggest question ( I feel I will have to let this go for now ) 7.1. If e, the argument in = operator, contains only literals, I want e to be evaluated at compile time, and be assigned to c24. Should I make constant_tag<24> hold a member double ( that can be NaN meaning undefined, or the result ) and another member (what type?), to store the const-expression being assigned to it? 7.2. If e contains only literals and convertible to double runtime variables, I want = to evaluate e to the number and store it... 7.3. If e contains other math constants (constant_tag<>), evaluation is not possible and the canonical expression should be stored ( for e.g. c24 = c25+c0 - c0 -5 should be stored as c24 = c25 -5 if c25 is undefined, otherwise store the result )... I suspect this is not possible as I saw a similar question by Joel Falcou about this.... Thank you very much, regards,