<div dir="ltr">On Thu, Jan 24, 2013 at 9:47 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im"><br><div class="gmail_quote">On Thu, Jan 24, 2013 at 9:39 AM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Testing for the same number of iterations is - as you mentioned - a terrible metric. I see this regularly on GPUs, where rounding modes differ slightly from CPUs. Running a fixed (low) number of iterations is certainly the better choice here, provided that the systems we use for the tests are neither too ill-conditioned nor too well-behaved so that we can eventually reuse the tests for some preconditioners.<div>

</div></div></blockquote></div><div class="gmail_extra"><br></div></div><div class="gmail_extra">That's something that certainly makes sense for tests of functionality, but not for examples/tutorials that new users should encounter, lest they get the impression that they should use such options.</div>

<br>Do you have much experience with code coverage tools? It would be very useful if we could automatically identify which tests were serving no useful purpose. The amount of time taken by make alltests is currently unreasonable, and though parallel testing will help, I suspect there are also many tests that could be removed (and time-consuming tests that could be made much faster without affecting their usefulness).</div>

</div>
</blockquote></div><br>Satish had gcov working before, but it just did not prove to be very useful. First, we generally write tests</div><div class="gmail_extra">to look at the workflow for something rather than as a unit test. Second, coverage ignores the path you</div>
<div class="gmail_extra">take to get to a certain line of code. My impression is that these things are only useful when they tell you</div><div class="gmail_extra">lines which are never exercised.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">   Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>