So basically hoist most of the data structure
typedef struct { struct _MatShellOps ops[1]; PetscScalar vscale,vshift; Vec dshift; Vec left,right; Vec left_work,right_work; Vec left_add_work,right_add_work; Mat axpy; PetscScalar axpy_vscale; PetscBool managescalingshifts; /* The user will manage the scaling and shifts for the MATSHELL, not the default */ void *ctx; } Mat_Shell; into Mat? MatShell handles the axpy (which is nasty), would you handle that as well, if not then you still have code duplication between the MatShell implementations and the Mat___Basic implementations. If it wasn't for the axpy I would say it is worth trying but including correctly the axpy (I am not sure if it is always handled correctly for MatShell) requires complex code. Barry > On Dec 1, 2018, at 1:49 PM, Hapla Vaclav <vaclav.ha...@erdw.ethz.ch> wrote: > > MatDiagonalScale_Shell, MatDiagonalScale_Normal, > MatDiagonalScaleHermitian_Normal and perhaps some others are essentially the > same. > > What about converting them into one MatDiagonalScale_Basic which would be the > default implementation if no type-specific implementation is provided? > > I'm asking because I wanted to add the same to MATTRANSPOSE. But with my > proposal, this redundancy would be removed and additionally > MatDiagonalScale() would work for any current or future MatType while it > doesn't prevent providing an optimised version for explicit matrix types. > > Note the same could be done for MatScale, MatShift, MatDiagonalSet and maybe > some others. > > I also think such approach would promote using such high-level API functions > in higher PETSc layers and user codes because one wouldn't have to be afraid > those methods might not be implemented in input matrices. > > Thanks for opinions > > Vaclav