Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2008-02-22 12:36:23
|
Hi, I have some time data I can't see how to format to get it read in correctly. The seconds being decimal notation. # time ch1 ch7 14:33:02.250 0.615 0.635 14:33:02.450 0.615 0.640 14:33:02.650 0.615 0.635 the nearest I have got is this which obviously does not account for the decimal part. set xdata time set timefmt "%H:%M:%S" set format x "%02H:%02M:%02S" plot "adc.data" using 1:2 Is there a way to read this data with gnuplot or will I need to work another way? TIA, Peter. |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-02-22 18:00:35
|
On Friday 22 February 2008 04:35, pl...@pi... wrote: > > I have some time data I can't see how to format to get it read in > correctly. The seconds being decimal notation. This is a very long-standing request. See tracker items 536517 Higher resolution in timeseries plot 1078852 Flexible usage of geographic coordinates I think a patchset to address this would be very welcome. Or, if not an actual patch, at least a fully worked-out proposal for how such data would be handled both for input, for output, and for internal representation. Currently the internal representation of time is an integer number of seconds. Would one add a parallel float for the fractional seconds? Stick with an integer but multiply by 1000 to keep only millisecond precision? Something else? What are the conflicts between the requirements of degrees/minutes/seconds for spherical coordinate representation and hours/minutes/seconds for time representation? > # time ch1 ch7 > > 14:33:02.250 0.615 0.635 > 14:33:02.450 0.615 0.640 > 14:33:02.650 0.615 0.635 > > the nearest I have got is this which obviously does not account for the > decimal part. > > set xdata time > set timefmt "%H:%M:%S" > set format x "%02H:%02M:%02S" > > plot "adc.data" using 1:2 > > > Is there a way to read this data with gnuplot or will I need to work > another way? > > TIA, Peter. -- Ethan A Merritt Courier Deliveries: 1959 NE Pacific Dept of Biochemistry Health Sciences Building University of Washington - Seattle WA 98195-7742 |
|
From: <pl...@pi...> - 2008-02-22 18:50:11
|
On Fri, 22 Feb 2008 19:00:35 +0100, Ethan Merritt <merritt@u.washington.edu> wrote: > On Friday 22 February 2008 04:35, pl...@pi... wrote: >> >> I have some time data I can't see how to format to get it read in >> correctly. The seconds being decimal notation. > This is a very long-standing request. See tracker items > 536517 Higher resolution in timeseries plot > 1078852 Flexible usage of geographic coordinates Yes, that latter request was pretty explicit in terms of nomenclature. It should be fairly straight forward to %DD as a minimum solution to that request to prevent overflow at 24. Taking the same line , higher precision timescale could use %MS eg %HH:%MM:%SS.%MS internally maybe using a second int for microseconds as in struct timeval would carry the least overhead. (Don't forget embedded systems, possibly without an fpu ;) ) Any data requiring finer than microsecond resolution is unlikely to be using hours or minutes. These two , %DD and %MS , would not seem too complex to add and would not require massive changes to the input / output specifiers. Thanks for the reply, Peter. |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2008-02-22 23:04:32
|
Ethan Merritt wrote: > Currently the internal representation of time is an integer number > of seconds. Not really. time_t of the Standard C library is an integer, typically seconds since 1970-01-01 --- but our own time routines don't use that. Instead we use a double to hold seconds since 2000-01-01. For those who look at the code: please be aware that this matter is confused quite a bit by a long since aborted attempt to use the Standard C routines by proxy. Make sure you're looking at the right part of the giant #ifndef USE_SYSTEM_TIME around half of time.c. > What are the conflicts between the requirements of > degrees/minutes/seconds for spherical coordinate representation > and hours/minutes/seconds for time representation? In a nutshell: the different ranges for degrees vs. hours, including negative values, and the tendency of wanting the signs printed as 'N', 'S', 'W', or 'E' instead '+'/'-'. |
|
From: <pl...@pi...> - 2008-02-23 00:23:16
|
On Sat, 23 Feb 2008 00:04:17 +0100, Hans-Bernhard Bröker <HBB...@t-...> wrote: > Not really. time_t of the Standard C library is an integer, typically > seconds since 1970-01-01 --- but our own time routines don't use that. > Instead we use a double to hold seconds since 2000-01-01. So the code can already handle decimal fractions of seconds, it's just a case adding IO specifiers and adjusting the output routines. Is that correct? I presume axis labelling is done in a centralised fashion so as not to duplicate in each terminal , this sounds not too difficult. Would it be much work to add something like the microsecond specifier I suggested and get it to accept a decimal part. (Using %MM:%SS.%UUU takes care of any question of european locales using comma separtors on input.) Does that seem like a good approach? regards, Peter |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2008-02-23 16:21:43
|
pl...@pi... wrote: > So the code can already handle decimal fractions of seconds, No. Nothing in the code is actually prepared to work with fractions of seconds. Somebody just thought, a *long* time ago, that the usable range of 32-bit integers was a bit small (viz. the "Y2K37 problem"), and that most systems' "double" can hold a wider range of integers. > it's just a > case adding IO specifiers and adjusting the output routines. Is that > correct? No. "Just" isn't even remotely doing justice to the kind of trickery needed to keep time/date data handling in a state resembling sanity. > Would it be much work to add something like the microsecond specifier I > suggested and get it to accept a decimal part. (Using %MM:%SS.%UUU takes > care of any question of european locales using comma separtors on input.) It also goes against the grain of the existing format specifications. It should have to be "%M:%S:%U" or something like that --- except that it can't be %U. That's taken; see "help time_specifiers". |
|
From: <pl...@pi...> - 2008-02-23 18:01:09
|
On Sat, 23 Feb 2008 00:04:17 +0100, Hans-Bernhard Bröker <HBB...@t-...> wrote: > >> Currently the internal representation of time is an integer number >> of seconds. > Not really. time_t of the Standard C library is an integer, typically > seconds since 1970-01-01 --- but our own time routines don't use that. > Instead we use a double to hold seconds since 2000-01-01. >> So the code can already handle decimal fractions of seconds, > No. Nothing in the code is actually prepared to work with fractions of > seconds. Somebody just thought, a >*long* time ago, that the usable > range of 32-bit integers was a bit small (viz. the "Y2K37 problem"), and > >that most systems' "double" can hold a wider range of integers. So in effect Ethan was correct. Although stored in a double the value is integer and all arithemtic on the value is done as interger and there is no support for sub-second resolution in the time formats. The answer to my original enquiry is "no you can't" and it's all a long way off. Shame, you got my hopes up for a minute there. Thanks for explaining the state of play. This does however raise another question in my mind. I am mainly using gnuplot in an embedded context using softfloat. If all x coords are treated as double (although not using the fractional part) this mean a lot of unnecessary float operations at every step of the plot process. Mightn't it be worthwhile my changing this locally to use integer on an integer arch? Thanks again. Peter. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2008-02-23 18:12:26
|
On Saturday 23 February 2008 09:58, pl...@pi... wrote: > This does however raise another question in my mind. I am mainly using > gnuplot in an embedded context using softfloat. If all x coords are > treated as double (although not using the fractional part) this mean a lot > of unnecessary float operations at every step of the plot process. > > Mightn't it be worthwhile my changing this locally to use integer on an > integer arch? On input, data values are stored in a variable of type "coordval", which is either float or double depending on the architecture and configuration options. However when the data is used for plotting the program switches to using integer coordinates representing individual pixels to the precision of the current terminal. I doubt there is much room for switching to integers any earlier. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <pl...@pi...> - 2008-02-23 18:22:30
|
On Sat, 23 Feb 2008 19:12:09 +0100, Ethan A Merritt <merritt@u.washington.edu> wrote: > On Saturday 23 February 2008 09:58, pl...@pi... wrote: >> This does however raise another question in my mind. I am mainly using >> gnuplot in an embedded context using softfloat. If all x coords are >> treated as double (although not using the fractional part) this mean a >> lot >> of unnecessary float operations at every step of the plot process. >> >> Mightn't it be worthwhile my changing this locally to use integer on an >> integer arch? > > On input, data values are stored in a variable of type "coordval", > which is either float or double depending on the architecture and > configuration options. However when the data is used for plotting > the program switches to using integer coordinates representing > individual pixels to the precision of the current terminal. > > I doubt there is much room for switching to integers any earlier. > > OK! So internal calculation is always float of some sort or another and the original question of support for sub-second time resolution once again becomes a "simple" question of defining an input specifier and parsing the input data. Thus all plotting and fitting and other functions would account for the new precision. Thanks for the explainations. Peter. |
