Hi, My 5 cents. 1. > I assume that any existing C/C++ math lib can be directly used > from any ROOT compiled application. (Rene) > (...) > Therefore I cannot recommend to introduce ROOT wrappers for high > performance libraries. One should use them in compiled code as they > are and not in CINT. (Thorsten ?) > (...) That's perfectly fine. The full speed can only be achieved by compiled code. We all know this (at least some of available C++ packages claim they can be as good as old fortran and/or C code) ... but ... 2. > - BUT, I see many people requesting: > -- interactive access via CINT (debugging purpose mainly). (Rene ?) ... we can't seem, however, to agree on the need of INTERACTIVE access to matrices, vectors, ..., from CINT. I fully support Rene's point, and more. I DO WANT interactive access to these data. My idea is the following - the time consuming algorithms are compiled, linked to the ROOT dynamically via a shared library. The organization of what happens (and when) is done by an INTERPRETED script (I mean, from the command line, for example). That is, for example, I create the matrix from the root prompt, then I call a compiled function to fill it, ..., and finally I look at results. Then I INTERACTIVELY multiply the matrix by some kind of a vector, or a number, and repeat the process. Maybe I decide to make the matrix diagonal, ... ? Maybe I create two matrices and decide to add them ? All these actions MUST be available from the interpreter. 3. > I have never proposed to introduce wrappers. (Rene ?) > (...) > It implies that one must be able to run rootcint on the header > files. (Rene ?) > (...) > I think is is a big mistake to consider only those numerical > libraries which can be fully used in CINT. (Thorsten) I think I do NOT need all features of a "full-dimension" library in CINT. A reasonable "subset" would perfectly be fine. All "complicated" tasks would anyhow be "pre-compiled". Then a reasonable "wrapper" would be fine. Why not ? Or one might create a "cut-down" version of original header files ? 4. > For me, the I/O is a crucial point (CINT being a different > priority) (Rene ?) > (...) > I do not see why I/O should be a critical point (Thorsten) Neither do I. For me the interactive access to matrices is the critical point (I/O being a different priority). 5. > ... the HERA-B experiment which uses a high performance C++ > Vector/Matrix algebra library ... (Thorsten) Can you predict whether your library can be made "visible" in CINT ? 6. Blitz++ ? LAPACK ? GSL ? Please note that Blitz++ is a vector/matrix library, not a linear algebra package (one needs a separate, external, algebra package). > ... The matrix dimensions here are typically of the order 3 - 5 > ... (Thorsten) I think that Blitz++ can highly optimize the code for small, fixed-size objects "by using templates cleverly, optimizations such as loop fusion, unrolling, tiling, and algorithm specialization can be performed automatically at COMPILE TIME". COMPILE TIME is perfectly fine for me. All "complicated" routines should be compiled. The "glue" logic INTERPRETED. I have NEVER said that Blitz++ is the ULTIMATE library. It is a VERY nice library, but .. if you can recommend anything better ... that can easily be made visible from CINT ... Best regards, Jacek.
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:45 MET