Formal review request: static size matrix/vector linear algebra library (Boost) LA
Documentation and source code complete with comprehensive tests, released under the Boost Software License is available here: http://www.revergestudios.com/boost-la/ Thanks, Emil Dotchevski
Emil Dotchevski wrote:
Documentation and source code complete with comprehensive tests, released under the Boost Software License is available here:
Can you tell what has changed since http://lists.boost.org/Archives/boost/2009/10/157156.php ? Is it worth for me to review it again, or did you just posted this because of the "linear algebra library... again" message from DE? (Just curious, I don't want to imply that your initial submission wasn't sufficient for a formal review request.) Regards, Thomas
On Tue, Feb 2, 2010 at 12:42 PM, Thomas Klimpel <Thomas.Klimpel@synopsys.com> wrote:
Emil Dotchevski wrote:
Documentation and source code complete with comprehensive tests, released under the Boost Software License is available here:
Can you tell what has changed since http://lists.boost.org/Archives/boost/2009/10/157156.php ? Is it worth for me to review it again, or did you just posted this because of the "linear algebra library... again" message from DE? (Just curious, I don't want to imply that your initial submission wasn't sufficient for a formal review request.)
The difference is that this is a formal review request as per the Boost submission process. Nothing has changed because nobody pointed out anything that needed to be changed in the preliminary review. There are a few concerns, like the use of operator| ("pipe") to implement type-safe casting but I am not aware of a better solution. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
El 02/02/2010 06:35 p.m., Emil Dotchevski escribió:
On Tue, Feb 2, 2010 at 12:42 PM, Thomas Klimpel Nothing has changed because nobody pointed out anything that needed to be changed in the preliminary review. There are a few concerns, like the use of operator| ("pipe") to implement type-safe casting but I am not aware of a better solution.
I have been happily using this library for a while, and I have a couple of suggestions/observations. · I've often found the need to forward the result of some Boost.LA operation. To do so, I'm using types from the detail namespace to specify the return type. Until auto and decltype, and for C++03 support, a result_of namespace ala Boost.Fusion would be nice. · Support for subscript operator may be introduced via vref/mref. So vref( any_conforming_vertex_type )[ I ] could be used for both direct indexing and swizzling (as mentioned at your blog). · Support for "complex swizzling expressions" would be nice. I've just made that name up, but I'm referring to things like 'v1[Y,-X]' or 'v1|(Y,-X)' (again, as mentioned at your blog). · More algorithms to operate on vectors and matrices are needed, otherwise people would be reinventing the same generic algorithms. Ideally, I would like to see everything that is available at GLSL, including component-wise boolean operations. Finally, I'm not keen on the library name, but I don't have a better one to suggest. Let me say I have in the past unsuccessfully tried to implement a library like yours myself. I find the abstraction incredibly useful, and I am glad that you managed to write it. K-ballo.- http://talesofcpp.blogspot.com
2010/2/4 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
El 02/02/2010 06:35 p.m., Emil Dotchevski escribió:
On Tue, Feb 2, 2010 at 12:42 PM, Thomas Klimpel Nothing has changed because nobody pointed out anything that needed to be changed in the preliminary review. There are a few concerns, like the use of operator| ("pipe") to implement type-safe casting but I am not aware of a better solution.
I have been happily using this library for a while, and I have a couple of suggestions/observations.
· I've often found the need to forward the result of some Boost.LA operation. To do so, I'm using types from the detail namespace to specify the return type. Until auto and decltype, and for C++03 support, a result_of namespace ala Boost.Fusion would be nice.
Good point. Can you elaborate on your needs to forward results from functions? Is it possible that the library is missing some important functions that you had to implement yourself?
· Support for subscript operator may be introduced via vref/mref. So vref( any_conforming_vertex_type )[ I ] could be used for both direct indexing and swizzling (as mentioned at your blog).
Good idea. I wish this could be introduced non-intrusively though...
· Support for "complex swizzling expressions" would be nice. I've just made that name up, but I'm referring to things like 'v1[Y,-X]' or 'v1|(Y,-X)' (again, as mentioned at your blog).
Great idea. I wonder what other expressions would make sense, besides minus.
· More algorithms to operate on vectors and matrices are needed, otherwise people would be reinventing the same generic algorithms. Ideally, I would like to see everything that is available at GLSL, including component-wise boolean operations.
I'll take a look at what GLSL has and add what makes sense. Also, I am planning to add support for quaternions.
Finally, I'm not keen on the library name, but I don't have a better one to suggest.
I'm not keen on the library name either. I'm open for suggestions. Thanks for the kind words, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
El 05/02/2010 12:09 a.m., Emil Dotchevski escribió:
· I've often found the need to forward the result of some Boost.LA operation. To do so, I'm using types from the detail namespace to specify the return type. Until auto and decltype, and for C++03 support, a result_of namespace ala Boost.Fusion would be nice.
Good point. Can you elaborate on your needs to forward results from functions? Is it possible that the library is missing some important functions that you had to implement yourself?
Here is an example. I internally keep my vertices in arrays; in order to return them as vertex conforming types to the outside I have to do the following: boost::la::la_detail::vref_< T > get( int index ) { return boost::la::vref( ... ); } Ideally I would get ride of such `la_detail`, so I'm thinking something like: boost::la::result_of::vref< T >::type get( int index );
· Support for subscript operator may be introduced via vref/mref. So vref( any_conforming_vertex_type )[ I ] could be used for both direct indexing and swizzling (as mentioned at your blog).
Good idea. I wish this could be introduced non-intrusively though...
· Support for "complex swizzling expressions" would be nice. I've just made that name up, but I'm referring to things like 'v1[Y,-X]' or 'v1|(Y,-X)' (again, as mentioned at your blog).
Great idea. I wonder what other expressions would make sense, besides minus.
In my current project I use the library to generically work with any conforming vertex type, so I can't use the subscript operator since it would be optional. That's why I propose adding support for subscript operator via vref/mref. vref/mref would wrap the UDTs and implement the subscript operators, similar to what they currently do for arrays.
Finally, I'm not keen on the library name, but I don't have a better one to suggest.
I'm not keen on the library name either. I'm open for suggestions.
If no better name is found, I'd rather have the library named LinearAlgebra and the namespace `linear_algebra`. People can use namespace aliases to have `la` back if they want to. However, this name doesn't reflect either the statically sized nature of the elements it operates on. Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com
2010/2/8 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
boost::la::la_detail::vref_< T > get( int index ) { return boost::la::vref( ... ); }
I was actually interested in the ... part :) Why isn't it plausible for you to do: my_own_conforming_vector_type get( int index ) { ... } For example: struct vertex { float pos[3]; float normal[3]; }; float (&get_pos(int index))[3] { return verts[index].pos; }
In my current project I use the library to generically work with any conforming vertex type, so I can't use the subscript operator since it would be optional. That's why I propose adding support for subscript operator via vref/mref. vref/mref would wrap the UDTs and implement the subscript operators, similar to what they currently do for arrays.
However, all this presumes that op| doesn't work well. The only potential issue with it is the low precedence. Is that why you'd rather use op[ ]? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
El 09/02/2010 03:45 a.m., Emil Dotchevski escribió:
2010/2/8 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
boost::la::la_detail::vref_< T > get( int index ) { return boost::la::vref( ... ); }
I was actually interested in the ... part :)
It's merely an expression that returns a T(&)[N].
Why isn't it plausible for you to do:
my_own_conforming_vector_type get( int index )
I want to return a conforming vector type, and whatever vref returns fills the bill perfectly. My project is a generic OpenGL model, specialized by a sequence of attributes that describe a vertex.
In my current project I use the library to generically work with any conforming vertex type, so I can't use the subscript operator since it would be optional. That's why I propose adding support for subscript operator via vref/mref. vref/mref would wrap the UDTs and implement the subscript operators, similar to what they currently do for arrays.
However, all this presumes that op| doesn't work well. The only potential issue with it is the low precedence. Is that why you'd rather use op[ ]?
I have been bitten by the precedence issue to the point I enclose every pipe operation in parenthesis. And it gets worse if "complex swizzling expressions" are added to the library. Consider ( v1 | ( Y, -X ) ) * 2; versus v1[ Y, -X ] * 2; It *might* be possible to get ride of the precedence problems by using expression templates, but even then subscripting operator seems more natural. K-ballo.- http://talesofcpp.blogspot.com
2010/2/10 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
El 09/02/2010 03:45 a.m., Emil Dotchevski escribió:
2010/2/8 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
boost::la::la_detail::vref_< T > get( int index ) { return boost::la::vref( ... ); }
I was actually interested in the ... part :)
It's merely an expression that returns a T(&)[N].
Ah, I see. I'd just return T(&)[N] as in the code from my previous post; T(&)[N] is a conforming type already. You only need vref if all vectors/matrices in an expression are of built-in types: float v1[3] = { .... }; float v2[3] = { .... }; v1*v2; //error; you need vref(v1)*v2. but: float v1[3] = { .... }; boost::la::vec<float,3> v2=....; v1*v2; //okay
I have been bitten by the precedence issue to the point I enclose every pipe operation in parenthesis. And it gets worse if "complex swizzling expressions" are added to the library. Consider
( v1 | ( Y, -X ) ) * 2;
I don't think that such syntax is acceptable. I have to think about this but it seems to me that v1|Y-X should be possible (the currently supported syntax, for "non-complex" swizzling isn't v1|(Y,X), it is v1|YX.) Or we can throw op| out the window, I do hate it. Perhaps the best approach is to just use a function: vbind<YX>(v1) and let the user overload something if they want to.
It *might* be possible to get ride of the precedence problems by using expression templates, but even then subscripting operator seems more natural.
Operator [ ] is the best choice, but it can not be overloaded generically because it is required to be a member, for reasons that are beyond my understanding of C++. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Operator [ ] is the best choice, but it can not be overloaded generically because it is required to be a member, for reasons that are beyond my understanding of C++.
I don't see why you can't overlaod generically ? w/r to the swizzling operation, we have prototype for a : v[_2,_3,_1] = ... syntax in NT2, and currently, it doesn't seem to fail us.
Using boost 1_41 I found what I believe to be a bug in is_virtual_base_of. The following code reports that A and B are both virtual base classes of C. #include<boost/type_traits/is_virtual_base_of.hpp> #include <stdio.h> struct A { int base_old; }; struct B { int base_data; }; struct C : public A, public B { virtual void test(){}; float my_data; }; int main ( int argc, char** argv ) { printf( "is_virtual_base_of<A,C>::value: %d\n", boost::is_virtual_base_of<A,C>::value ); printf( "is_virtual_base_of<B,C>::value: %d\n", boost::is_virtual_base_of<B,C>::value ); } i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Using boost 1_41 I found what I believe to be a bug in is_virtual_base_of. The following code reports that A and B are both virtual base classes of
Works for me on Win32 with both VC9 and G++4.0, tested 1.41 and current Trunk. The only thing I notice is that you're passing a bool to printf, but telling it to expect an int - could it be reading garbage off the stack? Otherwise stumped yours, John.
cast the bool to an int, still does not work. It works for most cases, for example this works: struct C : public A, public B { virtual test(); // } struct C : public A, public B { virtual test(); float parameter; // DOESN"T WORK ANY MORE }; On Feb 11, 2010, at 4:43 AM, John Maddock wrote:
Using boost 1_41 I found what I believe to be a bug in is_virtual_base_of. The following code reports that A and B are both virtual base classes of
Works for me on Win32 with both VC9 and G++4.0, tested 1.41 and current Trunk.
The only thing I notice is that you're passing a bool to printf, but telling it to expect an int - could it be reading garbage off the stack?
Otherwise stumped yours, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
cast the bool to an int, still does not work. It works for most cases, for example this works:
struct C : public A, public B { virtual test(); // }
struct C : public A, public B { virtual test(); float parameter; // DOESN"T WORK ANY MORE };
Which specific compiler version? I need something that I can reproduce here... John.
I included the compiler version in the first post, but here it is again. I have expanded upon the bug and provided the actual output of the code. Looking at the implementation of is_virtual_base_of<>, it appears that it makes some assumptions regarding the sizeof() a class with and without virtual inheritance that are perhaps invalid? i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) #include <stdio.h> #include <boost/type_traits/is_virtual_base_of.hpp> struct A { int x; }; struct B { int y; }; struct C : public A, public B { int z; }; struct D : public A, virtual public B { int z; }; struct E : public A, public B { virtual void test(){}; int z; }; int main( int argc, char** argv ) { printf( "A,C %d\n", (int)boost::is_virtual_base_of<A,C>::value ); printf( "B,C %d\n", (int)boost::is_virtual_base_of<B,C>::value ); printf( "A,D %d\n", (int)boost::is_virtual_base_of<A,D>::value ); printf( "virtual B,D %d\n", (int)boost::is_virtual_base_of<B,D>::value ); printf( "A,E %d\n", (int)boost::is_virtual_base_of<A,E>::value ); printf( "B,E %d\n", (int)boost::is_virtual_base_of<B,E>::value ); printf( "sizeof(A) %ld\n", sizeof(A) ); printf( "sizeof(B) %ld\n", sizeof(B) ); printf( "sizeof(C) %ld\n", sizeof(C) ); printf( "sizeof(D) %ld\n", sizeof(D) ); printf( "sizeof(E) %ld\n", sizeof(E) ); return 0; } ================ A,C 0 B,C 0 A,D 1 virtual B,D 1 A,E 1 B,E 1 sizeof(A) 4 sizeof(B) 4 sizeof(C) 12 sizeof(D) 24 sizeof(E) 24 On Feb 11, 2010, at 12:59 PM, John Maddock wrote:
cast the bool to an int, still does not work. It works for most cases, for example this works:
struct C : public A, public B { virtual test(); // }
struct C : public A, public B { virtual test(); float parameter; // DOESN"T WORK ANY MORE };
Which specific compiler version? I need something that I can reproduce here... John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Here is the correct output running on Linux with gcc 4.3.2 A,C 0 B,C 0 A,D 0 virtual B,D 1 A,E 0 B,E 0 sizeof(A) 4 sizeof(B) 4 sizeof(C) 12 sizeof(D) 16 sizeof(E) 16 Perhaps some quirky difference between 32/64 bit? Or did I just find a bug in Apple's version of gcc? Dan On Feb 11, 2010, at 12:59 PM, John Maddock wrote:
cast the bool to an int, still does not work. It works for most cases, for example this works:
struct C : public A, public B { virtual test(); // }
struct C : public A, public B { virtual test(); float parameter; // DOESN"T WORK ANY MORE };
Which specific compiler version? I need something that I can reproduce here... John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think I found the root cause of the "bug", padding of the data structure for 64 bit alignment which is revealed by looking at the sizeof() different structs. struct A { int x; // 4 bytes } struct B { int y; // 4 bytes } struct C : A, B { int z; // 12 bytes } struct D : A, B { virtual ~D(){} // 8 bytes for virtual table ptr int z; // 4 bytes } sizeof(C) == 12 sizeof(D) == 24 In other words, the presence of a virtual pointer added 12 bytes instead of 8 bytes which implies the compiler is padding the data structure. If I change A::x to int64_t then everything works as expected, there is no unaccounted for "padding". Dan On Feb 11, 2010, at 12:59 PM, John Maddock wrote:
cast the bool to an int, still does not work. It works for most cases, for example this works:
struct C : public A, public B { virtual test(); // }
struct C : public A, public B { virtual test(); float parameter; // DOESN"T WORK ANY MORE };
Which specific compiler version? I need something that I can reproduce here... John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Here is my fix that attempts to account for the potential case of the compiler padding the structure size when the derived class adds members and/or virtual functions. I made the destructor of X and Y virtual and added an extra data-field that causes both X and Y to experience the same shift in padding and thus the only remaining difference is the virtual Base vs non-virtual Base. What do you think? Any potential problems / side effects? template<typename Base, typename Derived> struct is_virtual_base_of_impl<Base, Derived, mpl::true_> { struct X : Derived, virtual Base { X(); X(const X&); X& operator=(const X&); virtual ~X(); char x; }; struct Y : Derived { Y(); Y(const Y&); Y& operator=(const Y&); virtual ~Y(); char x; }; BOOST_STATIC_CONSTANT(bool, value = (sizeof(X)==sizeof(Y))); }; On Feb 11, 2010, at 12:59 PM, John Maddock wrote:
cast the bool to an int, still does not work. It works for most cases, for example this works:
struct C : public A, public B { virtual test(); // }
struct C : public A, public B { virtual test(); float parameter; // DOESN"T WORK ANY MORE };
Which specific compiler version? I need something that I can reproduce here... John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Feb 12, 2010, at 6:53 AM, John Maddock wrote:
What do you think? Any potential problems / side effects?
Unfortunately it breaks the existing tests with all the gcc versions I tried (win32 and Linux) :-(
Are we looking at the same code? Have you been able to verify the padding problem? Do your tests at least confirm that my "patch" works for the test case I outlined? My patch seems to work (for my test case) for both Mac OS X and debian linux. gcc 4.2.1 and 4.3.2 respectively. What test case is it failing? Here are the full set of tests I ran on linux with my "hacked" version of is_virtual_base #include <stdio.h> #include "is_virtual_base_of.hpp" #include <stdint.h> struct A { int x; }; struct B { int y; }; struct C : public A, public B { int z; }; struct D : public A, virtual public B { int z; }; struct E : public A, public B { virtual void test(){}; int z; }; struct F : virtual public B { virtual void test(){}; int z; }; struct G : public B, public A { virtual void test(){}; int t; }; struct H : public B, public A { int t; }; struct I : virtual public B { int t; }; struct J : public B { int t; }; int main( int argc, char** argv ) { printf( "A,C %d\n", (int)boost::is_virtual_base_of<A,C>::value ); printf( "B,C %d\n", (int)boost::is_virtual_base_of<B,C>::value ); printf( "A,D %d\n", (int)boost::is_virtual_base_of<A,D>::value ); printf( "virtual B,D %d\n", (int)boost::is_virtual_base_of<B,D>::value ); printf( "A,E %d\n", (int)boost::is_virtual_base_of<A,E>::value ); printf( "B,E %d\n", (int)boost::is_virtual_base_of<B,E>::value ); printf( "virtual B,F %d\n", (int)boost::is_virtual_base_of<B,F>::value ); printf( "B,G %d\n", (int)boost::is_virtual_base_of<B,G>::value ); printf( "A,G %d\n", (int)boost::is_virtual_base_of<A,G>::value ); printf( "virtual B,I %d\n", (int)boost::is_virtual_base_of<B,I>::value ); printf( "B,J %d\n", (int)boost::is_virtual_base_of<B,J>::value ); } ========================================== A,C 0 B,C 0 A,D 0 virtual B,D 1 A,E 0 B,E 0 virtual B,F 1 B,G 0 A,G 0 virtual B,I 1 B,J 0
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
----- Original Message ----- From: "Daniel Larimer" <dlarimer@gmail.com> To: <boost@lists.boost.org> Sent: Friday, February 12, 2010 2:06 PM Subject: Re: [boost] bug in type_traits/is_virtual_base_of ??
On Feb 12, 2010, at 6:53 AM, John Maddock wrote:
What do you think? Any potential problems / side effects?
Unfortunately it breaks the existing tests with all the gcc versions I tried (win32 and Linux) :-(
Are we looking at the same code? Have you been able to verify the padding problem?
No I can't reproduce here, it seems to be somthing peculiar to 64-bit Mac systems I'm guessing.
Do your tests at least confirm that my "patch" works for the test case I outlined? My patch seems to work (for my test case) for both Mac OS X and debian linux. gcc 4.2.1 and 4.3.2 respectively.
What test case is it failing?
libs/type_traits/test/is_virtual_base_of_test.cpp Cheers, John.
On Wed, Feb 10, 2010 at 9:52 PM, <Joel.Falcou@lri.fr> wrote:
Operator [ ] is the best choice, but it can not be overloaded generically because it is required to be a member, for reasons that are beyond my understanding of C++.
I don't see why you can't overlaod generically ?
Because operator [ ] is required to be a member function. By overloading generically, I mean the way other operators are overloaded in (Boost) LA: they're namespace-scope functions that kick-in for any conforming user-defined vector or matrix type. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
By overloading generically, I mean the way other operators are overloaded in (Boost) LA: they're namespace-scope functions that kick-in for any conforming user-defined vector or matrix type.
Oh yeah OK i see it now. What about: at(v, (_2,_1,-_3)) = xxx ; ?
On Wed, Feb 10, 2010 at 11:20 PM, Joel Falcou <joel.falcou@lri.fr> wrote:
Emil Dotchevski wrote:
By overloading generically, I mean the way other operators are overloaded in (Boost) LA: they're namespace-scope functions that kick-in for any conforming user-defined vector or matrix type.
Oh yeah OK i see it now. What about:
at(v, (_2,_1,-_3)) = xxx ; ?
Perhaps at<2,1,-3>(v) = xxx This is a possibility, yes. I think it is better if this is a function by default, instead of operator overload. With the function, the operator overload is trivial to implement by the user. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
[sorry for dropping in the conversation, but I love these games of play-with-syntax] On Thu, Feb 11, 2010 at 5:12 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Wed, Feb 10, 2010 at 11:20 PM, Joel Falcou <joel.falcou@lri.fr> wrote:
Emil Dotchevski wrote:
By overloading generically, I mean the way other operators are overloaded in (Boost) LA: they're namespace-scope functions that kick-in for any conforming user-defined vector or matrix type.
Oh yeah OK i see it now. What about:
at(v, (_2,_1,-_3)) = xxx ; ?
Perhaps at<2,1,-3>(v) = xxx
That would lose the convenience of ADL (AFAIK ADL does not work when you explicitly specify the template parameters). Also you would have to use a different syntax if you were to add the possiblity to specify the swizling at runtime. This could be made to work: (_2,_1,-_3)[v] = xxx; but it is counterintuitive, altough in a perverse way it is consistent with the rest of the language (think "string"[n] and n["string"]). A more realisistic and simpler syntax would be: at(v)[_2,_1,-_3] = xxx; at() could be implemented as the identity funciton by default so that operator[] can be easily implemented as a member of v. To adapt existing vectors or matrices one would just overload at() for v and return a proxy. Just my 0.02€ -- gpd
On Tue, Feb 16, 2010 at 6:10 AM, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
[sorry for dropping in the conversation, but I love these games of play-with-syntax]
On Thu, Feb 11, 2010 at 5:12 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Wed, Feb 10, 2010 at 11:20 PM, Joel Falcou <joel.falcou@lri.fr> wrote:
Emil Dotchevski wrote:
By overloading generically, I mean the way other operators are overloaded in (Boost) LA: they're namespace-scope functions that kick-in for any conforming user-defined vector or matrix type.
Oh yeah OK i see it now. What about:
at(v, (_2,_1,-_3)) = xxx ; ?
Perhaps at<2,1,-3>(v) = xxx
That would lose the convenience of ADL
Not a problem, since the convenience of ADL is lost already. :) The operator overloads require the user to use "using" anyway; like those overloads, at<> would use SFINAE so it won't clash with anything the user may have defined. I'm pretty sure I've never used "use" so many times in a single sentence :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
if there is no name for your lib yet here is a suggestion: Generic Linear Algebra for Static Structures or simply GLASS if you adopt it you can put in the docs words such as: "the usage of this library is as transparent as glass" -- Pavel
DE wrote:
if there is no name for your lib yet here is a suggestion:
Generic Linear Algebra for Static Structures
My main cocnern is that currently, the Algebra side is not that prevalent nor really the main focus of the library. static_container is maybe more suited. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
On Tue, Feb 16, 2010 at 9:03 AM, joel falcou <joel.falcou@lri.fr> wrote:
DE wrote:
if there is no name for your lib yet here is a suggestion:
Generic Linear Algebra for Static Structures
My main cocnern is that currently, the Algebra side is not that prevalent nor really the main focus of the library.
The library provides generic vector and matrix operations and generic access to vector and matrix types. This is all within the Algebra domain and the library doesn't do anything else so I'm not sure what you mean by "not prevalent". It is true however that the Algebra domain is rather large. I am in favor of coming up with a name that properly narrows down the purpose of this library.
static_container is maybe more suited.
Nothing in this library is a container. It is a collection of generic operations on vector and matrix types of static size. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
The library provides generic vector and matrix operations and generic access to vector and matrix types. This is all within the Algebra domain and the library doesn't do anything else so I'm not sure what you mean by "not prevalent".
When people hear algebra, they await tons of algebra related algorithm more than algebra related entities.
It is true however that the Algebra domain is rather large. I am in favor of coming up with a name that properly narrows down the purpose of this library. Why not stick Numeric or Computation instead of Algebra ? Nothing in this library is a container. It is a collection of generic operations on vector and matrix types of static size.
static_matrix then ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
On Tue, Feb 16, 2010 at 10:12 AM, joel falcou <joel.falcou@lri.fr> wrote:
Emil Dotchevski wrote: Why not stick Numeric or Computation instead of Algebra ?
Nothing in this library is a container. It is a collection of generic operations on vector and matrix types of static size.
static_matrix then ?
It also does vectors though. :) It should (will) also do quaternions. Maybe something with "graphics" and "math" in the name makes more sense. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
It also does vectors though. :)
It should (will) also do quaternions.
Maybe something with "graphics" and "math" in the name makes more sense.
and maybe adaptor somewhere ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
On Tue, Feb 16, 2010 at 11:59 AM, joel falcou <joel.falcou@lri.fr> wrote:
Emil Dotchevski wrote:
It also does vectors though. :) It should (will) also do quaternions. Maybe something with "graphics" and "math" in the name makes more sense. and maybe adaptor somewhere ?
I think the word "generic" fits that aspect of the library better than adaptor does. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Feb 16, 2010 at 11:59 AM, joel falcou <joel.falcou@lri.fr> wrote:
Emil Dotchevski wrote:
It also does vectors though. :) It should (will) also do quaternions. Maybe something with "graphics" and "math" in the name makes more sense. and maybe adaptor somewhere ?
I think the word "generic" fits that aspect of the library better than adaptor does.
How about GVMM (Generic Vector and Matrix Math), which could be pronounced like gum. regards and great work Fabio
Fabio Fracassi wrote:
Emil Dotchevski wrote:
On Tue, Feb 16, 2010 at 11:59 AM, joel falcou <joel.falcou@lri.fr> wrote:
Emil Dotchevski wrote:
It also does vectors though. :) It should (will) also do quaternions. Maybe something with "graphics" and "math" in the name makes more sense. and maybe adaptor somewhere ?
I think the word "generic" fits that aspect of the library better than adaptor does.
How about GVMM (Generic Vector and Matrix Math), which could be pronounced like gum.
It started to seem to me that the word Generic used for Boost libraries has become redundant. Genericity of a library is a very important aspect being verified during reviews, so perhaps it's correct to assume all libraries accepted to Boost are generic (or at least as generic as feasible to achieve for particular problem/domain). Best regards, -- Mateusz Loskot http://mateusz.loskot.net
On Thu, Feb 18, 2010 at 11:56 AM, Mateusz Loskot <mateusz@loskot.net> wrote:
Fabio Fracassi wrote:
Emil Dotchevski wrote:
On Tue, Feb 16, 2010 at 11:59 AM, joel falcou <joel.falcou@lri.fr> wrote:
Emil Dotchevski wrote:
It also does vectors though. :) It should (will) also do quaternions. Maybe something with "graphics" and "math" in the name makes more sense. and maybe adaptor somewhere ?
I think the word "generic" fits that aspect of the library better than adaptor does.
How about GVMM (Generic Vector and Matrix Math), which could be pronounced like gum.
It started to seem to me that the word Generic used for Boost libraries has become redundant. Genericity of a library is a very important aspect being verified during reviews, so perhaps it's correct to assume all libraries accepted to Boost are generic
From that point of view (Boost) LA is generic and I think that it is rather descriptive and appropriate to use that word in the name of the
Not all Boost libraries are generic, or at least not all of them are examples of generic programming: http://en.wikipedia.org/wiki/Generic_programming. library. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
Mateusz Loskot wrote:
Fabio Fracassi wrote:
Emil Dotchevski wrote:
joel falcou wrote:
Emil Dotchevski wrote:
It also does vectors though. :) It should (will) also do quaternions. Maybe something with "graphics" and "math" in the name makes more sense.
and maybe adaptor somewhere ?
I think the word "generic" fits that aspect of the library better than adaptor does.
How about GVMM (Generic Vector and Matrix Math), which could be pronounced like gum.
It started to seem to me that the word Generic used for Boost libraries has become redundant. Genericity of a library is a very important aspect being verified during reviews, so perhaps it's correct to assume all libraries accepted to Boost are generic
Not all Boost libraries are generic, or at least not all of them are examples of generic programming: http://en.wikipedia.org/wiki/Generic_programming.
From that point of view (Boost) LA is generic and I think that it is rather descriptive and appropriate to use that word in the name of the library.
Point taken, thanks. Best regards, -- Mateusz Loskot http://mateusz.loskot.net
Hi Emil, Emil Dotchevski wrote:
Documentation and source code complete with comprehensive tests, released under the Boost Software License is available here:
Thanks for announcing this library! I played with it, a few weeks after your first announcement and I think it is a very valuable addition to the Boost library collection. We currently use Boost.uBlas for matrix calculations in Boost.Geometry. But because this new LA library contains staticly sized matrices and vectors, it fits much better to the staticly dimensioned geometries of Boost.Geometry, and we will probably change the implementation to use this library. Then using the vectors (e.g. the dot-product is welcome) as well. It would then conveniently complement Boost.Geometry. So I'm looking forward to the review. Regards, Barend
Emil Dotchevski wrote:
Documentation and source code complete with comprehensive tests, released under the Boost Software License is available here:
http://www.revergestudios.com/boost-la/
Thanks, Emil Dotchevski
Emil, would you be opposed to adding this to the boost svn sandbox? Or is it there already? - Jeff
On Thu, Feb 4, 2010 at 7:32 PM, Jeffrey Hellrung <jhellrung@ucla.edu> wrote:
Emil Dotchevski wrote:
Documentation and source code complete with comprehensive tests, released under the Boost Software License is available here:
http://www.revergestudios.com/boost-la/
Thanks, Emil Dotchevski
Emil, would you be opposed to adding this to the boost svn sandbox? Or is it there already?
It isn't there but the source code and documentation can be downloaded here: http://www.revergestudios.com/boost-la/boost-la.zip Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Thu, Feb 4, 2010 at 7:32 PM, Jeffrey Hellrung <jhellrung@ucla.edu> wrote:
Emil, would you be opposed to adding this to the boost svn sandbox? Or is it there already?
It isn't there but the source code and documentation can be downloaded here:
http://www.revergestudios.com/boost-la/boost-la.zip
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
I only request this in order to make it easier to distribute code among my group with this library; I think we can make use of it. We already all have the boost svn sandbox checked out (to occasionally play around with other proposed libraries), so if this were already in the sandbox, it'd be one less (albeit small) hurdle to jump over. If you don't already have SVN access, don't worry about it. It's not a big deal. - Jeff
On Thu, Feb 4, 2010 at 9:09 PM, Jeffrey Hellrung <jhellrung@ucla.edu> wrote:
I only request this in order to make it easier to distribute code among my group with this library; I think we can make use of it. We already all have the boost svn sandbox checked out (to occasionally play around with other proposed libraries), so if this were already in the sandbox, it'd be one less (albeit small) hurdle to jump over.
I committed it to the sandbox, enjoy: http://svn.boost.org/svn/boost/sandbox/la Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
looking at traits class specialization i have a question: is there a reason defining integral constants as following? static cont int dim = 42; i mean if you do not take address of that member a better solution (imho) is to define an anonymous enum like enum { dim = 42 }; or in one line enum { dim = 42 }; rather than defining a global object -- Pavel
DE wrote:
looking at traits class specialization i have a question: is there a reason defining integral constants as following?
static cont int dim = 42;
i mean if you do not take address of that member a better solution (imho) is to define an anonymous enum like
enum { dim = 42 };
or in one line
enum { dim = 42 };
rather than defining a global object
An optimizing compiler will perform constant propagation, substituting the value of the variable (in this case, 42) everywhere it is used. If the address of the variable is never taken, the compiler need not actually have a memory location to hold it. --Jeffrey Bosboom
Jeffrey Bosboom wrote:
DE wrote:
looking at traits class specialization i have a question: is there a reason defining integral constants as following?
static cont int dim = 42;
i mean if you do not take address of that member a better solution (imho) is to define an anonymous enum like
enum { dim = 42 };
or in one line
enum { dim = 42 };
rather than defining a global object
An optimizing compiler will perform constant propagation, substituting the value of the variable (in this case, 42) everywhere it is used. If the address of the variable is never taken, the compiler need not actually have a memory location to hold it.
I've had bad experience with optimizing compilers failing to perform constant propagation for static const int the way I expected and prefer enum to avoid such problems. I avoid all static declarations when possible. Regards, Luke
Simonson, Lucanus J wrote:
Jeffrey Bosboom wrote:
DE wrote:
looking at traits class specialization i have a question: is there a reason defining integral constants as following?
static cont int dim = 42;
i mean if you do not take address of that member a better solution (imho) is to define an anonymous enum like
enum { dim = 42 };
or in one line
enum { dim = 42 };
rather than defining a global object
An optimizing compiler will perform constant propagation, substituting the value of the variable (in this case, 42) everywhere it is used. If the address of the variable is never taken, the compiler need not actually have a memory location to hold it.
I've had bad experience with optimizing compilers failing to perform constant propagation for static const int the way I expected and prefer enum to avoid such problems. I avoid all static declarations when possible.
Regards, Luke
FWIW, I've never had a problem with "static const int" (MSVC8 and 9, GCC 4.3 and 4.4), but if you're worried, there is a boost macro for this: http://www.boost.org/libs/config/doc/html/boost_config/boost_macro_reference... - Jeff
on 05.02.2010 at 21:29 Jeffrey Hellrung wrote :
Simonson, Lucanus J wrote:
I've had bad experience with optimizing compilers failing to perform constant propagation for static const int the way I expected and prefer enum to avoid such problems. I avoid all static declarations when possible.
Regards, Luke
FWIW, I've never had a problem with "static const int" (MSVC8 and 9, GCC 4.3 and 4.4), but if you're worried, there is a boost macro for this:
http://www.boost.org/libs/config/doc/html/boost_config/boost_macro_reference...
why to use macro while there is enum?? -- Pavel
DE wrote:
why to use macro while there is enum??
Because soem compiler don't handle enum properly when covnertign to integral type. Reading the page is actually a good idea. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
On Fri, Feb 5, 2010 at 11:20 AM, joel falcou <joel.falcou@lri.fr> wrote:
DE wrote:
why to use macro while there is enum??
Because soem compiler don't handle enum properly when covnertign to integral type. Reading the page is actually a good idea.
Why not use enum? Because I'm not enumerating anything. Why not use the Boost macro? To avoid unnecessary dependency. Isn't this going to cause issues on some ancient compilers? Yes. Are these compilers able to handle the rest of the Boost LA code? No. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Hi Emil, I have added your library to the review queue. Ron On Feb 2, 2010, at 2:48 PM, Emil Dotchevski wrote:
Documentation and source code complete with comprehensive tests, released under the Boost Software License is available here:
http://www.revergestudios.com/boost-la/
Thanks, Emil Dotchevski _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (18)
-
Agustín K-ballo Bergé -
Barend Gehrels -
Daniel Larimer -
DE -
Emil Dotchevski -
Emil Dotchevski -
Fabio Fracassi -
Giovanni Piero Deretta -
Jeffrey Bosboom -
Jeffrey Hellrung -
joel falcou -
Joel Falcou
-
Joel.Falcou＠lri.fr
-
John Maddock -
Mateusz Loskot -
Ronald Garcia -
Simonson, Lucanus J -
Thomas Klimpel