Re: [pdf-devel] filter testcases

[raskolnikov]

> just encode something, decode it and then compare with the
original data.

I don't fully agree with you. There are some problems that can't be
found in that way. Actually, there was a hidden problem in the
predictors filters which I solved in the last patch and could not be
seen by that method. The filter packed some bits in the wrong order,
and then read them back in the wrong order, so you could encode and
decode the data, but the encoded data did not follow the standards
requirments.

I think that it is better to provide a correct output which has been
checked by a human and compare with it.

Or even better, we could implement both methods. The one I explained
which is better to find bugs or problems between platforms -for example
endianess problems and such- and your purposed method, which is better
for benchmarking and performance tuning -because you can input large
loads of data that doesn't need special human checking.

Both, methods are quite easy to implement, so there should be no trouble
in my opinion.

--
PD: Marchesi, I resend this mail to the mailing list because I sent it
using the es.gnu webmail which does not reply tho the list when using the
reply button.