Barry, I'd think that adding efficient cross-type operations in C also has a combinatorial explosion problem :)
At the expense of a more complicated build system, the ugliness can be addressed in the following way: prior to compiling, ctags (or some sed script, etc.) is run against the source files to pull out the global symbol names. The list is then used to generate a header file which looks like: #if defined(USE_FLOAT) #define Sym1 Sym1_FLT ... #elif defined(USE_DOUBLE) #define Sym1 Sym1_DBL ... #endif I've done this kind of thing too, so I figured I'd mention it. It has the advantage that the source files are left essentially unchanged. -Hal Barry Smith wrote: > > Hal, > > Thanks for the suggestion. I've played around with this approach over > the years, but given the size of PETSc I've always been too frightened > by the uglyness and complexity of maintaining such code. It also doesn't > cleanly handle mixing objects of different types together. For example, > from a user perspective it is completely reasonable to try to multiply a > complex vector by a real matrix, or conversely a real vector by a > complex matrix, or to put real values into a complex matrix or vector > but providing support for this requires even more "templating-like" > stuff with macros. > > Barry > > On Jan 22, 2010, at 10:23 PM, Hal Finkel wrote: > >> Barry, >> >> I've used the following process to achieve a similar effect in C >> projects: >> >> Modify the make files to build each source file multiple times, once >> for each base type (float, double, double complex, etc.). The type is >> selected via a preprocessor definition provided on the command line >> (-DUSE_FLOAT, -DUSE_DOUBLE, etc.). A prefix or suffix specific to each >> type is appended to the name of the resulting object file (so that >> they're unique). Also, the function names (and all other global >> symbols) in each file are wrapped with a function-like macro which >> appends a prefix or suffix depending on the current type selected. In >> this way, everything can be included in one library without conflict >> or unnecessary code duplication. >> >> -Hal >> >> Barry Smith wrote: >>> The issue is that PETSc is written in C and there are not C++ >>> templates in C. We do not want to write TWO copies of each file, one >>> with dcomplex everywhere and another with double everywhere and give >>> different names to the functions in each language. It would be a pain >>> to write and maintain and a pain to use. Who wants to write >>> MatSolve() to solve with real numbers and MatSolveComplex() to solve >>> with complex? >>> C++ templates can be used to make all this possible but they are not >>> perfect to the task. Basically we need a better language to allow >>> easy mixing of dcomplex and double. >>> Barry >>> On Jan 22, 2010, at 2:43 PM, Yujie wrote: >>>> Dear Barry, >>>> >>>> What are the difficult things if PETSc is revised with matrices of >>>> complex and real numbers? It should be more flexible for a general >>>> scientific toolbox. I am curious almost all the packages don't >>>> support both simultaneously. Thanks a lot. >>>> >>>> Regards, >>>> Yujie >>>> >>>> On Fri, Jan 22, 2010 at 2:35 PM, Barry Smith <bsmith at mcs.anl.gov> >>>> wrote: >>>> >>>> The way we handle complex numbered linear systems in PETSc is to >>>> compile all of PETSc with complex numbers and then just use the >>>> solvers on those complex numbers. The current drawback to this is >>>> that PETSc can only be built with support for complex numbers or for >>>> real numbers. We cannot build a PETSc where some matrices are >>>> complex and some are real. >>>> We don't have any interest in solving complex systems as larger real >>>> systems. >>>> >>>> Barry >>>> >>>> >>>> On Jan 22, 2010, at 11:04 AM, Yujie wrote: >>>> >>>> Dear PETSc Developers, >>>> >>>> Recently, I am trying to find some complex number-based solvers and >>>> preconditioners. However, it is difficult to find a general >>>> framework to include some solvers and preconditioners. Trilinos is >>>> developing a package, komplex, to use the real-number-based solver >>>> to solve complex number -based problem. I don't know whether PETSc >>>> wants to develop such the function for complex number-based problem. >>>> I think it will significantly increase the application range of >>>> PETSc. After all, in PETSc, lots of solvers and preconditioners have >>>> been developed. Thanks a lot. >>>> >>>> Regards, >>>> Yujie >>>> >>>>
