[Kst] Time index lookup

[Nicolas Brisset]

Hi Barth,

Thanks for the explanations, that sounds really good... and will be pretty neat to work with the forthcoming (?) ASCII date/time support.
I have some ideas I will detail later, but some quick remarks: 
1) please make the name of the time vector configurable. Not everybody speaks English, remember? I have bunches of files where time is called Temps :-)
2) if binary search is not fast enough, maybe we could store an index of 100 of 1000 intermediate time values to initialize the search (not sure it'S worth it, though, just an idea like that. Nad maybe I should read up on what binary search exactly is...)
3) I hope we will quickly have a convenient way to input date and time because a float value is not going to be fun to work with!

I can't wait to see that :-)

Nicolas

P.S.: while we are at sharing ideas for cool new features, I have had another idea I find quite nice. We regularly have requests to limit plugins, statistics computations etc to the visible part of the curves/vectors. As of now we have ne easy way of doing that, but why not add an entry in the range menu which would just restrict the vectors to currently visible data? I think that would be fairly easy to implement and pretty cool: you could visually zoom in on the interesting part of the data, compute whatever you want, store the result and switch back to the whole file or a different data range using the range tools. What do you think of that idea? It would be a sort of "visual range tool"...

----- Mail original -----
> De: "Barth Netterfield" <netterfield at astro.utoronto.ca>
> À: "kst" <kst at kde.org>
> Envoyé: Mardi 24 Juillet 2012 17:00:32
> Objet: [Kst] Time index lookup
> 
> 
> For BLASTpol, I need to implement the ability to index samples by
> time, rather than by frame number. So I'm going to implement it.
> Here is my initial plan:
> 
> 
> In the field range widget, there is a combo box that currently only
> includes 'frame'.
> Kst will add to the combo box any vector fields provided by the data
> source which happen to be called "time", "Time", or "TIME". kst will
> assume that these fields will be monotonically increasing (though it
> will be able to look for and ignore short telemetry glitches).
> The user can then do a lookup with these fields instead of frames.
> Kst will do a binary search to find the right frames, and then read
> them in.
> 
> 
> In the first instance, you will enter the times as numbers in
> whatever format the fields store them.
> 
> 
> Eventually, you will be able to tell kst (how?) what to interpret the
> fields as, and then use text type time entry (eg, yyyy/mm/dd
> hh:mm:ss). But not in the first instance.
> 
> 
> 
> --
> C. Barth Netterfield
> University of Toronto
> 416-845-0946
> 
> 
> 
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>