warn message in log summary

[Lisandro Dalcin]

On 12/7/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
>     Actually it was not a joke.

OK, let see...

> 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.

Yo are right, simple features will start to be not enough at some
point. And you are right, dynamic languages like Python are far better
for dynamic dispatching, and far easier to code.

> 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.

This feature is similar to what 'numpy' does for multidimensional
arrays in Python (using data descriptors and coercion/casting rules).

> 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.

Yes, some nested 'switch'/'if' can be used to dispatch template
parameters of a templatized function. And some of them can be even
specialized for some datatype combinations, perhaps in Fortran.

> 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'll take a look.

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

Now I understand you were no joking. This is preciselly de way I use
Python every day.

After my fist intent of implemented derived type objects, let me say
that I reached a natural conclusion. Almost all KSP/SNES/TS interface
and subtypes could be easyly implemented in pure Python.

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

I firmly believe this kind of desicision should be dictate regarding
three aspects, in that order:
1) portability
3) easy interoperability with C
2) native support for inheritance and exceptions.



-- 
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