Re: [Plplot-devel] Plotting time axes
Following some useful discussion on the list, I have now implemented a first go at this new functionality. As I originally suggested, I have added a new API function pltimefmt which specifies the format to use. This uses the C library strftime to do the actual work, so any formats supported by strftime on your system will be available. To enable the date / time labels, use the "d" option (for date) in plbox. This will interpret the data as seconds since the epoch. "t" is already in use so we can't have that. Example 29 (currently just for C - don't propagate until it is finalised) demonstrates the functionality. Some caveats 1) You can enable / disable date-time formats for each axis independently, but there is currently no way to specify different formats for each axis. Perhaps we need a plxtimefmt and plytimefmt? As an example of why we might want to do this, consider plot 2 in example 29. 2) Currently no way of using this with plenv. We need to invent some new axis codes. 3) No cmake checks that time.h, strftime and gmtime are available on the system. There are all in Posix, C89 and C99 so should be available as standard on all recent compilers. 4) In order to keep with the same plotting functions this involves cast PLFLT to time_t, which may have some resolution / range issues. I don't see any other way of easily doing this though. 5) Possibly others... Andrew - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plotting time axes
Andrew Roach wrote: At 11:47 AM 23/11/2007 -0800, you wrote: The C library internal representation of time as a time_t variable does have the well-known drawback you mentioned of a rather limited date range for those systems where time_t is defined as a 32-bit integer, see discussion in http://en.wikipedia.org/wiki/Year_2038_problem . Note, however, hardware is rapidly moving to 64-bit right now. For example, my impression from a recent computer buy is that 64-bit has become the norm rather than the exception for new PC's. Thus, on PC's at least, I don't think the above 32-bit time_t issue is going to be relevant for too much longer. Just to put things in context, even 32-bit versions of Windows now treats time internally as an unsinged 64-bit int measured in 100 nanosecond intervals from 1st January 1601. Well, in that case, using strftime() and time_t ought to be okay for all but the most demanding applications. I just did not want such a new feature to be hampered from the beginning by a rather arbitrary limit. (Oh, I checked for MS Visual C/C++ 6.0: that uses a 32-bits type for time_t, version 7 uses a 64-bits type. And my pretty old MingW environment uses a 32-bits type.) Regards, Arjen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plotting time axes
At 11:47 AM 23/11/2007 -0800, you wrote: >The C library internal representation of time as a time_t variable does have >the well-known drawback you mentioned of a rather limited date range for >those systems where time_t is defined as a 32-bit integer, see discussion in >http://en.wikipedia.org/wiki/Year_2038_problem . Note, however, hardware is >rapidly moving to 64-bit right now. For example, my impression from a >recent computer buy is that 64-bit has become the norm rather than the >exception for new PC's. Thus, on PC's at least, I don't think the above >32-bit time_t issue is going to be relevant for too much longer. Just to put things in context, even 32-bit versions of Windows now treats time internally as an unsinged 64-bit int measured in 100 nanosecond intervals from 1st January 1601. -Andrew - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plotting time axes
On 2007-11-23 10:24+0100 Arjen Markus wrote: > Alternative representations of date and time could be Julian dates > (effectively > the number of days, time as a fraction, since well before Christ). The > advantage > of that is that the definition is platform-independent, which is not the case > for > the number of seconds since "epoch" - ubiquitously but not universally chosen > to be midnight, 1 january 1970. Another advantage is that the valid range is > much larger than that for the number of seconds (if stored as a 32-bits > signed integer): > - Julian dates range from effectively the beginning of time to Armageddon, > as they are stored as double precision reals (resolution is slightly more > than milliseconds, IIRC). > - The date/time as seconds since 1 january 1970 ranges from 1903 to 2037 > (IIRC) > > The drawback is that you will have to write more code (I am not aware of > strftime()-equivalent for Julian date/time, but there might be). And perhaps > the API will be more involved - dealing with the Gregorian calendar > more explicitly. But there are good algorithms to do these conversions. > Hi Arjen: I do have some concerns about your idea which I hope Andrew will consider before making his final decision. If Andrew uses the (local) C library time_t variable convention then that same (local) C library can be used to convert the user's specific time representation into the time_t representation. Using some representation other than time_t puts an extra burden on both Andrew and each user. The C library internal representation of time as a time_t variable does have the well-known drawback you mentioned of a rather limited date range for those systems where time_t is defined as a 32-bit integer, see discussion in http://en.wikipedia.org/wiki/Year_2038_problem . Note, however, hardware is rapidly moving to 64-bit right now. For example, my impression from a recent computer buy is that 64-bit has become the norm rather than the exception for new PC's. Thus, on PC's at least, I don't think the above 32-bit time_t issue is going to be relevant for too much longer. In the past for long time series, I have used special programming to convert my particular time representation to Julian day number, and then plotted that Julian day number as the independent variable. Those who are stuck with 32-bit time_t and who want to plot a time series outside the 32-bit time_t limits can always ignore Andrew's new time API fall back to using this approach. I guess my principal concern is various vendors (both Unix/Linux/Mac OS X vendors and the one windows vendor) have tried to struggle with time representation issues for years. Does Andrew want to wade into that tarpit? I just think it would be easier for him (and users) if he just adopted whatever convention the local C library used for time_t. But the decision is, of course, up to Andrew since he is the one volunteering to do the coding. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plotting time axes
On Fri, Nov 23, 2007 at 10:24:18AM +0100, Arjen Markus wrote: > Alan W. Irwin wrote: > > >I was interested enough so I googled for strftime. strftime appears > >to be a comprehensive time formatting routine that would be a good to > >use. There is even a "poor man's version" that you could use > >from http://www.perlmonks.org/?node_id=290054. > > > >Anyhow, I think you have a good idea. > > > Alternative representations of date and time could be Julian dates > (effectively > the number of days, time as a fraction, since well before Christ). The > advantage > of that is that the definition is platform-independent, which is not the > case for > the number of seconds since "epoch" - ubiquitously but not universally > chosen > to be midnight, 1 january 1970. Another advantage is that the valid > range is > much larger than that for the number of seconds (if stored as a 32-bits > signed integer): > - Julian dates range from effectively the beginning of time to Armageddon, > as they are stored as double precision reals (resolution is slightly more > than milliseconds, IIRC). > - The date/time as seconds since 1 january 1970 ranges from 1903 to 2037 > (IIRC) > > The drawback is that you will have to write more code (I am not aware of > strftime()-equivalent for Julian date/time, but there might be). And perhaps > the API will be more involved - dealing with the Gregorian calendar > more explicitly. But there are good algorithms to do these conversions. > > Still, having a date/time type axis will be a good thing! It will enable us > to implement a number of "financial" plot types, for instance (see a > question > on the list from may/june this year). I've also used julian day for work related stuff (often just day within the year). As you say, this gives a wider range of dates. For compatibility with all the other plotting routines we will have to store the date as PL_DOUBLE internally, and so it perhaps makes sense to use the julian day, rather than number of seconds which is usually stored as a 32-bit integer. The 32-bit integer breaks down about 2038 when we need to switch to a 64-bit integer. I'm sure by then 64-bit computing will be ubiquitous. Anway, for now, perhaps being limited to 1970-2038 is a little restrictive for a plotting library. My other thought (more work, but more flexible) is to use something like the julian day or number of seconds, but allow you to define your own epoch. For example, often you know what day of the year it is, or hour of the day. By setting the epoch to the start of that year or day you avoid the user having to explicitly calculate the number of years since some distant epoch. Alternatively we could supply routines to do this calculation. The other advantage of this is that it keeps the julian day small and increases the number of decimal places and hence the time resolution. This might be important for those wishing to plot millisecond data. Algorithms for calculating julian day <-> yy/mm/dd hh:mm:ss are relatively simple so this is not a coding problem. More complicated is the code for parsing the output template - which is where strftime would have come in useful. Andrew - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plotting time axes
Alan W. Irwin wrote:
On 2007-11-22 19:18- Andrew Ross wrote:
For some time I've been pondering ways of plotting up time series over
days / months. Many plotting packages (e.g. gnuplot) provide special
options for time series so you can format the axis labels in a human
dd/mm type format for example. Plplot currently has no such facility.
This has been brought up on the list before. It is also something I'd
personally find useful in my work.
What I am thinking about is adding a new (x|y)opt flag for plaxes, perhaps
'T'. This would interpret the corresponding axis as a time. The format
of the time would be determined using a new function, perhaps pltimefmt
which would allow you to specify the time format,
e.g. pltimefmt("%H:%d")
would format the labels as hour:minute. I would suggest adopting the
format used by strftime. This function is relatively standard (it is
in SVr4, C89 and C99) and would make a good basis for the formatting
routine. Again, there is the question of how a time should be
represented. I would suggest interpreting the data as seconds since 1st
Jan 1970 (the usual standard).
Any comments?
I was interested enough so I googled for strftime. strftime appears
to be a comprehensive time formatting routine that would be a good to
use. There is even a "poor man's version" that you could use
from http://www.perlmonks.org/?node_id=290054.
Anyhow, I think you have a good idea.
Alternative representations of date and time could be Julian dates
(effectively
the number of days, time as a fraction, since well before Christ). The
advantage
of that is that the definition is platform-independent, which is not the
case for
the number of seconds since "epoch" - ubiquitously but not universally
chosen
to be midnight, 1 january 1970. Another advantage is that the valid
range is
much larger than that for the number of seconds (if stored as a 32-bits
signed integer):
- Julian dates range from effectively the beginning of time to Armageddon,
as they are stored as double precision reals (resolution is slightly more
than milliseconds, IIRC).
- The date/time as seconds since 1 january 1970 ranges from 1903 to 2037
(IIRC)
The drawback is that you will have to write more code (I am not aware of
strftime()-equivalent for Julian date/time, but there might be). And perhaps
the API will be more involved - dealing with the Gregorian calendar
more explicitly. But there are good algorithms to do these conversions.
Still, having a date/time type axis will be a good thing! It will enable us
to implement a number of "financial" plot types, for instance (see a
question
on the list from may/june this year).
Regards,
Arjen
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plotting time axes
On 2007-11-22 19:18- Andrew Ross wrote:
>
> For some time I've been pondering ways of plotting up time series over
> days / months. Many plotting packages (e.g. gnuplot) provide special
> options for time series so you can format the axis labels in a human
> dd/mm type format for example. Plplot currently has no such facility.
> This has been brought up on the list before. It is also something I'd
> personally find useful in my work.
>
> What I am thinking about is adding a new (x|y)opt flag for plaxes, perhaps
> 'T'. This would interpret the corresponding axis as a time. The format
> of the time would be determined using a new function, perhaps pltimefmt
> which would allow you to specify the time format,
> e.g. pltimefmt("%H:%d")
> would format the labels as hour:minute. I would suggest adopting the
> format used by strftime. This function is relatively standard (it is
> in SVr4, C89 and C99) and would make a good basis for the formatting
> routine. Again, there is the question of how a time should be
> represented. I would suggest interpreting the data as seconds since 1st
> Jan 1970 (the usual standard).
>
> Any comments?
I was interested enough so I googled for strftime. strftime appears
to be a comprehensive time formatting routine that would be a good to
use. There is even a "poor man's version" that you could use
from http://www.perlmonks.org/?node_id=290054.
Anyhow, I think you have a good idea.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Plotting time axes
For some time I've been pondering ways of plotting up time series over
days / months. Many plotting packages (e.g. gnuplot) provide special
options for time series so you can format the axis labels in a human
dd/mm type format for example. Plplot currently has no such facility.
This has been brought up on the list before. It is also something I'd
personally find useful in my work.
What I am thinking about is adding a new (x|y)opt flag for plaxes, perhaps
'T'. This would interpret the corresponding axis as a time. The format
of the time would be determined using a new function, perhaps pltimefmt
which would allow you to specify the time format,
e.g. pltimefmt("%H:%d")
would format the labels as hour:minute. I would suggest adopting the
format used by strftime. This function is relatively standard (it is
in SVr4, C89 and C99) and would make a good basis for the formatting
routine. Again, there is the question of how a time should be
represented. I would suggest interpreting the data as seconds since 1st
Jan 1970 (the usual standard).
Any comments?
Andrew
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
