How about an aggregated trick, incrementally hashing each output crc value and
at the end just compare the hash against an expected value? Instead of
comparing each incremental crc value against a table. This trick works better
for many polynomials too. The hash doesn’t have to be strong so could be md5 or
something simpler (although I suggest not using crc).
/Simon
> 22 okt. 2024 kl. 14:02 skrev Bruno Haible <br...@clisp.org>:
>
> Sam Russell wrote:
>> ran the tests just printing out the values from the current implementation
>> and then put them into arrays that we now check against, the idea being
>> that the current implementation is correct and we expect future
>> implementations to match the current implementation
>
> Yes, that's the point of extending the unit test before adding the
> optimization :)
>
> But this is a huge amount of expected values (32 x 32). Which is a
> problem if we later want to support another polynomial too.
>
> I'd opt for reducing this set of expected values to 32 values,
> by reintroducing the memcpy() trick from your previous patch:
>
> for (i = 0; i < 32; i++)
> {
> memset (data, 0x55, sizeof (data));
> memcpy (data + i, randomb, ...);
> ...
> }
>
> Then there are only 32 expected values to find via printf() and to fill in.
>
> Bruno
>
>
>
