netterfield at astro.utoronto.ca
Thu Jun 14 01:07:46 UTC 2012
On Tue, Jun 12, 2012 at 5:40 PM, Nicolas Brisset <nicolas.brisset at free.fr>wrote:
> What is your next target? The point scaling issues? The ASCII issue with
> empty columns?
ASCII issue should now be fixed. I would like to rework data points and
> Or should we start trying to implement ASCII date/time as per
> https://bugs.kde.org/show_bug.cgi?id=243684, which is my personal
> favorite new feature for the next version, hopefully?
That will be fun and useful, but requires a well thought through plan -
which we have started.
> I have been thinking a bit after you implemented EXCEL time and I believe
> we have to find a way to represent dates as doubles (maybe the current
> approach is jsut fine, I just don't know the details)
They are. There are several ways with different offsets though: ctime, JD,
Excel. The scaling doesn't matter, but the offset does. The further you
are from the epoch/zero of the standard, the lower the resolution you get.
So you want to use ctime if you can get away with it. kst's
implementation of ctime times is happy to go negative I think, so it will
probably always be either the best or an acceptable choice. So I think
that we will just output time vectors in ctime.
> and then get the ASCII datasource to interpret the strings as dates and
> produce the right values.
> We should also probably add a "TimeType" enum property to vectors to say
> if they are time vectors, and how they should be interpreted. We could then
> set it from the wizard, the plot axis properties, or the vector dialog. If
> it is set on a vector used for X axis, we could then switch on time
> interpretation automatically.
> How does that sound (it's only a rough online to get the discussion
Sounds correct. The TimeType enum would just set the defaults when
creating a plot. You will still be able to change them, like you can now.
> Kst mailing list
> Kst at kde.org
C. Barth Netterfield
University of Toronto
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kst