On Wed, 23 May 2007, Stjepan Rajko wrote:

Cool - I'd be interested. It seems like it would be a decent foundation for simple low-dimensional point / vector classes, perhaps? I'll check out what you have in the sandbox.

This is what we primarily use it for here: vector operations as well as the base for quaternions. It also does well for homogeneous coordinate matrices. The design use-case is most general vector math ops of known, fixed size. Future possiblities also include support for SIMD etc a la macstl. Mike

I tried using the .h file as-is in msvc 8.0 but got a bunch of compile errors on the test code provided in your e-mail. Maybe it doesn't make sense to do that, sorry I'm not too familiar with configure/make. I downsized the test code to where it did something pretty simple (declared a cvalarray using the default consructor and printed its values). Anything beyond that and errors come up.

OK, I did some checking and I believe the compile errors on MSVC is a language non-conformance bug in MSVC. Specifically, VC++ reports an ambiguity error for the following code: #include <iostream> template<typename T, int N> struct foo { foo(const T *t) {std::cerr << "const T *t called\n";} foo(const T (&t)[N]) {std::cerr << "const T (&t)[N] called\n";} }; int main() { int a[10]; foo<int,10> f(a); return 0; } GCC, SUNForte, and others compile this fine. MSVC seems to erroneously decay the array argument in f's constructor even though one of the options is a constant array parameter. Vandevoorde(C++ Templates, pg 59) discusses this further. In any case, the decision to stray from std::valarray's interface in this area was an arbitrary one so it is easy to chose the other option. The interface now mimics std::valarray for single value as well as pointer arguments in that they require a size parameter. The test cases and docs have been updated and the new version (cvalarray-.1.3.tar.gz) is now in the vault. I have also included MSVS project files located in the 'tests' directory that will run all 24 tests. I do not use MSVS much so I don't promise that it is elegant. Mike

Hi Michael, OK I got to play with the library finally :-) It seems pretty complete, nice work! I derived a little class based on your cvalarray called cvalarray_constructible which offers the constructors I was suggesting (for N<=UNROLL_LIMIT). Source attached, if you're interested (it uses your original cvalarray.h except it wants v to be protected instead of private). I'm not sure whether in its current state it works interchangeably with cvalarray objects, though. One other comment - instead of storing the array as a member T v[N], maybe you can consider inheriting boost::array<T, N>. This would give you iteration support and a few other things, assuming it wouldn't cause any problems. Regards, Stjepan On 5/30/07, Stjepan Rajko <stipe@asu.edu> wrote:

On 5/30/07, Michael Tegtmeyer <tegtmeye@eecis.udel.edu> wrote:

...

In any case, the decision to stray from std::valarray's interface in this area was an arbitrary one so it is easy to chose the other option. The interface now mimics std::valarray for single value as well as pointer arguments in that they require a size parameter.

The test cases and docs have been updated and the new version (cvalarray-.1.3.tar.gz) is now in the vault.

I have also included MSVS project files located in the 'tests' directory that will run all 24 tests. I do not use MSVS much so I don't promise that it is elegant.

Thanks very much for doing this! I will try to take a look at the new version tomorrow.

Stjepan

On 6/4/07, Michael Tegtmeyer <tegtmeye@eecis.udel.edu> wrote:

Stjepan, As for the storage part, inheriting from boost::array is probably not a good thing. One of the principal reasons that std::valarray does not support iterators is that pointers to the actual storage of the array (or types that pretend that they are) violate the strict aliasing rules that the standard requires for the class. Since cvalarray is intended to mimic the purpose and semantics of std::valarray with the exception of being statically sized, I'm not sure introducing an aliasing violation is worth the convenience.

I see. Sorry, I'm ignorant of such issues, I had to look up what strict aliasing rules are :-) I'm not sure whether the following might be a compromise: namespace n_std { namespace no_alias { ... current cvalarray } namespace alias { ... cvalarray that inherits array } using namespace alias; } Or, there could be two classes, one called cvalarray and the other called value_array. I'll try tweaking your code to allow for the former option just because it will be easy to throw together from your code (although I think the latter option seems cleaner and still explains what's going on). Regards, Stjepan

Stjepan, I appreciate you taking the time to have a look at the code.

I would really like to see this library in boost, would you like any help getting it ready for submission? I have recently learned how to use bjam, do boost-style docs etc, and have time to lend a hand. If we wanted to work together on preparing this, it would be good to put the code in the boost sandbox so we can both access it via subversion.

Thanks, I am interested in whatever help you could offer. I have little experience in bjam nor the boost document style.

use the boost general license Not a big deal, see COPYING file.

code readability and maintainability - there is a lot of code repetition in the .h file, also it could use to be chunked up into smaller files (it is really hard to look at a ~5000 line header file). Did you use a code generation script to make that file? It could benefit from using macros for all the similar functions, which can be readily made from the code generation script if you used one.

I didn't use a code generator but most is copy-paste, At one point I had macros to generate each individual case but debugging (use code, not library code) became a pain. ie it was easier to track down a compiler error when it said "no operator in expression<lots and lots of stuff> on line 42 which said __positive::T operator[](std::size_t n) const {return +(value[n]);} rather than MAKE_EXPRESSION_TIMES(...) which was a top-level macro and the real problem was missing operator + nested 8 layers. (real problem we had). So since the library has been stable for a few years, we got rid of the macros to aid debugging it's use. I think that I have a better understanding of what you are looking for but let me get the following out of the way: I'm not sure that a general purpose container is the best use for this class. cvalarray is meant to mimic the semantics and purpose of std::valarray. Which is specifically designed for numeric values. I think that if the purpose is general, then so should the interface, ie not mimic std::valarray. One could claim that the incorrect use of boost::array and by implication a general-purpose cvalarray is not our problem but IMHO, libraries should be easy to use correctly and hard to use incorrectly. Arguably, concepts solves some of these problems but in this case, I believe the better behavior is limiting the scope to numeric operations as does the well documented std::valarray-especially since the interface is identical. Additionally, the next step for cvalarray here is for it to automatically use SIMD instructions to further speed up the numeric operations. Again making its use general purpose will unnecessarily complicate things. On a side and somewhat historical note, if cvalarray morphs into anything else, one of the issues here for the adoption is the adding dependancies. Currently, the libraries is one file, self-contained, and does not rely on anything outside of the language. That is very important in many peoples view. As it is now, one can drop the file into their own project and it is available everywhere there is a standard compliant compiler. Boost, unfortunately is still not everywhere so unless adding dependancies adds significant functionality, I'd like to avoid them. I also thought about submitting cvalarray to the c++ standard at one time. For it to ever be adopted there, it cannot have dependancies outside of the language. All of that said, I believe that your general-purpose need/desires are legitimate. Therefore, I think that it is worth working for a general-purpose solution. I have may ideas towards this end but one of the biggest ones is the use of expressions. Currently, both std::valarray and cvalarray use expressions solely as an implementation detail allowed to under the standard: 26.3.1 Header<valarray> synopsis: 3 Any function returning avalarray<T>is permitted to return an object of another type, provided all the const member functions ofvalarray<T>are also applicable to this type. This return type shall not add more than two levels of template nesting over the most deeply nested argument type.254) 4 Implementations introducing such replacement types shall provide additional functions and operators as follows: for every function taking aconst valarray<T>&, identical functions taking the replacement types shall be added; for every function taking twoconst valarray<T>&arguments, identical functions taking every combination of const valarray<T>& and replacement types shall be added. 5 In particular, an implementation shall allow avalarray<T>to be constructed from such replacement types and shall allow assignments and computed assignments of such types to valarray<T>, slice_array<T>, gslice_array<T>, mask_array<T> and indirect_array<T> objects. However this is considered an implementation detail and whatever internal type is not officially exposed. I'd like to work toward an exposed expression type for general purpose use in a new general purpose container: For example in the case of std::valarray std::valarray<float> f1, f2, f3; // assume filled with 3 interesting numbers f1 = f2 + f3; // all ok f1[i] = f2[i] + f3[i] for all n template<typename T> std::valarray<T> cross_product(const std::valarray<T> &lhs, const std::valarray<T> &rhs) { std::valarray<T> temp; // do cross product return temp; } // unnecessary temporary f1 = cross_product(f2,f3); Notice that the above creates an unnecessary temporary that could easily be solved with an expression type. But since the expression type is not formally exposed, there is no way to write portable code to take advantage of it. I think in a new, general-purpose container with a general-purpose interface, we could have an exposed expression type that uses a boost concept that ensures that as long as (for example) the contained type has a valid [] operator, any additional functionality can take advantage of it. ie template<typename T> class expression_container ... { public: typedef ??? expression_type; }; then expression_container<std::string> foo("Hello1","Hello2","Hello3"); expression_container<std::string> foo("World1","World2","World3"); Then: template<typename T> expression_container<T> join(expression_container<T> &lhs, expression_container<T> &rhs) { expression_container<T> temp(lhs); for(std::size_t i=0; i<lhs.size(); ++i) temp[i] += rhs[i]; return temp; } And template<typename T> expression_container<T>::expression_type join(const expression_container<T>::expression_type &lhs, expression_container<T>::expression_type &rhs) { return expression_container<T>::expression_type(lhs,rhs,op_plus) } expression_container<std::string> f1, f2, f3; template<typename T> void foo(expression_container<T> &val) {...} f1 = join(f2,f3); // no temporary foo(join(f2,f3)); //makes temporary because it must Thoughts? Mike

All, An updated version of cvalarray has been posted to the vault. Although the original purpose was to mimic std::valarray as much as possible, features that address the criticism of std::valarray in issue 93 (and others) of the c++ working groups have been added. Since there are few specifics in this area, it would be nice to hear the community weigh in on some of the design decisions. In no particular order: - non-member operations on cslice_array and cindirect_array are now defined: ie res[cslice<0,4,3>()] = (foo[cslice<1,4,3>()] * bar[cslice<2,4,3>()]); expression templates are used to eliminate temporaries and operations are unrolled for small N - operator[] is defined for both cslice_array and cindirect_array. Not so sure about this one. I can see a valid use case (computed indirect indices) but if the purpose of std::slice_array and std::indirect_array is to be transparent to the user, this is directly a violation of that. I can go either way if folks don't like it. - member computed assignment for cslice_array and cindirect array are added for all: ie T foo[N] = {...}; cvalarray<T,2*N> bar; bar[cslice<1,N,2>()] += foo; In addition it is now possible to have a computed assignment of another cslice_array or cindirect_array: ie foo[cslice<1,2,3>()] += bar[cslice<3,2,1>()]; or cvalarry<size_t,2> indirect; foo[cslice<1,2,3>()] += bar[indirect]; expression templates are used to eliminate temporaries and operations are unrolled for small N - transcendental operations are now defined for cslice_array and cindirect_array: ie cvalarray<float,10> foo = cos(bar[cslice<2,10,3>()]); does not result in an unnecessary temporary creation. The documentation and test cases have been updated for the above changes. Mike

On Fri, 06 Jul 2007 18:52:32 +0200, Marco wrote:

Hi, I was looking at the unified look and feel project test pages, and I noticed that the code blocks page isn't displayed correctly: watch the attached image ! I've this problem only using opera, no isuue occurs with konqueror and firefox 2 (all under linux). This is odd because I remind that the first time Matias Capeletto made up the pages I browsed them and they look fine with opera too.

.. ehm, this time I really attached the image, sorry ! Regards, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Fri, 06 Jul 2007 20:24:40 +0200, Matias Capeletto <matias.capeletto@gmail.com> wrote:

On 7/6/07, Marco <mrcekets@gmail.com> wrote:

...

Hi, I was looking at the unified look and feel project test pages, and I noticed that the code blocks page isn't displayed correctly: watch the attached image ! I've this problem only using opera, no isuue occurs with konqueror and firefox 2 (all under linux). This is odd because I remind that the first time Matias Capeletto made up the pages I browsed them and they look fine with opera too.

It works for me, Opera on Linux Are you sure you are looking at the right place: http://beta.boost.org/development/doc/doc_test/doc/html/document_to_test_for...

Version information ----------------------------------- Version = 9.21 Build = 641 Platform = Linux System = i686, 2.6.20-16-generic Qt library = 3.3.7 Java = Java Runtime Environment installed Browser identification = Opera/9.21 (X11; Linux i686; U; en)

No, the page I was looking at is: http://www.drivehq.com/file/df.aspx/publish/matias.capeletto/wwwhome/doc_tes... I started from: http://svn.boost.org/trac/boost/wiki/UnifiedLookAndFeelProject and then I followed the "new style here" link. Sorry for the noise if this isn't the latest version. The page whose link you posted here looks fine as far as the layout but the syntax highlight switches (KD EM CW, ... ) doesn't appear anymore. Again, that happens only using Opera. I tried all four code block corners (clicking or not). On the page which is showed me with a wrong layout the highlight switches work correctly. Opera information: ----------------- Version: 9.21 Build: 641 Platform: Linux System: i686, 2.6.17-5mdv Qt library: 3.3.6 Java: Java Runtime Environment installed Browser identification: Opera/9.21 (X11; Linux i686; U; en) Kind Regards, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Fri, 06 Jul 2007 22:59:53 +0200, Matias Capeletto <matias.capeletto@gmail.com> wrote:

...

...

On 7/6/07, Marco <mrcekets@gmail.com> wrote:

...

No, the page I was looking at is: http://www.drivehq.com/file/df.aspx/publish/matias.capeletto/wwwhome/doc_tes... I started from: http://svn.boost.org/trac/boost/wiki/UnifiedLookAndFeelProject and then I followed the "new style here" link. Sorry for the noise if this isn't the latest version.

Thanks for spotting this link error. I will fix it.

...

The page whose link you posted here looks fine as far as the layout but the syntax highlight switches (KD EM CW, ... ) doesn't appear anymore. Again, that happens only using Opera. I tried all four code block corners (clicking or not). On the page which is showed me with a wrong layout the highlight switches work correctly.

Opera does not support this feature for the moment. We will let users change the IDE from a more comfortable and easy to find place in the future.

It will be great if you can talk with Stuart ( stuart dot dootson at gmail dot com ) to become an active tester. It is very little work and we can really use your help.

Thanks for the feedback!

Best regards Matias

It's a pleasure, let me know when there is some pages to test. :-) Kind regards, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/