Setting options on matrices obtained from a DM

[Matthew Knepley]

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

> Matthew Knepley wrote:
> > 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.
>
> If I call MatGetXXX(), I expect to either get a meaningful and usable
> result, or get an error.  As I understand your suggestion, I wouldn't
> get that unless SetUp had been called.  But I wanted to do something
> with that result which means that I will either get a request object (I
> keep control of when I do that thing with the result, this will be a
> PITA) or I give you a continuation for whatever I wanted to do with it


There is no way we would be doing conintuations. Why even bring this up?
This just complicates the discussion and distracts from the main issues.

The answer is incredibly easy and straightforward. Just like MANY  functions
in PETSc, you will not get the correct answer until things have been
initialized.
This just sounds like arguing for the sake of argument.

  Matt


> (but then I don't know when it will be executed which is confusing
> because the continuation will have side-effects, and it's a PITA to do
> continuations in C/C++/etc).  In Haskell, it's possible to maintain
> control of side-effects and have sane syntax for all these
> continuations, but we don't have (or want to be using) Haskell for this.
>
> To be concrete, someone is going to do:
>
>  TSGetSNES
>  SNESGetKSP
>  KSPGetPC
>  PCGetOperators
>  MatGetVecs
>  /* do something with the matrices and vectors */
>
> If the objects are not sufficiently set up when this is called, the
> current model will give an error which is easy to understand.  With your
> model, if we haven't called SetUp(), none of these objects will be
> available, so instead we'll pass a continuation for everything to do
> with them.  In pseudo-Haskell and skipping the obvious sugar, we'd have
> something like
>
>  TSGetSNES ts (\snes ->
>    SNESGetKSP snes (\ksp ->
>      KSPGetPC ksp (\pc ->
>        PCGetOperators pc (\(a,p) ->
>          MatGetVecs p (\(x,y) ->
>            -- do something with a,x,y
>          )))))
>
> The monad that this runs under would be able to control side-effects.
> That is, we have a type signature like
>
>  XXXGetYYY :: x -> (y -> M a) -> M a
>
> where the monad M controls the side-effects.  Doing this in C would be
> insane which means that I must be misunderstanding what you want to do.
>
> 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/9a58b9d5/attachment.html>