<div dir="ltr"><div class="gmail_extra"><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 id=":2m9">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 class="im">
</div></div></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra" style>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>