[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warn message in log summary


   Actually it was not a joke. Currently PETSc has pretty dynamic
ways of dispatching methods that I don't think could be
accomplished easily/cleanly using "simple features" (basic classes
and inheritance) of C++. And as soon
we start using complicated features of C++ we get a huge
hairball that you obviously want to avoid also.

In any future generation of PETSc I want to support the
mixing of vectors/matrices of different precisions/types (real/complex)
in the same code. This will require a dynamic dispatch based on
the storage types of ALL the arguments. Certainly doable in
C++ (you can do anything) but perhaps much less cumbersome
in python? Generating all this code is something that C++
templates can help, so one could write the numeric functions in C++
with templates and then dispatch between them all in Python.
I found some old package PyProtocols that looked like it
might be useful but its webpages are real old, I fear it may not
exist any more.

I don't think performance is an issue with python since all the
core numerics would be in straight-line C or Fortran code.

Other languages to consider: ruby? objective-c (2.0)? Fortran 2003?

   Barry



On Dec 7, 2007, at 4:32 PM, Lisandro Dalcin wrote:

On 12/7/07, Barry Smith <bsmith@xxxxxxxxxxx> wrote: 

I'm on Matt's side. Have you ever considered C++ for implementing
PETSc internals?

Python? 

Not sure if that was a joke, but in any case, definitely no. For PETSc
internals, and for many reasons,  a C++ code using simple features
(trying avoiding templates, rtti, and all data) like exception
handling and polymorphism would simplify a lot the implementation of
derived object types (the compiler fills for you the table of method
pointers) and error management (the compiler thow exceptions, you do
not need to check error codes at almost every line). If C++ exceptions
ever cause a loss of performance, the selected parts of all the code
doing very heavy number crunching can be implemented in C/Fortran.

If PETSc internal were implemented in C++, then we would be able to
take advantage of some tools like SWIG, straightforwardly enabling
cross-language polymorphism, for implementing new type objects in pure
python code, or even inherit for some type and specialize some
methods. But this would be for the long, long future.


On Dec 7, 2007, at 7:28 AM, Lisandro Dalcin wrote:

On 12/7/07, Matthew Knepley <knepley@xxxxxxxxx> wrote:
On Dec 6, 2007 9:00 PM, Barry Smith <bsmith@xxxxxxxxxxx> wrote: 
 I am very nervous about mixing a catastrophic error handling
system
WITH an exception system. I'd like to go back to the model:
"once seterrq() is called ANYWHERE there is no possibility of
continuing the program.


I guess I have the opposite opinion. I think it is inevitable that
PETSc
is rewritten at some point in the future. At that point, we would
replace
the current, imperfect exception system with a better one. This way
we
can preserve a good design. If we go the other way, all that code
will
have to be rethought instead of just rewritten.


I'm on Matt's side. Have you ever considered C++ for implementing
PETSc internals?

--
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594





--
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594