Menu
▾
▴
gnuplot-beta
|
From: Dima K. <gn...@di...> - 2013-04-03 09:57:11
|
I'm attaching another patch. This one adds support to the "reverse" ranges setting for replots of volatile data. This is similar to the previous ranging fixes, where the setting was respected for the original plot, but ignored for replots. I'm also including the test cases I used to validate this. For all the test cases, I made sure that both the original plot and a replot looked good. Lastly, I'm really not at ease with these patches. Currently there are separate code paths for volatile and from-a-file data; these paths get out of sync, and issues such as this arise. I'm assuming that where reading data from files gnuplot can (and does) take multiple passes through the data, which is impossible when reading a pipe. Does anybody know why multiple passes are made? Is it a major undertaking to reduce this to a single pass, so that all data becomes "volatile" and we can get rid of the multiple code paths? dima |
|
From: Ethan M. <merritt@u.washington.edu> - 2013-04-03 15:41:24
|
On Wednesday, 03 April 2013, Dima Kogan wrote:
> I'm attaching another patch. This one adds support to the "reverse"
> ranges setting for replots of volatile data. This is similar to the
> previous ranging fixes, where the setting was respected for the original
> plot, but ignored for replots.
I'll test the patch, but I fear it may break zoom/unzoom.
> Does anybody know why multiple passes are made?
The volatile path can only handle the simple case of un-transformed data.
This case is common enough to be useful, but it cannot substitute for the
general case treatment.
Consider:
f(x) = 2*x
plot 'silver.dat' using (f($1)):2
f(x) = x/2.
refresh # redraws the original plot even though f(x) has changed
replot # draw a new plot using the new f(x)
The fundamental problem is that gnuplot does not store the original
data values internally. It only stores the transformed coordinates used
in the plot. This is particularly annoying in the case of log-scaled axes,
where the log scaling is applied to the data when it is read in rather
than when it is plotted. So log scaling interferes with the volatile
data path.
> Is it a major undertaking to reduce this to a single pass, so that all data
> becomes "volatile" and we can get rid of the multiple code paths?
Yes. You would have to change it so that the original data values are
stored internally so that they can be reused without rereading from
the input file. That basically isn't possible.
Consider
plot "data" using 1: (sum [i=2:100] f(column(i)))
In order to reevaluate this after possibly redefining f() you would
have to store 100 columns of data internally. As it is now, they
are processed on input and only the resulting sum is stored.
Nevertheless, I have long wanted to do away with the log-scaled axis
code. Having to log/unlog the data every time you access the
stored values complicates the code throughout the plotting routines.
I would much rather get rid of all that extra code and apply the
log-scale transformation at the time the data is plotted.
The "set link" command added in 4.7 was designed to take us halfway
to this goal. The "link" code attaches a scaling function to the axis,
which could in this case be log(). The problem is that there is
a complicated bit of code that generates log-scale tick positions as
a special case, and it's not obvious to me how to replace this
transparently. On the other hand the existing log-scale tick mark
code has been buggy for 20 years or so; the oldest open bug still
being tracked is "short log axes get bad autotics", added when the
SourceForge tracker was started in 2000. So maybe throwing it out
and starting over wouldn't be a bad idea anyhow.
Ethan
>
> I'm also including the test cases I used to validate this. For all the
> test cases, I made sure that both the original plot and a replot looked
> good.
>
> Lastly, I'm really not at ease with these patches. Currently there are
> separate code paths for volatile and from-a-file data; these paths get
> out of sync, and issues such as this arise. I'm assuming that where
> reading data from files gnuplot can (and does) take multiple passes
> through the data, which is impossible when reading a pipe.
>
> dima
>
>
|
|
From: Ethan M. <merritt@u.washington.edu> - 2013-04-03 16:51:37
|
On Wednesday, April 03, 2013 02:57:01 am Dima Kogan wrote: > I'm attaching another patch. This one adds support to the "reverse" > ranges setting for replots of volatile data. This is similar to the > previous ranging fixes, where the setting was respected for the original > plot, but ignored for replots. > > I'm also including the test cases I used to validate this. For all the > test cases, I made sure that both the original plot and a replot looked > good. I'm not seeing any difference between the patched and the unpatched behavior. Could you give me a specific set of instructions to test, inclding any mouse or replot/refresh commands? Both the patched and unpatched code versions lose track of the "reverse" setting after an unzoom operation using the "u" hotkey. Ethan > > Lastly, I'm really not at ease with these patches. Currently there are > separate code paths for volatile and from-a-file data; these paths get > out of sync, and issues such as this arise. I'm assuming that where > reading data from files gnuplot can (and does) take multiple passes > through the data, which is impossible when reading a pipe. Does anybody > know why multiple passes are made? Is it a major undertaking to reduce > this to a single pass, so that all data becomes "volatile" and we can > get rid of the multiple code paths? > > dima > > -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742 |
|
From: Dima K. <gn...@di...> - 2013-04-03 19:46:34
|
Ethan Merritt <merritt@u.washington.edu> writes:
> On Wednesday, April 03, 2013 02:57:01 am Dima Kogan wrote:
>> I'm attaching another patch. This one adds support to the "reverse"
>> ranges setting for replots of volatile data. This is similar to the
>> previous ranging fixes, where the setting was respected for the original
>> plot, but ignored for replots.
>>
>> I'm also including the test cases I used to validate this. For all the
>> test cases, I made sure that both the original plot and a replot looked
>> good.
>
> I'm not seeing any difference between the patched and the unpatched
> behavior. Could you give me a specific set of instructions to test,
> inclding any mouse or replot/refresh commands?
>
> Both the patched and unpatched code versions lose track of the "reverse"
> setting after an unzoom operation using the "u" hotkey.
That's odd. I just tried again with a clean checkout, and the patch
seems to work, both through replots ('e' key) and zoom/unzoom (mouse and
'u' key). The tree I'm looking at has both of the patches I sent
yesterday, so the last few commits are titled
document use of "smooth frequency" to generate and plot a histogram
Allow level 1 PostScript interpreters to skip large (>64kB) embedded images
x11 terminal: corrected some sizing inconsistencies
volatile-data plots now handle 'reversed' ranges during replots
After the tree is checked out, I do
export GNUPLOT_DRIVER_DIR=$PWD/src
./prepare && ./configure && make -j2 && src/gnuplot
Then inside gnuplot, I load one of the testcases
load "/tmp/testcases/reverse_keywordspec.gp"
Then I press 'e' to replot, do some zooming with the mouse, and press
'u' to unzoom. The right answer is a downward sloping line (reversed y
axis). I see this even through 'e' and zoom/'u'. Before the attached
patch only the initial plot looked right.
dima
|
|
From: Ethan M. <merritt@u.washington.edu> - 2013-04-04 20:32:31
|
On Wednesday, April 03, 2013 12:46:23 pm Dima Kogan wrote:
> Ethan Merritt <merritt@u.washington.edu> writes:
>
> > On Wednesday, April 03, 2013 02:57:01 am Dima Kogan wrote:
> >> I'm attaching another patch. This one adds support to the "reverse"
> >> ranges setting for replots of volatile data. This is similar to the
> >> previous ranging fixes, where the setting was respected for the original
> >> plot, but ignored for replots.
> >>
> >> I'm also including the test cases I used to validate this. For all the
> >> test cases, I made sure that both the original plot and a replot looked
> >> good.
> >
> > I'm not seeing any difference between the patched and the unpatched
> > behavior. Could you give me a specific set of instructions to test,
> > inclding any mouse or replot/refresh commands?
> >
> > Both the patched and unpatched code versions lose track of the "reverse"
> > setting after an unzoom operation using the "u" hotkey.
>
> That's odd. I just tried again with a clean checkout, and the patch
> seems to work, both through replots ('e' key) and zoom/unzoom (mouse and
> 'u' key).
I must have gotten confused as to what patches had been applied
to the version I was testing. It all looks good now that I have
started from a clean copy.
Ethan
> The tree I'm looking at has both of the patches I sent
> yesterday, so the last few commits are titled
>
> document use of "smooth frequency" to generate and plot a histogram
> Allow level 1 PostScript interpreters to skip large (>64kB) embedded images
> x11 terminal: corrected some sizing inconsistencies
> volatile-data plots now handle 'reversed' ranges during replots
>
> After the tree is checked out, I do
>
> export GNUPLOT_DRIVER_DIR=$PWD/src
> ./prepare && ./configure && make -j2 && src/gnuplot
>
> Then inside gnuplot, I load one of the testcases
>
> load "/tmp/testcases/reverse_keywordspec.gp"
>
> Then I press 'e' to replot, do some zooming with the mouse, and press
> 'u' to unzoom. The right answer is a downward sloping line (reversed y
> axis). I see this even through 'e' and zoom/'u'. Before the attached
> patch only the initial plot looked right.
>
> dima
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
--
Ethan A Merritt
Biomolecular Structure Center, K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742
|
