[Kst] Re: CDF datasource debugging ?
George Staikos
staikos at kde.org
Thu Jul 15 22:21:21 CEST 2004
I have the CDF plugin working here now, with a sample database. So far it
looks to be ok - it just needs some bug fixes. I don't fully understand how
CDF works though, so I can't comment too much on how it fits into Kst yet.
In piolib we have a gross hack that needs to be fixed. Actually this is high
on my TODO list. Please don't look at that code. :-)
On Thursday 15 July 2004 13:59, Barth Netterfield wrote:
> On July 15, 2004 11:57 am, Nicolas.Brisset at eurocopter.com wrote:
> > > and the samples are assumed to be
> > > evenly distributed through the frame.
> >
> > That's just the problem I have. In the data I'm using (you may look at a
> > typical example in the .cdf file I sent recently), there are "blocks"
> > which you can imagine as groups of columns. In each group, the first
> > column gives the cycle number of the recording computer in which the
> > variables in the following columns were measured, but it is NOT evenly
> > spaced. It is not a "hard" real-time environment, and records may come
> > one cycle earlier or later :-(
> > That makes it very difficult to implement the scheme you describe, and
> > I'd much prefer to return the biggest number of records for the whole
> > file in frameCount(), 1 in samplesPerFrame(...), and handle the fact that
> > some variables have less points in readField() by returning 0 (or -1)
> > when asked for values beyond the last available for this field, treating
> > it as a sort of error. It means that X=INDEX will not be consistent in my
> > case, but if I use the right cycle for X then things will be OK. Do you
> > foresee any problem with this approach ?
>
> Two options:
> 1) Encode 'group/block' awareness into kst. So a data-source presents
> a group. Perhaps a syntax like "/data/datafile.cdf:group1" for the
> file name?
> + everything within a block (group) appears to be consistent with
> how kst thinks. (sampled together, with an x-axis variable availible)
> - May require changes to the kst UI. (eg, dataselector needs to know
> about groups for, eg, auto completion)
>
> 2) do as you suggest, but use NAN rather than 0 or -1. kst gracefully
> deals with NANs as much as is possible.
> + pretty easy
> - not a nice solution for looking at the data.
>
> I really don't like #2. If we can do #1, it will be a lot better I think.
> George, how did you end up dealing with implementing #1 in piolib?
--
George Staikos
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst
mailing list