Setting options on matrices obtained from a DM

Matthew Knepley knepley at gmail.com
Thu Jul 23 09:50:13 CDT 2009


On Thu, Jul 23, 2009 at 9:45 AM, Jed Brown <jed at 59a2.org> wrote:

> Matthew Knepley wrote:
> >> MatExecute()?  What about MatGetXXX() before MatExecute()?
> >
> > It will reregister that function, so you would need another SetUp()
> > call, exactly the same interface we have now.
>
> But the user wants to call MatGetXXX() and use the result right away
> (instead of getting a request object or passing a continuation to be
> executed when the result is available).  The whole point of the
> continuation is to perform a side-effect which is going to cause
> confusing behavior.
>
> Currently they get an error if the result isn't available.  With the
> "register attributes, then execute" model, the result will almost never
> be available so everything they might do would go into a continuation.
>
> We could probably make this work (even with reasonable syntax) in a
> language like Haskell, but in an impure strict language I think it will
> snowball into a mess of side-effecting continuations being called at
> peculiar times.


It would be impossible for me to disagree more strongly. A user cannot
get information that is not setup in the current model. I really do not
understand your objection, and the Haskell discussion is bizarre. All I am
suggestion is that we use a better model for remembering what to do.

Barry suggests that individual functions remember data and when to
execute it. I am suggesting we use a uniform model for both remembering
the data and the dependecies. That is it. Very simple.

  Matt



>
> Jed
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090723/844d5fe4/attachment.html>


More information about the petsc-dev mailing list