[Kst] extragear/graphics/kst/tests
Adam Treat
treat at kde.org
Fri Oct 13 17:17:29 CEST 2006
On Friday 13 October 2006 9:50 am, Barth Netterfield wrote:
> I agree that this is what the code appears to be intending to do, and it
> seems correct. What is it actually doing?
>
> cbn
Well, right now the code modifies the number of frames based on the value of
Skip, but I think it does so incorrectly. This is the current way and was
committed by Andrew. I think it is incorrect:
new_nf = (new_nf/Skip)*Skip;
In the testcase I described below, new_nf is initially equal to the frameCount
of the datasource, ie 15. All of those values are integers.
In my view, this value should be equal to 11, ie the count from the first
included frame to the last included frame. Here is how I arrive at the
value:
new_nf = int((floor(double(fc - (new_f0 + 1)) / (double)Skip) * (double)Skip)
+ 1);
Anyway, the point is we should come up with a set of testcases that we can all
agree on. I'd like to understand how you expect the numberOfFrames to vary
according to the value of Skip and why.
> On Friday 13 October 2006 03:55, Brisset, Nicolas wrote:
> > > The skip frames tests currently fail for calculating the nf
> > > and f0 in various scenarios.
> > >
> > > It seems my expectations for what skip will do differ from
> > > the current implementation. Consider the given testcase
> > > where we have 15 items indexed from 0 to 14. The RVector is
> > > created with nf = -1 (readToEOF), f0 set to 0 (first frame)
> > > and a skip value of 5. I would expect that the result would
> > > be a vector with 3 items {0, 5, 10}. Item #14 does not fit
> > > the the skip frame, thus the size of the vector is 3 and the
> > > number of frames is 11 (the count of the items between 0 and
> > > 10 inclusive).
> >
> > This is also what I expect. How about f0 = 2 for instance ?
When reading from left to right (ie, readToEOF() or from f0 to NF) I would
expect that f0 is never modified based on the value of Skip. Instead, we'd
modify nf based on the value of f0 and Skip. We should respect that the user
has set an initial starting frame and modify nf to the skip boundary based on
that.
When reading from right to left (ie, countFromEOF()) I suppose we should do
the same but with f0 equal to the last frame in the file.
Right now, the code modifies f0 AND nf. I don't understand this behavior.
Adam
More information about the Kst
mailing list