- Boost-users - lists.boost.org

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

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

05 Apr '06

Comments below > 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. > class ArgTable I think this is not needed if you can use the named parameter library. > class Equation Should be templated 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. SomeFn f = bind(my_fn(),_1,_2); // its not too difficult to understand this as x,y // I'd really like to do double v = f(x=x,y=y); Sohail

1 0

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

05 Apr '06

>Why don't just use Blitz++ for various expressions/equations? ;) I didn't know about blitz++, but I've just now taken a quick look at it. It appears designed for performance above all, which is not the idea behind my equation toolkit. The equation toolkit is designed to let you *easily* write straight-forward equations, combine them, and re-assign them as you want. For instance: ================= Equation e = x + y print e(x -> 1, y -> 2) e = y print e(y -> 9) e = z + 2 * y / a + b print e(a -> 2, b -> 5, y -> 100, z -> 50) ================= The advantage is that you can easily change an equation so you don't actually have to write functions for each equation. If you have a situation where you need to dynamically change around equations a lot during runtime, this system should (ideally) be useful. --Steve

1 0

Equation idea (follow-up)
by Stephen Gross 05 Apr '06

05 Apr '06

Ok, at least one person said they were interested in seeing my idea for an equation toolkit, so here goes... The files a few hundred lines, so hopefully that's ok for this group. If I've exceed some message size, I'm sorry in advance... ======== e.cpp (client code) follows ========= #include "equation.h" #include "equation_enable_macros.h" int main() { equation::Equation a; a = _y + _z; std::cout << a(_y is 5, _z is 10) << std::endl; a = _x + 8 * (_y - _z); std::cout << a(_x is 2, _y is 3, _z is -9000.9) << std::endl; return 0; } ======== equation.h follows (the real work) ========= // Copyright Stephen Gross 2006 #ifndef api_equation #define api_equation #include <string> #include <iostream> #include <map> #include "boost/function.hpp" #include "boost/lambda/lambda.hpp" #include "boost/lambda/bind.hpp" namespace equation { class ArgTable { typedef std::map<std::string, double> MapType; public: ArgTable & setArg(const std::string & name, double val) { my_map[name] = val; return *this; } virtual double getArg (const std::string & name) const { MapType::const_iterator f = my_map.find(name); if(f == my_map.end()) { std::cout << "Error: Equation requested argument '" << name << "' which was not given." << std::endl; exit(0); } else { return f->second; } } private: MapType my_map; }; class ArgTableReporter : public ArgTable { public: virtual double getArg(const std::string & name) const { my_last_var = name; return 0; } const std::string & getLastVar() const { return my_last_var; } private: mutable std::string my_last_var; }; /// /// Represents an Equation, simply put. /// /// The idea here is that, for any Equation that takes named arguments ("x", "y", etc.) and manipulates them /// arithmetically, such an Equation can in fact be encapsulated in an Equation instance. /// /// class Equation { public: typedef boost::function1<double, const ArgTable &> FunctorType; /// @name Constructors //@{ Equation() : my_ftr(boost::lambda::constant(0)) { ; } Equation(const Equation & other) : my_ftr(other.my_ftr) { } template<typename T> Equation(const T & t) : my_ftr(t) { } //@} /// @name The underlying function that invokes the functor: //@{ double go (const ArgTable & args) const { return my_ftr(args); } //@} /// @name operator() //@{ double operator() () { return go(ArgTable()); } template<typename A1> double operator() (const A1 & a1, double v1) const { ArgTable args; ArgTableReporter names; a1(names); args.setArg(names.getLastVar(), v1); return go(args); } template<typename A1, typename A2> double operator() (const A1 & a1, double v1, const A2 & a2, double v2) const { ArgTable args; ArgTableReporter names; a1(names); args.setArg(names.getLastVar(), v1); a2(names); args.setArg(names.getLastVar(), v2); return go(args); } template<typename A1, typename A2, typename A3> double operator() (const A1 & a1, double v1, const A2 & a2, double v2, const A3 & a3, double v3) const { ArgTable args; ArgTableReporter names; a1(names); args.setArg(names.getLastVar(), v1); a2(names); args.setArg(names.getLastVar(), v2); a3(names); args.setArg(names.getLastVar(), v3); return go(args); } template<typename A1, typename A2, typename A3, typename A4> double operator() (const A1 & a1, double v1, const A2 & a2, double v2, const A3 & a3, double v3, const A4 & a4, double v4) const { ArgTable args; ArgTableReporter names; a1(names); args.setArg(names.getLastVar(), v1); a2(names); args.setArg(names.getLastVar(), v2); a3(names); args.setArg(names.getLastVar(), v3); a4(names); args.setArg(names.getLastVar(), v4); return go(args); } //@} private: FunctorType my_ftr; }; namespace Private { class Sigma { public: Sigma() : my_start(0), my_stop(0), my_iter(boost::lambda::constant(0.0)) { } Sigma(double start, double stop, const Equation & eq) : my_start((int)start), my_stop((int)stop), my_iter(eq) { } Sigma(const Sigma & other) : my_start(other.my_start), my_stop(other.my_stop), my_iter(other.my_iter) { } Sigma& operator=(const Sigma & other) { if(this != &other) { my_start = other.my_start; my_stop = other.my_stop; my_iter = other.my_iter; } return *this; } double go (const ArgTable & args) const { ArgTable newargs = args; double result = 0.0; for(int i = my_start; i <= my_stop; ++i) { newargs.setArg("i", (double)i); result += my_iter.go(newargs); } return result; } private: int my_start; int my_stop; Equation my_iter; }; /// /// Helper struct so that unary math functions can be easily macro-ified for constructing Equations. struct UnaryFunc { UnaryFunc(double (*fn) (double), const Equation::FunctorType & arg_getter) : my_fn(fn), my_arg_getter(arg_getter) { } UnaryFunc(double (*fn) (double), double v) : my_fn(fn), my_arg_getter(boost::lambda::constant(v)) { } UnaryFunc(const UnaryFunc & other) : my_fn(other.my_fn), my_arg_getter(other.my_arg_getter) { } UnaryFunc& operator=(const UnaryFunc & other) { if(this != &other) { my_fn = other.my_fn; my_arg_getter = other.my_arg_getter; } return *this; } double go(const ArgTable & args) const { return (*my_fn) (my_arg_getter(args)); } double (*my_fn) (double); Equation::FunctorType my_arg_getter; }; /// /// Helper struct so that binary math functions can be easily macro-ified for construction Equations. struct BinaryFunc { BinaryFunc( double (*fn) (double, double), const Equation::FunctorType & arg1_getter, const Equation::FunctorType & arg2_getter) : my_fn(fn), my_arg1_getter(arg1_getter), my_arg2_getter(arg2_getter) { } BinaryFunc( double (*fn) (double, double), double arg1, const Equation::FunctorType & arg2_getter) : my_fn(fn), my_arg1_getter(boost::lambda::constant(arg1)), my_arg2_getter(arg2_getter) { } BinaryFunc( double (*fn) (double, double), const Equation::FunctorType & arg1_getter, double arg2) : my_fn(fn), my_arg1_getter(arg1_getter), my_arg2_getter(boost::lambda::constant(arg2)) { } BinaryFunc( double (*fn) (double, double), double arg1, double arg2) : my_fn(fn), my_arg1_getter(boost::lambda::constant(arg1)), my_arg2_getter(boost::lambda::constant(arg2)) { } BinaryFunc(const BinaryFunc & other) : my_fn(other.my_fn), my_arg1_getter(other.my_arg1_getter), my_arg2_getter(other.my_arg2_getter) { } BinaryFunc& operator=(const BinaryFunc & other) { if(this != &other) { my_fn = other.my_fn; my_arg1_getter = other.my_arg1_getter; my_arg2_getter = other.my_arg2_getter; } return *this; } double go(const ArgTable & args) const { return (*my_fn) (my_arg1_getter(args), my_arg2_getter(args)); } double (*my_fn) (double, double); Equation::FunctorType my_arg1_getter; Equation::FunctorType my_arg2_getter; }; } // End namespace Private } // End namespace equation #define VAR(name) boost::lambda::bind<double>(&equation::ArgTable::getArg, boost::lambda::_1, std::string(#name)) #define EQ(name) boost::lambda::bind<double>(&equation::Equation::go, &name, boost::lambda::_1) #endif =========== equation_enable_macros.h follows ============ #ifndef api_equation_enable_macros #define api_equation_enable_macros // Disable macros now available: #undef api_equation_disable_macros #define is , #define _a VAR(a) #define _b VAR(b) #define _c VAR(c) #define _d VAR(d) #define _e VAR(e) #define _f VAR(f) #define _g VAR(g) #define _h VAR(h) #define _i VAR(i) #define _j VAR(j) #define _k VAR(k) #define _l VAR(l) #define _m VAR(m) #define _n VAR(n) #define _o VAR(o) #define _p VAR(p) #define _q VAR(q) #define _r VAR(r) #define _s VAR(s) #define _t VAR(t) #define _u VAR(u) #define _v VAR(v) #define _w VAR(w) #define _x VAR(x) #define _y VAR(y) #define _z VAR(z) #define _sigma(start, stop, iter) boost::lambda::bind<double> (&equation::Private::Sigma::go, equation::Private::Sigma (start, stop, iter), boost::lambda::_1) #define _sqrt(x) boost::lambda::bind<double> (&equation::Private::UnaryFunc::go, equation::Private::UnaryFunc (&sqrt, x), boost::lambda::_1) #define _pow(x, y) boost::lambda::bind<double> (&equation::Private::BinaryFunc::go, equation::Private::BinaryFunc (&pow, x, y), boost::lambda::_1) #endif ========= end of code snippets ==============

2 1

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

05 Apr '06

From: "Stephen Gross" <sgross(a)darwin.epbi.cwru.edu> > Ok, at least one person said they were interested in seeing my idea for an > equation toolkit, so here goes... The files a few hundred lines, so > hopefully that's ok for this group. If I've exceed some message size, I'm > sorry in advance... This is a decent start, but I have several problems with it. 1. Types are not template-ized. I don't want everything to be a double. 2. Perhaps variables should be first-class objects, not just placeholders in BLL. 3. (Style not substance) Many of the type and function names aren't very clear. Examples: go() and MapType; 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 It would be cool to then be able to define some sort of 'evaluate' function so that you could write: v = expr.evaluate(10, 20); // v <- 30 Perhaps this is where the BLL comes in, because you'd first have to map the positional arguments to the variables in the expression. Maybe you could also extend this to handle currying. - James

1 0

Problem with memory allocation in UBLAS matrix and vector
by Vasilios Papakos 05 Apr '06

05 Apr '06

Hello, Here is the problem I am having: In the following code (tried to keep it as short as possible), I create a vector [vec1] and a matrix [mat1] in the respective test functions. Then, I create [vec2] and [mat2] in main, but when I print them they have the values of [vec1] and [mat1]. Why is this happening? I am quite new to boost, so I may miss something quite fundamental. I really appreciate you help. System: Fedora Core 4, boost-1.33.1.-5, g++ 4.0.2 Regards, Vasilios ---------------------------------------------------------------------------------------------------------------------------------------------------------- #include <boost/numeric/ublas/vector.hpp> #include <boost/numeric/ublas/matrix.hpp> #include <boost/numeric/ublas/io.hpp> typedef boost::numeric::ublas::matrix<double> ublas_matrix; typedef boost::numeric::ublas::vector<double> ublas_vector; using std::cout; using std::endl; void test_matrix(); void test_vector(); int main() { test_matrix(); ublas_matrix mat2(3, 2); cout << "m2 = " << mat2 << endl; test_vector(); ublas_vector vec2(4); cout << "v2 = " << vec2 << endl; } void test_matrix() { unsigned m = 3, n = 2; ublas_matrix mat1(m, n); for (unsigned i = 0; i < m; ++ i) for (unsigned j = 0; j < n; ++ j) mat1(i, j) = 5.0; } void test_vector() { ublas_vector vec1(4); for (unsigned i = 0; i < vec1.size(); ++i) vec1(i) = i; } ----------------------------------------------------------------------------------------------------------------------------------------------------------

1 0