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 at mcs.anl.gov> 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 at gmail.com> wrote:
>>>> On Dec 6, 2007 9:00 PM, Barry Smith <bsmith at mcs.anl.gov> 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
>
