From: Thomas P. <tho...@lu...> - 2005-04-27 08:53:21
|
Michael Haggerty schrieb: > Thomas Pfaff wrote: > >>> Why are you so allergic to temporary files? In most cases they >>> won't be significantly slower, as the bulk of the time is for >>> Python to format the data as ASCII data, which has to be done >>> anyway. >>> >>> Write yourself a little helper function like utils.write_array() >>> but which is smart about date-formatted data. File PlotItems can >>> take arbitrary strings as their "using" argument. What else do you >>> need? >>> >>> >> >> Well, basically I didn't like the thought of "having to". In all cases >> regular PlotItems work fine, except for time-data where I would "have >> to" use File PlotItems just because only they would accept the using >> keyword, which seemed to me like some kind of a workaround. >> >> > > What's missing isn't the "using" functionality; it's the ability to > include date information in data to be sent to gnuplot, and the > ability to format the date information in a way that gnuplot can > read. Gnuplot.py uses Numeric arrays to hold the data to be plotted > (at least when using the Data PlotItem), and I don't know of a good > way to store date information within a Numeric array. Therefore the > input to Data would have to be in a different form to even get started > supporting dates. > >> Maybe if I understood the concept behind the interaction with gnuplot >> .... If you say that Python has to format the data as ASCII data >> anyway, is it maybe that Python just creates ASCII lines in gnuplot >> format from the data which are then fed to gnuplot via a pipe? >> > > That is correct, though depending on your settings the data might be > transferred inline via the gnuplot command-input pipe, via a named > pipe, or via a temporary file. > >> If I >> can know beforehand how the final line would look like (the data from >> the array marked as x-data would be the first in line, followed by the >> y-data and so on), wouldn't it suffice to have all PlotItems accept >> the 'using' keyword, and then I would just say "using 1:3" if my >> date-strings contained a space? >> >> > > I think the real problem is that dates cannot be expressed as > space-separated columns of numbers (or can they...?) Gnuplot.py > doesn't have a way to output arbitrary strings, at least not via the > Data PlotItem. > > Let us know what you work out, > Michael > Well a simple form would be to use numbers according to the %s format, which would be seconds since the UNIX-epoch (1970-01-01, 00:00 UTC). I would prefer Julian dates, as they cover a larger period of time (1 Jan 4716 B.C.E. to 31 Dec 5000000 AD), but one would have to ask the gnuplot-developers to offer that functionality, I suppose; that's nothing gnuplot.py can do. Another possibility, if you just need numbers separated by spaces, might be "2005 04 27 00 00 00" which would be "%y %m %d %H %M %S" for the time format string. Actually I just read in the gnuplot help, that the above format string would also recognize the "number" 20050427000000 as spaces in format strings stand for zero or more spaces. However it would need 64bit integers to represent such numbers. Yet still I suppose gnuplot will still try to read a string using some kind of strptime function? Cheers, Thomas -- _______________________________________________________ Dipl.-Ing Thomas Pfaff, M.Eng. Dr.-Ing. Karl Ludwig Beratender Ingenieur Wasserwirtschaft - Wasserbau Herrenstr. 14 76133 Karlsruhe Tel: 0721 / 91251-46 Fax: 0721 / 91251-19 tho...@lu... |