[darcs-devel] [patch1979] better shrinking for patches

Ben Franksen bugs at darcs.net
Mon Feb 24 13:01:20 UTC 2020


Ben Franksen <ben.franksen at online.de> added the comment:

> The first shrink result is 'FlippedSeal qs' which omits one of the
> patches from 'ps'.

Sorry for being dense. I just couldn't see that. All clear now.

> Shrinking is iterative and a shrink function is only expected to produce
> "immediate" shrinks. For one iteration, QC will take the first shrink
> that fails the test, but then will attempt to further shrink that
> result. It will only terminate if there are *no* shrinks that fail the test.

Okay... I didn't know about that.

> So any final result from shrinking will be locally minimal: there will
> be no further shrinks possible to that value. There certainly could be
> weird failures where e.g. lists of size 4 and 6 fail, but none of size
> 5, and so we'd get stuck at 6 if we just shrink by 1 element each time.
> But more of the time it's just about performance, i.e. the faster we
> find smaller shrinks the less work we do.

I think I understand now, thanks for the explanation. So we drop one
patch from e.g. the head of the sequence. If that fails the test, QC
will try to further shrink that sequence, etc. If they all fail, then it
will finally try NilFL. But if one doesn't we'll be stuck. If this is
so, then shrinking a sequence with something like 'reverse . tailsFL' in
one go looks like an easy improvement.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1979>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 4211 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-devel/attachments/20200224/9f2740b1/attachment.key>


More information about the darcs-devel mailing list