- Boost-users - lists.preview.boost.org

Re: [Boost-users] equation (really expression) idea
by james.jones＠firstinvestors.com 06 Apr '06

06 Apr '06

From: "Stephen Gross" <sgross(a)darwin.epbi.cwru.edu> > >1. Types are not template-ized. I don't want everything to be a double. > This is an interesting point. My goal so far has been to prioritize > simplicity above all. The purpose of the toolkit is for letting people write > arithmetic equations easily. In light of that, I think sticking with doubles > makes sense. So if I want to use a rational class, or a higher-precision double provided by a library, or a fixed-precision class, or a boolean type (a la Excel: if(x<y,x,y)) I'm out of luck? I appreciate simplicity of use, but you can still accomplish this by letting double be the default type (which makes sense, I think). Then non-power-users get double all the time, and power users can still do some hacking. > Well, this is an interesting idea but it runs contrary to the metaphor I > want. In the above example, the variables 'x' and 'y' work as global > variables. I want the user to have to pass x and y directly to the equation. I agree - which is why I wrote the bit about an evaluate function that takes positional arguments. Maybe named arguments are even better, though. I hadn't thought of that. > If you had global-level variables, then it would be difficult to make the > above example work properly (passing z on as x and y when f2 invokes f1).. Please don't call them globals - they aren't. They're in the same scope as the expression. However, as to your particular issue, this isn't a problem: variable x, y, z; expression expr1 = x + y; expression expr2 = z + expr1; A variable is just a special form of an expression, after all. As to mapping, it would be nice to be able to write code like: double v = expr1(x=5,y=10); double w = expr2(x=2,y=3,z=8); I should think the Boost parameter library could handle this. Actually, maybe you don't even need the Boost parameter library. Just define operator() on expression to ignore its arguments (then x=5, y=10 sets the values of x and y, and expr1 is then evaluated in that context). - James

2 1

Cross compiling to Arm.
by James Hughes 06 Apr '06

06 Apr '06

Hello all, Just quick question. Has anyone managed to cross compile Boost from a Linux X86 host to ARM using a gcc compiler? Is so, which version of the compiler did you use and which version of boost? I am having problems with iwmmxt_le-g++ v 3.4.3 and boost:1.33.1, in the Spirit libs (as previously posted). It appears to be a compiler fault...which is not evident inthe non-cross compiler version of g++ 3.4.3. James

1 0

Spirit: Assigning elements of a closure member.
by Mark Williams 06 Apr '06

06 Apr '06

Is there any standard way, in a semantic action, to assign individual elements of a struct that is set as a member of a closure? For example suppose I have:- struct foo { int a, b, c; std::string d; float e; }; And I have this as member1 in my closure, which is then attached to a rule that parses each of those struct member elements seperately, is there then a standard way within the semantic actions in my rule to assign to foo.d, say, without modifying the other values? It seems that my only option is to either write my own functors to set each member seperately, or have the individual elements as seperate members of my closure. I kind of want to do something like this: myrule = int_p[assign_a(myrule.m1.a)] >> int_p[assign_a(myrule.m1.b)]; But myrule.m1 is an actor, not an instance of foo. Is there a way to do this with boost::bind perhaps? I want to use closures since my rules need to be reentrant. Mark

1 1

Assertions doesn't work!
by Kiuhnm 05 Apr '06

05 Apr '06

I'm using MSVC8 (2005) with Boost 1.33.1. The code at the end of this post should cause the compiler to print out something like this (GCC): conversion from 'mpl_::failed ****************(factorial<mpl_::int_<-5> >::FACTORIAL_of_NEGATIVE_NUMBER::****************) (mpl_::int_<-5>)' to non-scalar type 'mpl_::assert<false>' requested. but I obtain something completely different. It seems that the compiler continues to evaluate the factorial (-1, -2, -3, ...) ignoring the assertions. Since the template expansion is quite "complex", the compiler fails and prints out: --- fatal error C1202: recursive type or function dependency context too complex c:\boost\include\boost-1_33_1\boost\mpl\aux_\preprocessed\plain\times.hpp(60) : see reference to class template instantiation 'factorial<N>' being compiled with [ N=boost::mpl::int_<-88> ] --- What's wrong? --- #include <boost/mpl/assert.hpp> #include <boost/mpl/greater_equal.hpp> #include <boost/mpl/equal_to.hpp> #include <boost/mpl/multiplies.hpp> #include <boost/mpl/prior.hpp> #include <boost/static_assert.hpp> namespace mpl = boost::mpl; // specializations are nullary metafunctions that compute n>0 template <int n> struct FACTORIAL_of_NEGATIVE_NUMBER : mpl::greater_equal<mpl::int_<n>, mpl::int_<0> > {}; template <class N> struct factorial : mpl::eval_if< mpl::equal_to<N,mpl::int_<0> > , mpl::int_<1> , mpl::multiplies< N , factorial<typename mpl::prior<N>::type> > > { BOOST_MPL_ASSERT((FACTORIAL_of_NEGATIVE_NUMBER<N::value>)); BOOST_STATIC_ASSERT((0)); // !!! BOOST_MPL_ASSERT_MSG(N::value >= 0, FACTORIAL_of_NEGATIVE_NUMBER, (N)); // !!! }; int main() { int f = factorial< mpl::int_<-5> >::type::value; } --- Thank you, Kiuhnm -- View this message in context: http://www.nabble.com/Assertions-doesn%27t-work%21-t1401263.html#a3770376 Sent from the Boost - Users forum at Nabble.com.

2 1

Re: [Boost-users] Boost-users Digest, Vol 866, Issue 4
by Stephen Gross 05 Apr '06

05 Apr '06

Message: 10 Date: Wed, 5 Apr 2006 10:52:07 -0700 From: "Sohail Somani" <s.somani(a)fincad.com> Subject: Re: [Boost-users] Equation idea (follow-up) To: <boost-users(a)lists.boost.org> Message-ID: <1C1EBEF8DBACDC439D038EA051674EC728BE13(a)xbox.financialcad.com> Content-Type: text/plain; charset="us-ascii" >Because people want to use different types. For example, some systems may support higher precision for long double. I think you have a good point on this one... The trick is to find a way to do it that keeps the client syntax as simple. >I think most boost users are pretty much power-users (for better or worse). Sure, so I guess the question is more like this: If we accept the premise that the intended users of the toolkit aren't power users, then does it make sense for boost to include? I think you have a valid point that maybe it's not appropriate for boost. But at the same time, I figured that since it's built so directly off of boost, it might be helpful. Then again, maybe the best place for the equation toolkit is in a different toolkit bundle...? --Steve

2 1

Re: [Boost-users] equation (really expression) idea (follow-up)
by Stephen Gross 05 Apr '06

05 Apr '06

>1. Types are not template-ized. I don't want everything to be a double. This is an interesting point. My goal so far has been to prioritize simplicity above all. The purpose of the toolkit is for letting people write arithmetic equations easily. In light of that, I think sticking with doubles makes sense. 2. Perhaps variables should be first-class objects, not just placeholders in BLL. Maybe... The whole idea, though, is basically to macro-ify some boost::lambda::bind operations so that you let lambda do the heavy lifting of actually combining all the functors together. 3. (Style not substance) Many of the type and function names aren't very clear. Examples: go() and MapType; Sure; style can always be worked on. Right now, it's not very well-documented anyway so some of the implementation may not be intuitive. >I'm thinking the client syntax should be something more like this: expression expr; variable<double> x; variable<int> y; expr = x + y; double v = expr; // would throw because x and y are unassigned x = 10; y = 20; v = expr; // assigns 30 to v Well, this is an interesting idea but it runs contrary to the metaphor I want. In the above example, the variables 'x' and 'y' work as global variables. I want the user to have to pass x and y directly to the equation. There's another reason for this: If one equation uses another equation, you have to make sure the equations use the right variables. Consider this: Equation f1 = x + y Equation f2 = z + f1(x -> z, y -> z) print f2(9) If you had global-level variables, then it would be difficult to make the above example work properly (passing z on as x and y when f2 invokes f1).. --Steve

2 1

Re: [Boost-users] I NEED HEMP PLEASEeeeeeeeeeeeeee
by Sohail Somani 05 Apr '06

05 Apr '06

I don't think this is the right list to discuss these things. (Sorry, I had to)

1 0

Re: [Boost-users] Boost-users Digest, Vol 866, Issue 4
by Sohail Somani 05 Apr '06

05 Apr '06

> >I think most boost users are pretty much power-users (for better or > worse). > > Sure, so I guess the question is more like this: If we accept > the premise > that the intended users of the toolkit aren't power users, > then does it make > sense for boost to include? I think you have a valid point > that maybe it's > not appropriate for boost. But at the same time, I figured > that since it's > built so directly off of boost, it might be helpful. Then > again, maybe the > best place for the equation toolkit is in a different toolkit > bundle...? Im sure you'd get a really great response on a numerical analysis type forum (I think there is a newsgroup sci.math.num-analysis or something) Sohail

1 0

Re: [Boost-users] Equation idea (follow-up)
by Sohail Somani 05 Apr '06

05 Apr '06

> >> class Equation > >Should be templated > > Why? Because people want to use different types. For example, some systems may support higher precision for long double. > The idea is that the target users for this toolkit aren't > power-users. Quite > the contrary: I work with a lot of scientists, and they have > rudimentary > C/C++ skills. This system would let them write equations > without having to > learn template syntax or, for that matter, much about > function declarations. I think most boost users are pretty much power-users (for better or worse). If your stuff is compatible with boost/tr1 function (and it seems that it is, just might be missing some tyepdefs), then that's a step in the right direction. Sohail

1 0

Re: [Boost-users] Equation idea (follow-up)
by Stephen Gross 05 Apr '06

05 Apr '06

>> std::cout << a(_y is 5, _z is 10) << std::endl; >I do think the idea of assigning inputs at the call site is important which is what you've done. It would be nice to use the named parameter library here if possible to get rid of the leading underscores. I've played around a little with the parameter library, but it requires you to pre-register variable names (I think???). With this system, you can either use the underscore-letter name, or just wrap the name in the VAR() macro (eg: Equation e = VAR(foo) + VAR(bar); cout << e(VAR(foo) is 9, VAR(bar) is 10). ) >> class Equation >Should be templated Why? >I don't know what this offers over boost bind and function. I use these to do a lot of this type of stuff. As long as the number of parameters are low, its easy to understand and you get some currying for free. The idea is that the target users for this toolkit aren't power-users. Quite the contrary: I work with a lot of scientists, and they have rudimentary C/C++ skills. This system would let them write equations without having to learn template syntax or, for that matter, much about function declarations. >// I'd really like to do >double v = f(x=x,y=y); I think the system I've proposed will do what you're asking: Equation f = _x + _y; double v = f(_x is 5, _y is 8) --Steve

1 0