Page **3** of **7**

### Choice of matrix library and interface

Posted: **November 13th, 2011, 10:26 pm**

by **Polter**

QuoteOriginally posted by: Cuchulainn Will there be support for compile time/tiny vectors+matrices on the lines of?Cuch, have you tried fixed containers from EASTL?

http://www.open-std.org/jtc1/sc22/wg21/ ... QuoteFixed containers are fixed-size containers with their memory stored right within the container itself. Fixed containers allocate no dynamic memory and their memory tends to be cache-friendly due to its contiguity and proximity to the container's housekeeping data. The user declares the max container size as a template parameter, and can also specify that if the container overflows that an auxiliary dynamic allocator is used. The overflow allocation feature is best used for pathological cases or during development when the container's fixed size is being tuned. All fixed containers have high-water mark tracking to assist in size tuning.fixed_listfixed_slistfixed_vectorfixed_stringfixed_setfixed_multisetfixed_mapfixed_multimapfixed_hash_setfixed_hash_multisetfixed_hash_mapfixed_hash_multimapAn example of fixed_vector -- the policy of being fixed-size in memory is implemented via an allocator template argument specialization of std::vector, quite nice separation of concerns:

http://github.com/paulhodge/EASTL/blob/ ... cator.html

### Choice of matrix library and interface

Posted: **November 14th, 2011, 2:12 pm**

by **Cuchulainn**

EASTL seems very extensive; a simple matrix<V, int R, int C> along the lines of boost::array<V,N>.What is also needed (I have one using NumericMatrix and STL) is associative matrixThey are very useful, e.g. lookup tables on 2 parameters for NonCentral ChiSquared Distribution. Thijs,Are the index sets all of integral type?

### Choice of matrix library and interface

Posted: **November 14th, 2011, 3:02 pm**

by **Cuchulainn**

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnEASTL seems very extensive; a simple matrix<V, int R, int C> along the lines of boost::array<V,N>.What is also needed (I have one using NumericMatrix and STL) is associative matrixThey are very useful, e.g. lookup tables on 2 parameters for NonCentral ChiSquared Distribution. Thijs,Are the index sets all of integral type?I think we have different concepts and specialized containers to keep performace high, ..so we might have different interfaces for matrices and grids (integral types) and lookup tables (floats, sorted). Right?I think the requirement is Functionality here, since the lookup tables are not so big.

### Choice of matrix library and interface

Posted: **November 14th, 2011, 3:33 pm**

by **Cuchulainn**

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnEASTL seems very extensive; a simple matrix<V, int R, int C> along the lines of boost::array<V,N>.What is also needed (I have one using NumericMatrix and STL) is associative matrixThey are very useful, e.g. lookup tables on 2 parameters for NonCentral ChiSquared Distribution. Thijs,Are the index sets all of integral type?I think we have different concepts and specialized containers to keep performace high, ..so we might have different interfaces for matrices and grids (integral types) and lookup tables (floats, sorted). Right?I think the requirement is Functionality here, since the lookup tables are not so big.I can think if 3 ways to do lookups:* std::map* boost::multi_index* a static sorted list, and a std:binary)searchThe first one is very standard, the second one flexible and fancy, and the third standard and fast.Maybe leave this open until we actually run into it? Picking any if the three methods above (and others) doesn't even need to be discussed I would say: * we can use whatever we want from STL and maybe boost behind our interfaces.The requirement is an associative matrix, as in the link. On the lines of

### Choice of matrix library and interface

Posted: **November 14th, 2011, 9:05 pm**

by **Cuchulainn**

QuoteOriginally posted by: outrunTo be honest I dont like these features. Maybe that would be convenient but at the same time more interfaces to learn, and essential and expected? I'm worried about bloath vs simplicity. But I'm nit going to vote against it.What are the other ways to create associative matrices? I am open to better solutions. But the matrix structure should be evident. The closest analogy is accessing Excel cells.

### Choice of matrix library and interface

Posted: **November 21st, 2011, 2:43 pm**

by **Cuchulainn**

QuoteDoes uBlas use map instead of unordered_map for sparse matrices? It's an undocumented feature But I suspect map. One could use hash map but what's the point.I have tried the CGM (you can even try it yourself) on a) sparse b) dense matrices containing the same data . a) is soooo mucho slower So, if you have enough memory, just use a dense matrix (or clever sparse matrix). Fortran has been doing sparse matrices for 40 years. Maybe google.

### Choice of matrix library and interface

Posted: **November 21st, 2011, 4:33 pm**

by **Cuchulainn**

QuoteOriginally posted by: outrunThat's thr exact point, if they use the top line (map, I suspect they do: they call their default "map_std") instead of the bottom line (unordered map) then that is 100 times slower! My hunch is that sparse should only be 5x slower than dense with hash-keys, mauve even on par due to the much higher cache hit on the smaller memory footprint.100 times slower more or less is what I see as well. I reckon hash will also be slow.Fortran way