Serving the Quantitative Finance Community

  • 1
  • 5
  • 6
  • 7
  • 8
  • 9
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

container bindings

November 20th, 2011, 10:38 am

QuoteOriginally posted by: outrunInteresting!They distinguish bestween upper triangular and lower triangular stored symmetric. I would assume we could use m1,m2,m3,m4 in both loops.Good idea to analyze uBlas.The following init also give same results; makes user's life easier. BTW I have emailed you 2 chapters on uBLAS.
Last edited by Cuchulainn on November 19th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

container bindings

November 20th, 2011, 7:18 pm

QuoteOriginally posted by: outrunQuoteOriginally posted by: PolterBTW -- I think that as far as the names of iterators (not indices) functions are concerned, it's better to stick to "begin/end" convention (incl. free functions) and rely on the idiomatic asymmetric [begin, end) convention, too.yes, it's not 'better' but essential!Btw how would you decompose a problem (into e.g free functions) of filling a matrix in two ways: either rows first of columns first? Would you use a hierarchical concept, a matrix is a set of rows/columns? Sometimes I think that is all wrong: it should be a 2d iterator that can move in the 2d plane (up,down,left,right,diagonal, cr/lf, top-left, end-of-row) and for which ++, --, begin, end have no meaning because those are 1d dimensional concepts. Using this 2d iterator concept would make matrix algorithms much less cluttered with temporal object like 'row' 'column' and make it more homogenous. I'm not sure how to proceed in general. I think we are missing solid design principles -or at least the ambition to define them-: what are the concepts, algorithms and interfaces? Getting that right for just matrices is an overkill for this QFCL projects (let alone for MC, numerical solvers, back-end integration), and hence the project itself will by definition lack a solid foundation that gives it essential properties like genericacity, orthogonality etc. Without that we work for the next 5 years to come up with something as complicates and not-to-be-so-proud-of as QuantLib. That's not an inspiring outlook.You're right, we're pioneering here in a sense (even Stepanov mentioned two-dimensional iterators as going beyond the current STL -- and we're still before 2016 when he plans to teach a course on Generic Numerical Methods! ;-)Perhaps we could consider some ideas from here, like grids, grid functions and cell iterators:The Grid Algorithms Library (GrAL) http://www.math.tu-cottbus.de/~berti/gr ... nts?outrun -- any thoughts on the genericity of this approach?http://www.math.tu-cottbus.de/~berti/gr ... mlOOglesby also mentioned image iterators, I wonder how can we tie this together.Cuch -- the GrAL is "marketed" in the context of solving PDEs via FEM and FVM, but it seems to me there are common concepts that also apply to FDM -- what do you think?http://www.math.tu-cottbus.de/~berti/gr ... op_25.html
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

container bindings

November 20th, 2011, 7:20 pm

BTW, I've had some issues with connection to the above, this website may load faster:http://gral.berlios.de/http://gral.berl ... l/top.html
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

container bindings

November 20th, 2011, 8:01 pm

QuoteYou're right, we're pioneering here in a sense (even Stepanov mentioned two-dimensional iterators as going beyond the current STL -- and we're still before 2016 when he plans to teach a course on Generic Numerical Methods! ;-)That's a long lead time (5 year plan) What in the meantime?Had a quick look at GrAL. Documentation is a bit light. I was unable to find a 101 example (e.g. Laplace in 2d). The approach is somewhat new for someone with FEM Fortran background.
Last edited by Cuchulainn on November 19th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

container bindings

November 20th, 2011, 8:14 pm

Cuch, yes, there are several levels of documentation, see "Documentation" but also "Some Papers on GrAL" here: http://gral.berlios.de/For instance, there's a (short, indeed) discussion of Laplace equation example in here:http://gral.berlios.de/papers/design-principles.ps.gz BTW -- I'm not sure if I necessarily agree with all the entirety of the design decisions (haven't read all the docs and I have already noticed some use of operator[] which I'm not convinced is the way to go), but at the same time I find the introduced concepts (grid and several kinds of grid iterators introduced as refinements of respective STL iterators) quite helpful baseline to start a discussion on what are the possible avenues, what can we do differently (and why / why not), etc.
Last edited by Polter on November 19th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
OOglesby
Posts: 1
Joined: August 26th, 2011, 5:34 am

container bindings

November 20th, 2011, 11:03 pm

QuoteOriginally posted by: outrunBlas routines do it like that: they use descriptive info about how the matrix in stored in random access memory. So maybe that's enough? How about these two interfaces for a start:1) we provide (row,col) interface for plain simple non-optimized algorithms, following math style. This interface hides all underlying storage layouts details etc. instead of iterators..2.1) we provide a 1d random access to element in storage (for all sort of containers). This separates memory storage en layout.2.2) we provide layout information that algorithms can use in combination with the random access to optimization loops etc...so my suggestion might be is to go the BLAS way instead of iterator for optimizing. Have algorithms use random access memory and element layout information. We can always add iterators, but I think for fast code this interface is more essentialThis makes sense to me; after all, a raw pointer + length is the simplest form of iterator. I currently use method 2 in my general purpose finite difference routine. Plus, not every algorithm is going to need speed. Areas the demand easier maintainability over speed can simply use the (row, col) method.Your proposed matrix_interface bindings sound like they provide access to all of the required information for both 1 and 2.
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

container bindings

November 24th, 2011, 8:58 am

A very important banded class of matrices is non-symmetric tridiagonal matrices and the Thomas algorithmIt would be a good beta test because it is used a lot. I can test it on Crank Nicolsom, for example. For exceptions, the matrix may not have an inverse. There must be quite a few LU solvers at this stage.
Last edited by Cuchulainn on November 23rd, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

container bindings

November 24th, 2011, 3:50 pm

QuoteOriginally posted by: outrunCuch, Polter,For tensor layouts, I'm thinking of translating the row/col major concept to either traversal by coordinates left to right, or right to left, -no permutations-.Have you used (semi) banded tensorts? What is the non-zero structure, any proposals other than full dense? Symmetric? What sort of symmetric?No. Dense is fine. Have you looked at multi_array?
Last edited by Cuchulainn on November 23rd, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

container bindings

November 24th, 2011, 4:11 pm

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunCuch, Polter,For tensor layouts, I'm thinking of translating the row/col major concept to either traversal by coordinates left to right, or right to left, -no permutations-.Have you used (semi) banded tensorts? What is the non-zero structure, any proposals other than full dense? Symmetric? What sort of symmetric?No. Dense is fine. Have you looked at multi_array?the user-interface for user-developer, of the internal workings?Both