<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Yes, this would a good option as well.
<div class=""><br class="">
</div>
<div class="">Also nice it would be easy to distinguish "implicit" matrices, where people shouldn't expect e.g. MatGetRow() to work, as subtypes of shell...</div>
<div class=""><br class="">
</div>
<div class="">Vaclav<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 7 Dec 2018, at 11:28, Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com" class="">stefano.zampini@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="auto" class="">I think the best solution is to have mattranspose, matnormal and similar to be subclasses of matshell</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">Il giorno Dom 2 Dic 2018, 02:23 Smith, Barry F. via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" class="">petsc-dev@mcs.anl.gov</a>> ha scritto:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
I am fine with you giving this a try. I fear it mostly just moves the complications from one (several :-)) places to a different place but.<br class="">
<br class="">
Barry<br class="">
<br class="">
<br class="">
> On Dec 1, 2018, at 2:47 PM, Hapla Vaclav <<a href="mailto:vaclav.hapla@erdw.ethz.ch" target="_blank" rel="noreferrer" class="">vaclav.hapla@erdw.ethz.ch</a>> wrote:<br class="">
> <br class="">
> Yes, that means that a significant part of MatShell logic would become default implementations. But I would now do that only with MatDiagonalScale as a proof-of-concept - then we can progressively do the same with the others. At some point it could happen
even with axpy - I think it would be cool although more a complex task as you say.<br class="">
> <br class="">
> Vaclav<br class="">
> <br class="">
>> 1. 12. 2018 v 21:31, Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov" target="_blank" rel="noreferrer" class="">bsmith@mcs.anl.gov</a>>:<br class="">
>> <br class="">
>> <br class="">
>> So basically hoist most of the data structure <br class="">
>> <br class="">
>> typedef struct {<br class="">
>> struct _MatShellOps ops[1];<br class="">
>> <br class="">
>> PetscScalar vscale,vshift;<br class="">
>> Vec dshift;<br class="">
>> Vec left,right;<br class="">
>> Vec left_work,right_work;<br class="">
>> Vec left_add_work,right_add_work;<br class="">
>> Mat axpy;<br class="">
>> PetscScalar axpy_vscale;<br class="">
>> PetscBool managescalingshifts; /* The user will manage the scaling and shifts for the MATSHELL, not the default */<br class="">
>> void *ctx;<br class="">
>> } Mat_Shell;<br class="">
>> <br class="">
>> 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.<br class="">
>> <br class="">
>> <br class="">
>> Barry<br class="">
>> <br class="">
>> <br class="">
>>> On Dec 1, 2018, at 1:49 PM, Hapla Vaclav <<a href="mailto:vaclav.hapla@erdw.ethz.ch" target="_blank" rel="noreferrer" class="">vaclav.hapla@erdw.ethz.ch</a>> wrote:<br class="">
>>> <br class="">
>>> MatDiagonalScale_Shell, MatDiagonalScale_Normal, MatDiagonalScaleHermitian_Normal and perhaps some others are essentially the same.<br class="">
>>> <br class="">
>>> What about converting them into one MatDiagonalScale_Basic which would be the default implementation if no type-specific implementation is provided?<br class="">
>>> <br class="">
>>> 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.<br class="">
>>> <br class="">
>>> Note the same could be done for MatScale, MatShift, MatDiagonalSet and maybe some others.<br class="">
>>> <br class="">
>>> 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.<br class="">
>>> <br class="">
>>> Thanks for opinions<br class="">
>>> <br class="">
>>> Vaclav<br class="">
>> <br class="">
> <br class="">
<br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>