<p>I don't see why it's unnatural for the member functions to take the location to evaluate as an argument.</p>
<p>In general, it is fragile and bad style to put any more state in a class member than necessary.</p>
<div class="gmail_quote">On May 8, 2012 8:31 AM, "Dominik Szczerba" <<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Because my (class member) functions to construct A(x) and b(x) rely on<br>
the same (class member) "x" as registered with KSP. I could perhaps<br>
set up my A and b routines to take "x" as an argument, but this is a<br>
bit unnatural for a class member function, and I can not quickly<br>
predict the consequences for the rest of the code either.<br>
<br>
Dominik<br>
<br>
On Tue, May 8, 2012 at 3:22 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
> Why a copy?<br>
><br>
> On May 8, 2012 8:16 AM, "Dominik Szczerba" <<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>> wrote:<br>
>><br>
>> >> I am currently assuming they are different and am using the "x" from<br>
>> >> the signature to set up my A(x) and b(x). I was thinking if they are<br>
>> >> the same (i.e. corresponding to x_n in the Newton method), I could<br>
>> >> significantly simplify my code. But apparently "x" in the signature is<br>
>> >> not simply x_n because of the involved line search, correct me if I am<br>
>> >> wrong.<br>
>> ><br>
>> ><br>
>> > Correct, they are not the same. How could it possibly simplify your code<br>
>> > "significantly"?<br>
>><br>
>> Significantly was perhaps too strong a word, but a vector copy and a<br>
>> couple lines of code would certainly go. Never mind, thanks a lot for<br>
>> the clarification.<br>
>><br>
>> Dominik<br>
</blockquote></div>