Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1179 Ranges don't accept negative %s times

closed-out-of-date
nobody
2D plot (258)
5
2015-03-23
2012-10-08
Craig DeForest
No

Although the data processing step accepts negative %s times, range processing doesn't (even if they are in quotes).

In the pasted example, I plot two points at the Apollo 11 launch (1967) and the last second of the old millennium (1999-12-31T23:59:59). Without ranging it works fine. Setting the X range truncates the graph at 1/1/1970 (Unix time zero).

Is the range parsing artificially limiting %s to nonnegative numbers?

(Sorry for the messed up plots - paste into a fixed-font window for clarity)

[dhcp-10-72:~] zowie% gnuplot

G N U P L O T
Version 4.6 patchlevel 0 last modified 2012-03-04
Build System: Darwin x86_64

Copyright (C) 1986-1993, 1998, 2004, 2007-2012
Thomas Williams, Colin Kelley and many others

gnuplot home: http://www.gnuplot.info
faq, bugs, etc: type "help FAQ"
immediate help: type "help" (plot window: hit 'h')

Terminal type set to 'aqua'
gnuplot> set terminal dumb
Terminal type set to 'dumb'
Options are 'feed size 79, 24'
gnuplot> set output "/dev/tty"
gnuplot> set timefmt "%s"
gnuplot> set xdata time
gnuplot> plot '-' using 1:2 with points
input data ('e' ends) > -14552880 1
input data ('e' ends) > 946684799 2
input data ('e' ends) > e

2 +++-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-++A
+ + + + + + + + '-' using 1:2 +A +
| |
| |
1.8 ++ ++
| |
| |
| |
1.6 ++ ++
| |
| |
1.4 ++ ++
| |
| |
| |
1.2 ++ ++
| |
| |
+ + + + + + + + + + + +
1 +++-+A+-+-+--+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+++
01/01/19671/197001/19731/19761/19791/198201/19851/19881/19911/199401/1997/2000

gnuplot> set xrange ["-14552880":"946684799"]
gnuplot> plot '-' using 1:2 with points
input data ('e' ends) > -14552880 1
input data ('e' ends) > 946684799 2
input data ('e' ends) > e

2 ++-+--+-+-+-+--+-+-+-+--+-+-+-+--+-+-+--+-+-+-+--+-+-+-+--+-+-+-+--++A
|+ + + + + + + '-' using 1:2 + A +
| |
| |
1.8 ++ ++
| |
| |
| |
1.6 ++ ++
| |
| |
1.4 ++ ++
| |
| |
| |
1.2 ++ ++
| |
| |
|+ + + + + + + + + + +
1 A+-+--+-+-+-+--+-+-+-+--+-+-+-+--+-+-+--+-+-+-+--+-+-+-+--+-+-+-+--+++
01/01/197001/197301/19761/197901/198201/198501/198801/19911/199401/19971/2000

gnuplot> unset xrange
gnuplot> plot ["-14552880":"946684799"] '-' using 1:2 with points
input data ('e' ends) > -14552880 1
input data ('e' ends) > 946684799 2
input data ('e' ends) > e

2 ++-+--+-+-+-+--+-+-+-+--+-+-+-+--+-+-+--+-+-+-+--+-+-+-+--+-+-+-+--++A
|+ + + + + + + '-' using 1:2 + A +
| |
| |
1.8 ++ ++
| |
| |
| |
1.6 ++ ++
| |
| |
1.4 ++ ++
| |
| |
| |
1.2 ++ ++
| |
| |
|+ + + + + + + + + + +
1 A+-+--+-+-+-+--+-+-+-+--+-+-+-+--+-+-+--+-+-+-+--+-+-+-+--+-+-+-+--+++
01/01/197001/197301/19761/197901/198201/198501/198801/19911/199401/19971/2000

gnuplot>

Discussion

  • Ethan Merritt
    Ethan Merritt
    2012-10-11

    Here is what seems to be happening. I do not know how best to fix it.

    Time is specified externally relative to the unix epoch. But gnuplot internally tracks time relative to 1-Jan-2000. I do not know why, nor do I know what would break if we were to change that. Anyhow, when you read in time data from a file it is converted from the external convention to the internal convention by subtracting SEC_OFFS_SYS = 946684800.0 = seconds between 1970 and 2000. When time coordinates are output as labels, they are converted back from gnuplot time-coords to clock time. Internal system is mostly hidden from the user, but if you type "show xrange" after your first auto-ranged plot you will see:

    gnuplot> show xrange
    set xrange [ * : * ] noreverse nowriteback # (currently ["-1041400800":"0"] )

    The values shown as "currently" are a glimpse at the internal coordinates.

    The problem comes when you set a specific axis range in seconds. If the range were specified as clock time-of-day then the disparity between internal and external second-counts would be hidden. But if you specify the range in seconds, it cannot be hidden. As it is, the limits in seconds are used as given, but this reveals the mismatch between the externally specified seconds-relative-to-1970 and the internally stored seconds-relative-to-2000.

    One option is to convert the limits to internal coordinates at the time they are given in the "set range" command. This will (I think) produce the expected plots. But it will have the strange side-effect that "show xrange" will not report the same numbers you gave in "set xrange". I don't know what effect it would have on things like zooming, axis range writeback, etc.

    Perhaps the above approach could be modified by adding code to have the save/show range commands convert back before printing any ranges. That might work, but I have not tried it and again I don't know if there would be side effects.

    A more drastic option is to do away with the separate internal coordinate system. I have no idea what havoc that might cause, as I don't even know why it was chosen in the first place.

    A third option is to modify all range checks so that they are aware of the relevant offset. This is unfortunately very invasive and would at least potentially slow down processing of all plots whether or not they use time data.

    I am largely unfamiliar with the time code in gnuplot since I don't use it myself. So I am reluctant to choose between the above options and anyhow there may be a better fix that I haven't even thought of.

     
  • Ethan Merritt
    Ethan Merritt
    2013-04-08

    • status: open --> closed-out-of-date
    • milestone: --> 5.0
     
  • Ethan Merritt
    Ethan Merritt
    2013-04-08

    The time code in 4.7 has now been changed to use the standard unix epoch date. I hope this change fixes more things than it breaks.