You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
(22) |
May
(52) |
Jun
(43) |
Jul
(36) |
Aug
(59) |
Sep
(37) |
Oct
(55) |
Nov
(39) |
Dec
(36) |
| 2005 |
Jan
(64) |
Feb
(40) |
Mar
(62) |
Apr
(58) |
May
(256) |
Jun
(77) |
Jul
(80) |
Aug
(39) |
Sep
(56) |
Oct
(36) |
Nov
(113) |
Dec
(68) |
| 2006 |
Jan
(43) |
Feb
(64) |
Mar
(69) |
Apr
(60) |
May
(71) |
Jun
(53) |
Jul
(63) |
Aug
(63) |
Sep
(76) |
Oct
(85) |
Nov
(82) |
Dec
(73) |
| 2007 |
Jan
(75) |
Feb
(82) |
Mar
(84) |
Apr
(104) |
May
(67) |
Jun
(101) |
Jul
(107) |
Aug
(138) |
Sep
(128) |
Oct
(106) |
Nov
(112) |
Dec
(112) |
| 2008 |
Jan
(94) |
Feb
(87) |
Mar
(146) |
Apr
(169) |
May
(75) |
Jun
(26) |
Jul
(26) |
Aug
(7) |
Sep
(18) |
Oct
(53) |
Nov
(42) |
Dec
(19) |
| 2009 |
Jan
(43) |
Feb
(39) |
Mar
(18) |
Apr
(45) |
May
(66) |
Jun
(87) |
Jul
(56) |
Aug
(41) |
Sep
(56) |
Oct
(139) |
Nov
(98) |
Dec
(88) |
| 2010 |
Jan
(81) |
Feb
(79) |
Mar
(83) |
Apr
(97) |
May
(124) |
Jun
(84) |
Jul
(53) |
Aug
(85) |
Sep
(89) |
Oct
(50) |
Nov
(98) |
Dec
(78) |
| 2011 |
Jan
(97) |
Feb
(74) |
Mar
(68) |
Apr
(54) |
May
(63) |
Jun
(59) |
Jul
(65) |
Aug
(58) |
Sep
(37) |
Oct
(40) |
Nov
(59) |
Dec
(35) |
| 2012 |
Jan
(16) |
Feb
(56) |
Mar
(63) |
Apr
(25) |
May
(48) |
Jun
(58) |
Jul
(20) |
Aug
(13) |
Sep
(43) |
Oct
(35) |
Nov
(20) |
Dec
(17) |
| 2013 |
Jan
(22) |
Feb
(11) |
Mar
(51) |
Apr
(34) |
May
(57) |
Jun
(27) |
Jul
(70) |
Aug
(30) |
Sep
(38) |
Oct
(53) |
Nov
(40) |
Dec
(25) |
| 2014 |
Jan
(26) |
Feb
(35) |
Mar
(60) |
Apr
(12) |
May
(17) |
Jun
(15) |
Jul
(9) |
Aug
(18) |
Sep
(46) |
Oct
(18) |
Nov
(19) |
Dec
(15) |
| 2015 |
Jan
(17) |
Feb
(28) |
Mar
(21) |
Apr
(54) |
May
(36) |
Jun
(8) |
Jul
(30) |
Aug
(13) |
Sep
(3) |
Oct
(28) |
Nov
(3) |
Dec
(3) |
| 2016 |
Jan
(11) |
Feb
(9) |
Mar
(29) |
Apr
(10) |
May
(8) |
Jun
(5) |
Jul
(50) |
Aug
(57) |
Sep
(13) |
Oct
(5) |
Nov
(17) |
Dec
(11) |
| 2017 |
Jan
(3) |
Feb
(23) |
Mar
(16) |
Apr
(7) |
May
(15) |
Jun
(12) |
Jul
(48) |
Aug
(15) |
Sep
(3) |
Oct
(20) |
Nov
(28) |
Dec
(21) |
| 2018 |
Jan
(13) |
Feb
(21) |
Mar
(21) |
Apr
(7) |
May
(3) |
Jun
(7) |
Jul
(27) |
Aug
(38) |
Sep
(4) |
Oct
(30) |
Nov
(22) |
Dec
|
| 2019 |
Jan
(5) |
Feb
(16) |
Mar
(1) |
Apr
(9) |
May
(7) |
Jun
(20) |
Jul
(13) |
Aug
(3) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
(4) |
| 2020 |
Jan
(6) |
Feb
(11) |
Mar
(1) |
Apr
(18) |
May
(4) |
Jun
(5) |
Jul
(12) |
Aug
(1) |
Sep
(3) |
Oct
(7) |
Nov
(1) |
Dec
(17) |
| 2021 |
Jan
(1) |
Feb
(11) |
Mar
(16) |
Apr
(6) |
May
(5) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(4) |
| 2022 |
Jan
(9) |
Feb
(35) |
Mar
(4) |
Apr
|
May
(3) |
Jun
(49) |
Jul
(11) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
(16) |
Dec
(13) |
| 2023 |
Jan
|
Feb
(8) |
Mar
(3) |
Apr
|
May
(8) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
| 2024 |
Jan
(6) |
Feb
(9) |
Mar
|
Apr
(26) |
May
(24) |
Jun
|
Jul
(4) |
Aug
(2) |
Sep
(1) |
Oct
(10) |
Nov
(9) |
Dec
|
| 2025 |
Jan
|
Feb
(22) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2026 |
Jan
|
Feb
(24) |
Mar
(20) |
Apr
(18) |
May
(2) |
Jun
(2) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: theozh <th...@gm...> - 2017-10-28 23:01:12
|
Thank you again, Ethan, for the explanations and links. What's still not clear to me why you can place the ysum=0 between two plot commands... What else can you place in front of a plot command? For example: n=1 plot n=n+1 sin(x*n) # works plot (n=1,n=n+1) sin(x*n) # doesn't work... why? Anyway, my original question is solved :-). Nevertheless, I played around a little further. If the portions in the stacked histogram are too small to fit a number, the following code shows a way to place those numbers on the side with a pointing arrow. Maybe some people also mind find this useful. The following code was working on my system (Win7, gnuplot 5.2) and should be ready for copy&paste&plot. Be aware that the mail program might have "messed up" the line breaks. ###### start gnuplot code reset $Data <<EOD XXX Header1 Header2 one 10 50 two 3 2 three 30 15 four 40 5 five 0.5 0.5 six 0.6 0.6 seven 1 17 EOD set style data histogram set style histogram columnstacked set style fill solid border -1 set boxwidth 0.6 YminSpace = 4 YStep = 2 YExtraDistance = -YStep XShift(n) = (n < YminSpace) ? 0.45 : 0 YShift(n) = (n < YminSpace) ? (YExtraDistance=YExtraDistance+YStep,YExtraDistance) : (YExtraDistance=-YStep,0) plot \ $Data u 2 ti col , '' u 3:key(1) ti col, \ ysum=0 '' skip 1 using (0+XShift($2)):((ysum = ysum + $2, ysum-$2/2+YShift($2))):2 with labels notitle, \ ysum=0 '' skip 1 using (1+XShift($3)):((ysum = ysum + $3, ysum-$3/2+YShift($3))):3 with labels notitle,\ ysum=0 '' skip 1 using ($2>YminSpace ? 1/0:(0+XShift($2)-0.05)):((ysum = ysum + $2, ysum-$2/2+YShift($2))):(-0.1):(-YExtraDistance) ls -1 with vectors not,\ ysum=0 '' skip 1 using ($3>YminSpace ? 1/0:(1+XShift($3)-0.05)):((ysum = ysum + $3, ysum-$3/2+YShift($3))):(-0.1):(-YExtraDistance) ls -1 with vectors not,\ ###### end gnuplot code |
|
From: sfeam <sf...@us...> - 2017-10-28 16:31:18
|
On Saturday, 28 October 2017 10:23:40 theozh wrote:
> Thanks a lot Ethan,
> I'll never would have found this one.
> With the minor change "ysum-$2/2", the following seems to place the
> number in the center of the portion.
>
> plot $Data u 2 ti col , '' u 3:key(1) ti col, \
> ysum=0 '' skip 1 using (0):((ysum = ysum + $2, ysum-$2/2)):2 with
> labels notitle, \
> ysum=0 '' skip 1 using (1):((ysum = ysum + $3, ysum-$3/2)):3 with
> labels notitle
>
> However, if looking at the syntax in "help plot"
> plot-element:
> {<iteration>}
> <definition> | {sampling-range} <function> | <data source>
> {axes <axes>} {<title-spec>}
> {with <style>}
>
> I still don't understand why and how ((ysum = ysum + $2, ysum-$2/2))
> works.
The comma is a mathematical binary operator indicating
serial evaluation. The operation
A,B
signifies "first evaluate A, then evaluate B, return the latter result"
https://en.wikipedia.org/wiki/Comma_operator
> So apparently, you can place an expression/function before the
> comma and the expression after the comma is actually plotted? Good to
> know, I didn't know that one can make such constructs. Would be nice to
> have an example in "plot help" or if you have a link where to find this
> documented, please let me know.
gnuplot> help expression operators binary
(4th from last in the long list of operators)
Serial evaluation occurs only in parentheses and is guaranteed to proceed
in left to right order. The value of the rightmost subexpression is returned.
For a demo the makes good use of this operator see
http://gnuplot.sourceforge.net/demo_cvs/running_avg.html
Ethan
|
|
From: theozh <th...@gm...> - 2017-10-28 08:24:05
|
Thanks a lot Ethan,
I'll never would have found this one.
With the minor change "ysum-$2/2", the following seems to place the
number in the center of the portion.
plot $Data u 2 ti col , '' u 3:key(1) ti col, \
ysum=0 '' skip 1 using (0):((ysum = ysum + $2, ysum-$2/2)):2 with
labels notitle, \
ysum=0 '' skip 1 using (1):((ysum = ysum + $3, ysum-$3/2)):3 with
labels notitle
However, if looking at the syntax in "help plot"
plot-element:
{<iteration>}
<definition> | {sampling-range} <function> | <data source>
{axes <axes>} {<title-spec>}
{with <style>}
I still don't understand why and how ((ysum = ysum + $2, ysum-$2/2))
works. So apparently, you can place an expression/function before the
comma and the expression after the comma is actually plotted? Good to
know, I didn't know that one can make such constructs. Would be nice to
have an example in "plot help" or if you have a link where to find this
documented, please let me know.
|
|
From: Ethan M. <eam...@gm...> - 2017-10-27 22:50:58
|
This could maybe serve as a starting point. The placement is not pretty
but it shows the basic principle.
plot $Data u 2 ti col , '' u 3:key(1) ti col, \
ysum=0 '' skip 1 using (0):((ysum = ysum + $2, ysum-5)):2 with labels
notitle, \
ysum=0 '' skip 1 using (1):((ysum = ysum + $3, ysum-5)):3 with labels
notitle
On Fri, Oct 27, 2017 at 2:24 PM, theozh <th...@gm...> wrote:
> Hi,
> Is there maybe a simple way to place the values on top of
> in a column stacked histogram?
> The following example does not place the labels at the right
> y-positions, i.e. ideally centered within the different portions.
> For this you would need to somehow sum up the previous values. I do not
> see how...
> Any hints are appreciated!
> Theo.
>
> ###### gnuplot code start
> reset
> $Data <<EOD
> XXX Header1 Header2
> one 10 50
> two 20 30
> three 30 15
> four 40 5
> EOD
>
> set style data histogram
> set style histogram columnstacked
> set style fill solid border -1
> set boxwidth 0.75
>
> plot $Data u 2 ti col , '' u 3:key(1) ti col, \
> '' u (0):2:2 with labels notitle, '' u (1):3:2 with labels notitle
>
> ###### gnuplot code end
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/
> lists/listinfo/gnuplot-info
>
|
|
From: theozh <th...@gm...> - 2017-10-27 21:25:13
|
Hi,
Is there maybe a simple way to place the values on top of
in a column stacked histogram?
The following example does not place the labels at the right
y-positions, i.e. ideally centered within the different portions.
For this you would need to somehow sum up the previous values. I do not
see how...
Any hints are appreciated!
Theo.
###### gnuplot code start
reset
$Data <<EOD
XXX Header1 Header2
one 10 50
two 20 30
three 30 15
four 40 5
EOD
set style data histogram
set style histogram columnstacked
set style fill solid border -1
set boxwidth 0.75
plot $Data u 2 ti col , '' u 3:key(1) ti col, \
'' u (0):2:2 with labels notitle, '' u (1):3:2 with labels notitle
###### gnuplot code end
|
|
From: David K. <da...@gn...> - 2017-10-22 14:01:28
|
Because of the current epslatex terminal's inability to draw dashed line
patterns in contours, I am in trouble.
Issue 1612 would indicate that temporarily saving contours to data may
help, but that apparently is only feasible when using the data with plot
(and thus a rectangular projection) rather than splot: for the following
fragment
set table $blobs
splot [-pi:pi][-3:3] 2*pi*Vm0m1(1,-1,0,pi/4,x,y) title "$2\\pi V_{1,-1}^{(0,\\pi/4)}(\\theta,p)$" nosurface
unset table
splot [-pi:pi][-3:3] 2*pi*Vm0m1(1,-1,0,pi/4,x,y) title "$2\\pi V_{1,-1}^{(0,\\pi/4)}(\\theta,p)$" nocontours, $blobs nosurface
I get
splot [-pi:pi][-3:3] 2*pi*Vm0m1(1,-1,0,pi/4,x,y) title "$2\\pi V_{1,-1}^{(0,\\pi/4)}(\\theta,p)$" nocontours, $blobs nosurface
^
"wigner4.gp", line 190: 2 columns only possible with explicit pm3d style (line 8)
Is there any expedient for reattaching exported contours into a full
splot command, allowing me to root around the current dash pattern
initialization bug?
--
David Kastrup
|
|
From: David K. <da...@gn...> - 2017-10-19 09:07:19
|
David Kastrup <da...@gn...> writes: > Ethan Merritt <eam...@gm...> writes: > My expectation is colored by current documentation that is supposed to > reflect the change from 4.x to 5.x. It is not like I didn't quote it. > As it is, Gnuplot is useless for creating monochrome surface plots with > contours because all contour lines will look the same. This wasn't the > case in Gnuplot 4.x, and the documented replacement for versions >= 5.0 > does not work. And this was already noted in <https://sourceforge.net/p/gnuplot/bugs/1612/#d961> in 2015 after which the containing issue was closed without further comment. There may be a backstory I am not aware of, but the resulting discrepancy between documentation and code is not telling it. -- David Kastrup |
|
From: David K. <da...@gn...> - 2017-10-18 07:26:47
|
Ethan A Merritt <eam...@gm...> writes: > On Tuesday, 17 October 2017 15:13:49 Ethan Merritt wrote: >> You are now, as I understand it, advocating that both the linewidth and dashtype >> properties should act as the linecolor does. I'm fine with adding that as >> a user-specified option, but it would be something new rather than a return to >> what any previous gnuplot version did. > > > It occurs to me that if we do add something of this sort, > it might be more usable to assign the linewidth or dashpattern > directly to a series of contour levels rather than indirectly by > counting out linetypes and tryiing to figure out which level is > going to get which linetype. > > Something like we already do with axis tic labels > > set cntrlabel onecolor > set cntrparam level discrete 0 dashtype '..' > set cntrparam level add incremental 10, 10 linewidth 2 > set cntrparam level add incremental 2, 10 linewidth 0.5 > set cntrparam level add incremental 4, 10 linewidth 0.5 > set cntrparam level add incremental 6, 10 linewidth 0.5 > set cntrparam level add incremental 8, 10 linewidth 0.5 > > That would get you a dotted contour at 0, heavy lines every 10, > and thin lines every 2 otherwise. All the same color in this case. > > Thoughts? Mostly useless for linetypes displayed in a key. Both plot types and contour line labels are usually listed in a key, so it does not make a lot of sense to treat them differently in that respect. -- David Kastrup |
|
From: David K. <da...@gn...> - 2017-10-18 07:24:17
|
Ethan Merritt <eam...@gm...> writes:
> On Tue, Oct 17, 2017 at 6:38 AM, David Kastrup <da...@gn...> wrote:
>
>> Ethan A Merritt <eam...@gm...> writes:
>>
>> > On Sunday, 15 October 2017 10:53:08 Ethan A Merritt wrote:
>> >> On Sunday, 15 October 2017 13:06:50 David Kastrup wrote:
>> >> >
>> >> > So I now tried compiling 5.2.0.
>> >> >
>> >> > No change in the epslatex terminal: it would appear that _only_ the
>> >> > linewidth and the dash pattern for linestyle 1 are ever consulted and
>> >> > are used for _all_ lines. Linecolor can be changed per line style,
>> but
>> >> > pretty much nothing else.
>> >>
>> >> Correct. It steps through sequential line colors.
>> >>
>> >> > Anybody have a good idea for where to patch this up?
>> >>
>> >> The following 1-line change might or might not produce acceptable
>> >> results for you. One problem is that the line segments making up
>> >> a contour are not necessarily drawn in order and some terminals
>> >> reset the dash pattern for each segment, leading to mostly solid
>> >> or mostly missing lines rather than the desired dash pattern.
>> >> For other terminal types this doesn't seem to be a problem.
>> >>
>> >> If this does work for you please report back.
>> >> We could make it an optional setting of some sort.
>>
>> I don't think following the documentation is "optional".
>>
>> [snip]
>
> I think I understand what you are expecting from the program, but honestly
> it has never worked that way.
Shrug. Of course not: dash types as part of line style were a 5.0
thing. Before one used
set terminal epslatex dashed
but dashed is now ignored, and the _documented_ replacement one is
supposed to be using does not work. And now you state it shouldn't
work, documentation be damned. But in a monochrome print, having all
contour lines look the same is not an option.
> You are now, as I understand it, advocating that both the linewidth
> and dashtype properties should act as the linecolor does. I'm fine
> with adding that as a user-specified option, but it would be something
> new rather than a return to what any previous gnuplot version did.
Look, this isn't fun.
help dash
clearly states:
gnuplot> help dash
In gnuplot version 5 the dash pattern (`dashtype`) is a separate property
associated with each line, analogous to `linecolor` or `linewidth`. It is not
necessary to place the current terminal in a special mode just to draw dashed
lines. I.e. the command `set term <termname> {solid|dashed}` is now ignored.
If backwards compatibility with old scripts written for version 4 is required,
the following lines can be used instead:
if (GPVAL_VERSION >= 5.0) set for [i=1:9] linetype i dashtype i
if (GPVAL_VERSION < 5.0) set termoption dashed
So _of_ _course_ this worked differently before version 5.0. The
problem is that it _worked_. Now it doesn't work at all. There is
absolutely no more way to get differently dashed contours in a
monochrome terminal since the documented replacement does not work, and
you state that you think it should be an optional feature to have it
work.
> Note: Your expectation may be colored by past behaviour of the
> postscript terminal driver.
My expectation is colored by current documentation that is supposed to
reflect the change from 4.x to 5.x. It is not like I didn't quote it.
As it is, Gnuplot is useless for creating monochrome surface plots with
contours because all contour lines will look the same. This wasn't the
case in Gnuplot 4.x, and the documented replacement for versions >= 5.0
does not work.
--
David Kastrup
|
|
From: Ethan A M. <eam...@gm...> - 2017-10-18 04:22:35
|
On Tuesday, 17 October 2017 15:13:49 Ethan Merritt wrote: > You are now, as I understand it, advocating that both the linewidth and dashtype > properties should act as the linecolor does. I'm fine with adding that as > a user-specified option, but it would be something new rather than a return to > what any previous gnuplot version did. It occurs to me that if we do add something of this sort, it might be more usable to assign the linewidth or dashpattern directly to a series of contour levels rather than indirectly by counting out linetypes and tryiing to figure out which level is going to get which linetype. Something like we already do with axis tic labels set cntrlabel onecolor set cntrparam level discrete 0 dashtype '..' set cntrparam level add incremental 10, 10 linewidth 2 set cntrparam level add incremental 2, 10 linewidth 0.5 set cntrparam level add incremental 4, 10 linewidth 0.5 set cntrparam level add incremental 6, 10 linewidth 0.5 set cntrparam level add incremental 8, 10 linewidth 0.5 That would get you a dotted contour at 0, heavy lines every 10, and thin lines every 2 otherwise. All the same color in this case. Thoughts? Ethan |
|
From: Ethan M. <eam...@gm...> - 2017-10-17 22:13:56
|
On Tue, Oct 17, 2017 at 6:38 AM, David Kastrup <da...@gn...> wrote: > Ethan A Merritt <eam...@gm...> writes: > > > On Sunday, 15 October 2017 10:53:08 Ethan A Merritt wrote: > >> On Sunday, 15 October 2017 13:06:50 David Kastrup wrote: > >> > > >> > So I now tried compiling 5.2.0. > >> > > >> > No change in the epslatex terminal: it would appear that _only_ the > >> > linewidth and the dash pattern for linestyle 1 are ever consulted and > >> > are used for _all_ lines. Linecolor can be changed per line style, > but > >> > pretty much nothing else. > >> > >> Correct. It steps through sequential line colors. > >> > >> > Anybody have a good idea for where to patch this up? > >> > >> The following 1-line change might or might not produce acceptable > >> results for you. One problem is that the line segments making up > >> a contour are not necessarily drawn in order and some terminals > >> reset the dash pattern for each segment, leading to mostly solid > >> or mostly missing lines rather than the desired dash pattern. > >> For other terminal types this doesn't seem to be a problem. > >> > >> If this does work for you please report back. > >> We could make it an optional setting of some sort. > > I don't think following the documentation is "optional". > > [snip] I think I understand what you are expecting from the program, but honestly it has never worked that way. Prior to gnuplot version 5 linetypes did not include a "dashtype" property, so the question of applying or not applying it to draw contours was moot. Linetypes did have a "linewidth" property of course, but just as now only one linewidth was used for all the contours in a plot. I've gone back and confirmed that for versions 4.4 and 4.6. When gnuplot version 5 introduced dashtypes, we had to choose whether for the purposes of drawing contours they would follow the example of the linecolor property (increment for each contour level) or linewidth property (same for the entire plot). There was no strong advocacy either way and we ended up choosing to treat it as analogous to linewidth. You are now, as I understand it, advocating that both the linewidth and dashtype properties should act as the linecolor does. I'm fine with adding that as a user-specified option, but it would be something new rather than a return to what any previous gnuplot version did. Note: Your expectation may be colored by past behaviour of the postscript terminal driver. Prior to gnuplot version 5 the postscript terminal acted differently from all other terminal types. One of the goals set for version 5 was to get all terminals to behave as consistently as possible, even at the cost of losing exact backwards compatibility. Normally backwards compatibility has the highest priority, so the 4->5 transition was highly unusual in that regard. |
|
From: David K. <da...@gn...> - 2017-10-17 13:39:17
|
Ethan A Merritt <eam...@gm...> writes:
> On Sunday, 15 October 2017 10:53:08 Ethan A Merritt wrote:
>> On Sunday, 15 October 2017 13:06:50 David Kastrup wrote:
>> >
>> > So I now tried compiling 5.2.0.
>> >
>> > No change in the epslatex terminal: it would appear that _only_ the
>> > linewidth and the dash pattern for linestyle 1 are ever consulted and
>> > are used for _all_ lines. Linecolor can be changed per line style, but
>> > pretty much nothing else.
>>
>> Correct. It steps through sequential line colors.
>>
>> > Anybody have a good idea for where to patch this up?
>>
>> The following 1-line change might or might not produce acceptable
>> results for you. One problem is that the line segments making up
>> a contour are not necessarily drawn in order and some terminals
>> reset the dash pattern for each segment, leading to mostly solid
>> or mostly missing lines rather than the desired dash pattern.
>> For other terminal types this doesn't seem to be a problem.
>>
>> If this does work for you please report back.
>> We could make it an optional setting of some sort.
I don't think following the documentation is "optional".
>From help set cntrlabel:
A contour label is placed in the plot key for each linetype used. By default
each contour level is given its own linetype, so a separate label appears for
each. The command `set cntrlabel onecolor` causes all contours to be drawn
using the same linetype, so only one label appears in the plot key.
This command replaces an older command `unset clabel`.
>From help set linetype:
The `set linetype` command allows you to redefine the basic linetypes used
for plots. The command options are identical to those for "set style line".
Unlike line styles, redefinitions by `set linetype` are persistent; they
are not affected by `reset`.
>From help set style line:
Each terminal has a default set of line and point types, which can be seen
by using the command `test`. `set style line` defines a set of line types
and widths and point types and sizes so that you can refer to them later by
an index instead of repeating all the information at each invocation.
Syntax:
set style line <index> default
set style line <index> {{linetype | lt} <line_type> | <colorspec>}
{{linecolor | lc} <colorspec>}
{{linewidth | lw} <line_width>}
{{pointtype | pt} <point_type>}
{{pointsize | ps} <point_size>}
{{pointinterval | pi} <interval>}
{{pointnumber | pn} <max_symbols>}
{{dashtype | dt} <dashtype>}
{palette}
unset style line
show style line
`default` sets all line style parameters to those of the linetype with
that same index.
>From help dashtype:
In gnuplot version 5 the dash pattern (`dashtype`) is a separate property
associated with each line, analogous to `linecolor` or `linewidth`. It is not
necessary to place the current terminal in a special mode just to draw dashed
lines. I.e. the command `set term <termname> {solid|dashed}` is now ignored.
If backwards compatibility with old scripts written for version 4 is required,
the following lines can be used instead:
if (GPVAL_VERSION >= 5.0) set for [i=1:9] linetype i dashtype i
if (GPVAL_VERSION < 5.0) set termoption dashed
All lines have the property `dashtype solid` unless you specify otherwise.
You can change the default for a particular linetype using the command
`set linetype` so that it affects all subsequent commands, or you can include
the desired dashtype as part of the `plot` or other command.
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%
>> --- gnuplot52/src/graph3d.c 2017-09-15 20:26:48.393406844 -0700
>> +++ test52/src/graph3d.c 2017-10-15 10:50:39.698779538 -0700
>> @@ -1265,6 +1265,8 @@ do_3dplot(
>> /* otherwise the following would be sufficient */
>> load_linetype(&ls, this_plot->hidden3d_top_linetype + ic);
>> }
>> +/* DEBUG */ /* increment dashtype also */
>> +/* DEBUG */ thiscontour_lp_properties.d_type = ic;
>
> probably better as
>
> +/* DEBUG */ thiscontour_lp_properties.d_type = ls.d_type;
I can now set individual dash types. The individual linewidths still do
not seem to get consulted for the contour lines: it seems like the
linewidth of line style 1 is applied everywhere.
--
David Kastrup
|
|
From: Ethan A M. <eam...@gm...> - 2017-10-16 05:00:50
|
On Sunday, 15 October 2017 10:53:08 Ethan A Merritt wrote: > On Sunday, 15 October 2017 13:06:50 David Kastrup wrote: > > > > So I now tried compiling 5.2.0. > > > > No change in the epslatex terminal: it would appear that _only_ the > > linewidth and the dash pattern for linestyle 1 are ever consulted and > > are used for _all_ lines. Linecolor can be changed per line style, but > > pretty much nothing else. > > Correct. It steps through sequential line colors. > > > Anybody have a good idea for where to patch this up? > > The following 1-line change might or might not produce acceptable > results for you. One problem is that the line segments making up > a contour are not necessarily drawn in order and some terminals > reset the dash pattern for each segment, leading to mostly solid > or mostly missing lines rather than the desired dash pattern. > For other terminal types this doesn't seem to be a problem. > > If this does work for you please report back. > We could make it an optional setting of some sort. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%% > --- gnuplot52/src/graph3d.c 2017-09-15 20:26:48.393406844 -0700 > +++ test52/src/graph3d.c 2017-10-15 10:50:39.698779538 -0700 > @@ -1265,6 +1265,8 @@ do_3dplot( > /* otherwise the following would be sufficient */ > load_linetype(&ls, this_plot->hidden3d_top_linetype + ic); > } > +/* DEBUG */ /* increment dashtype also */ > +/* DEBUG */ thiscontour_lp_properties.d_type = ic; probably better as +/* DEBUG */ thiscontour_lp_properties.d_type = ls.d_type; > thiscontour_lp_properties.pm3d_color = ls.pm3d_color; > term_apply_lp_properties(&thiscontour_lp_properties); > } > %%%%%%%%%%%%%%%%%%%%%%%%%%%% > > -- |
|
From: Ethan A M. <eam...@gm...> - 2017-10-15 17:53:17
|
On Sunday, 15 October 2017 13:06:50 David Kastrup wrote:
>
> So I now tried compiling 5.2.0.
>
> No change in the epslatex terminal: it would appear that _only_ the
> linewidth and the dash pattern for linestyle 1 are ever consulted and
> are used for _all_ lines. Linecolor can be changed per line style, but
> pretty much nothing else.
Correct. It steps through sequential line colors.
> Anybody have a good idea for where to patch this up?
The following 1-line change might or might not produce acceptable
results for you. One problem is that the line segments making up
a contour are not necessarily drawn in order and some terminals
reset the dash pattern for each segment, leading to mostly solid
or mostly missing lines rather than the desired dash pattern.
For other terminal types this doesn't seem to be a problem.
If this does work for you please report back.
We could make it an optional setting of some sort.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot52/src/graph3d.c 2017-09-15 20:26:48.393406844 -0700
+++ test52/src/graph3d.c 2017-10-15 10:50:39.698779538 -0700
@@ -1265,6 +1265,8 @@ do_3dplot(
/* otherwise the following would be sufficient */
load_linetype(&ls, this_plot->hidden3d_top_linetype + ic);
}
+/* DEBUG */ /* increment dashtype also */
+/* DEBUG */ thiscontour_lp_properties.d_type = ic;
thiscontour_lp_properties.pm3d_color = ls.pm3d_color;
term_apply_lp_properties(&thiscontour_lp_properties);
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
From: David K. <da...@gn...> - 2017-10-15 11:07:08
|
So I now tried compiling 5.2.0. No change in the epslatex terminal: it would appear that _only_ the linewidth and the dash pattern for linestyle 1 are ever consulted and are used for _all_ lines. Linecolor can be changed per line style, but pretty much nothing else. Anybody have a good idea for where to patch this up? -- David Kastrup |
|
From: David K. <da...@gn...> - 2017-10-11 19:52:47
|
David Kastrup <da...@gn...> writes: > On gnuplot 5.0.7 I am completely unable to get individually dashed > contours for the epslatex terminal: all contour lines take their color > from the individual line styles, but the dashing exclusively from line > style 1 (which I need for the main plot anyway, even if equally dashed > contour lines would not be pointless anyway). > > Here is my current file, I am out of my wits. I am pretty sure that > this is actually a bug, but I am under time pressure and would at least > need a workaround. Sigh, attachment scrubbed. Let's try again as text/plain attachment. I try explicitly to make linestyle 3 red and dotted, and try to give the other linestyles >= 2 the appropriate dashstyle. Red obviously works, dashing doesn't. |
|
From: David K. <da...@gn...> - 2017-10-11 19:38:52
|
On gnuplot 5.0.7 I am completely unable to get individually dashed contours for the epslatex terminal: all contour lines take their color from the individual line styles, but the dashing exclusively from line style 1 (which I need for the main plot anyway, even if equally dashed contour lines would not be pointless anyway). Here is my current file, I am out of my wits. I am pretty sure that this is actually a bug, but I am under time pressure and would at least need a workaround. |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-09-28 22:39:06
|
Am 28.09.2017 um 15:53 schrieb Cruzeiro,Vinicius Wilian D: > I am using gnuplot 5.2 and this script makes "almost" the graph I need (I am sending the xyz.tsv file attached): The attachment didn't make it past the mailing list processor, but that's no problem. The cause for the issue is clear enough already. > The only thing I would like to change now is to remove the lines > connecting the points for different values of x (for example, the > line between the 6th and the 7th points). You want to read "help splot data" and its "example" sub-section. |
|
From: Cruzeiro,Vinicius W. D <vwc...@uf...> - 2017-09-28 20:56:42
|
Dear all, I am using gnuplot 5.2 and this script makes "almost" the graph I need (I am sending the xyz.tsv file attached): set terminal svg enhanced set output 'output.svg' set key off set tics font "Helvetica,15" set xlabel "X axis" rotate parallel font "Helvetica,20" set ylabel "Y axis" rotate parallel font "Helvetica,20" set zlabel "Z axis" rotate parallel font "Helvetica,20" set cblabel "Fitting error\non Z" center rotate by 0 offset -8,7,0 font "Helvetica,17" splot 'xyz.tsv' using 1:2:3:4 with linespoints palette pointsize 2 pointtype 7 The only thing I would like to change now is to remove the lines connecting the points for different values of x (for example, the line between the 6th and the 7th points). In order to test a solution for that, I wrote a file that contains points for a single value of x (test.tsv, sending attached) and tried the following: set terminal svg enhanced set output 'output.svg' set key off set tics font "Helvetica,15" set xlabel "X axis" rotate parallel font "Helvetica,20" set ylabel "Y axis" rotate parallel font "Helvetica,20" set zlabel "Z axis" rotate parallel font "Helvetica,20" set cblabel "Fitting error\non Z" center rotate by 0 offset -8,7,0 font "Helvetica,17" splot 'test.tsv' using 1:2:3 with lines, 'xyz.tsv' using 1:2:3:4 with points palette pointsize 2 pointtype 7 The line appears on the way I want, however for some reason all the points become black! I am not sure if this is a bug in the program or if I am doing something wrong. Has anybody seen this problem before or has a better solution? Assuming there is a better/easier solution, having a way to make the same points but with the lines along the y axis (instead as along x as above) would be very helpful too. Thank you very much, Vinícius Wilian D Cruzeiro PhD Candidate Department of Chemistry, Physical Chemistry Division University of Florida, United States Voice: +1(352)846-1633 |
|
From: Nunzio L. <nun...@gm...> - 2017-09-13 13:41:11
|
In fact the suggested solution allows me to insert a second plot with its
origin at some exact coordinates x,y of the first graph. What I was looking
for, instead, is placing the origin of AXES of the second graph at some
(x,y) of the previous graph. I found a solution, although cumbersome. An
example is provided here:
first functions FRAC_X and FRAC_Y are defined to find the fraction of
screen coordinates corresponding to some coordinates x and y (which seem to
refer to the axes of the last plot) as suggested in the manual of version
5.2:
# ----------------- cut here ---------------- #
GRAPH_X(X) = (X - GPVAL_X_MIN) / (GPVAL_X_MAX - GPVAL_X_MIN)
GRAPH_Y(Y) = (Y - GPVAL_Y_MIN) / (GPVAL_Y_MAX - GPVAL_Y_MIN)
SCREEN_X(X) = GPVAL_TERM_XMIN + GRAPH_X(X) * (GPVAL_TERM_XMAX -
GPVAL_TERM_XMIN)
SCREEN_Y(Y) = GPVAL_TERM_YMIN + GRAPH_Y(Y) * (GPVAL_TERM_YMAX -
GPVAL_TERM_YMIN)
FRAC_X(X) = SCREEN_X(X) * GPVAL_TERM_SCALE / GPVAL_TERM_XSIZE
FRAC_Y(Y) = SCREEN_Y(Y) * GPVAL_TERM_SCALE / GPVAL_TERM_YSIZE
# ----------------- cut here ---------------- #
here comes the script
# ----------------- cut here ---------------- #
reset
set term qt size 600,400
set size ratio -1
set encoding iso_8859_1
unset key
set xrange [-30.:30.]
set yrange [35:0]
set y2range [9.5:-0.5]
set object 1 circle center -7.25,25 size 3.355
set object 2 circle center 7.25,25 size 3.355
set ylabel 'profondit{\340} [m]'
set xlabel "distanza [m]"
set y2label 'cedimento [mm]'
set y2tics ("0" 0)
set ytics nomirror
set xtics 10
set rmargin 7
set lmargin 7
set arrow 1 from graph 0., first 0. to graph 1., first 0. nohead
set arrow 2 from graph 0., first 9. to graph 1., first 9. nohead
set arrow 3 from graph 0., first 17. to graph 1., first 17. nohead
set multiplot
plot -50.
depths = "0.0 9.0 17.0"
Ox = FRAC_X(0.)
Oy = FRAC_Y(17.)
set size noratio
set size 1,0.3
set x2zeroaxis
set y2label 'cedimento [mm]'
set y2tics nomirror 2
unset arrow 1
unset arrow 2
unset arrow 3
unset xlabel
unset ylabel
unset ytics
unset xtics
unset xlabel
unset y2label
set tmargin 0
set bmargin 0
set border 8
unset object 1
unset object 2
plot for[i=3:3] 'dis-trans-z'.word(depths,3).'-y61.6_f120.4-odd.dat' u
1:(-$6*1000.) every 2 axes x1y2 w p ls 6 lc rgbcolor "black" not
Ox1 = FRAC_X(0.)
Oy1 = FRAC_Y(0.)
Ox2 = 0.0
Oy2 = Oy - Oy1
print Ox, Oy
print Ox1, Oy1
print Ox2, Oy2
set origin Ox2,Oy2 + 0.015
# why do I have to add 0.015 here???
plot for[i=3:3] 'dis-trans-z'.word(depths,3).'-y61.6_f120.4-odd.dat' u
1:(-$6*1000.) every 2 axes x1y2 w p ls 6 lc rgbcolor "green" not
unset multiplot
# ----------------- cut here ---------------- #
the dataset can be downloaded at:
https://www.dropbox.com/s/evrqlldb1q39uum/dis-trans-z17.0-y61.6_f120.4-odd.dat?dl=0
for testing.
What really puzzles me is why I have to add 0.015 to the new origin y
screen coordinate in order to get the correct alignment!!
(The xzeroaxis of the last plot must be aligned with the horizontal line at
y=17 of the first plot)
Thanks for your help
N
2017-06-22 23:05 GMT+02:00 Nunzio Losacco <nun...@gm...>:
> Great suggestion,
>
> Thanks a lot
>
> N
>
>
> Il 22 giu 2017 9:18 PM, "theozh" <th...@gm...> ha scritto:
>
>> as far as I understand, and it looks like that gnuplot does not allow
>> other than screen coordinates for offset in the multiplot environment.
>> Probably it's not clear which coordinates it should take: the first
>> ones, the previous ones...?
>>
>> Anyway, you could use the gnuplot internal variables GPVAL_...
>> "show var GPVAL"
>> With this you need to do some "little" coordinate transformations.
>> Maybe there is even a more elegant solution?
>>
>> The following code should do what you're looking for...
>> You can actually skip all the lines starting with "print..."
>>
>>
>> ### start gnuplot example code
>> reset
>>
>> # enter the coordinates of the origin of the second plot
>> # i.e. coordinates with respect to the first plot
>> XPos = -10
>> YPos = 0
>>
>> set multiplot
>>
>> # your first plot
>> plot x
>>
>> print "TermSize x,y: ", GPVAL_TERM_XSIZE, ", ", GPVAL_TERM_YSIZE
>> print "Term X: ", GPVAL_TERM_XMIN, " to ", GPVAL_TERM_XMAX
>> print "Term Y: ", GPVAL_TERM_YMIN, " to ", GPVAL_TERM_YMAX
>> print "Graph X: ", GPVAL_X_MIN, " to ", GPVAL_X_MAX
>> print "Graph Y: ", GPVAL_Y_MIN, " to ", GPVAL_Y_MAX
>>
>> XScaling = (GPVAL_TERM_XMAX - GPVAL_TERM_XMIN)/(GPVAL_X_MAX - GPVAL_X_MIN)
>> YScaling = (GPVAL_TERM_YMAX - GPVAL_TERM_YMIN)/(GPVAL_Y_MAX - GPVAL_Y_MIN)
>> print "Scaling x,y: ", XScaling, YScaling
>>
>> XMargin = GPVAL_TERM_XMIN/XScaling
>> YMargin = GPVAL_TERM_YMIN/YScaling
>> print "Margin x,y: ", XMargin, YMargin
>>
>> XOffset = (XPos - GPVAL_X_MIN + XMargin)*XScaling/GPVAL_TERM_XSIZE
>> YOffset = (YPos - GPVAL_Y_MIN + YMargin)*YScaling/GPVAL_TERM_YSIZE
>> print "XOffset x,y: ", XOffset, YOffset
>>
>> # your second plot, for example with reduced size
>> set size 0.4
>> set origin XOffset,YOffset
>> plot x*x
>>
>> unset multiplot
>>
>> ### end gnuplot code
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> gnuplot-info mailing list
>> gnu...@li...
>> Membership management via:
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-info
>>
>>
|
|
From: ivana r. <iva...@mf...> - 2017-08-15 05:52:48
|
Hi Ethan,
> I would instead suggest a scheme like
>
> gnuplot> array CityNames[25] =
>> ["Atlanta","Boston","Charleston","Dallas","Ephrata","Fargo",,,]
>> gnuplot> City(letter) = CityNames[
>> strstrt("abcdefghijklmnopqrstuvwxyz",letter) ]
>> gnuplot> print City("d")
>> Dallas
>> gnuplot>
the scheme looks great. I hope it will be postponed to demos. Thanks
for the tip!
Iva
|
|
From: Ethan M. <eam...@gm...> - 2017-08-14 21:47:03
|
>
> Anyhow, implementing basic ascii letters as
> predecessor/successor-system (in a way ``for [ x = "a":"g" ]'' would
> be also nice -- at least looking intuitively in some cases.
I don't like the idea of adding any syntax that depends on ascii encoding.
I would instead suggest a scheme like
gnuplot> array CityNames[25] =
> ["Atlanta","Boston","Charleston","Dallas","Ephrata","Fargo",,,]
> gnuplot> City(letter) = CityNames[
> strstrt("abcdefghijklmnopqrstuvwxyz",letter) ]
> gnuplot> print City("d")
> Dallas
> gnuplot>
That works as shown for ascii a-z but works equally well for non-ascii
gnuplot> GreekCity(letter) = GreekCityNames[
> strstrt("αβγδεζηθικλμνξοπρςστυφχψω", letter) ]
> gnuplot> print GreekCity("β")
> Βούλα
> gnuplot>
>
Ethan
On Mon, Aug 14, 2017 at 7:29 AM, ivana richterova <
iva...@mf...> wrote:
> Hi Ethan,
>
> >> I can disable all syscalls on startup at all. Otherwise I need to
> >> check if there are commands such 'rm -rf /', 'chmod -R a+r ~/.ssh',
>
> > This idea has been raised before.
> > The major problem I see with it is that gnuplot gains a lot of power from
> > being able to filter input and output through pipes.
>
> yes, I know. Pipes are nice and useful, but safe-check of other-hand
> scripts quite annoying. Maybe it would helpful widespread if there are
> strict simple rules for pipes and syscalls which can be demanded
> irrevocably at startup via init-file, as:
>
> - exact list of allowed commands including full path (e.g. /bin/grep,
> /bin/cat) with possibility to define aliases for them (e.g.,
> grep=/bin/grep)
> - do not read or write and access files and directories (except
> executing the allowed commands) outside the current directory tree at
> startup.
> - namely allow file extensions for files that can be (over)written.
> - allow or not creating new subdirs.
> - define permissions for new files and dirs.
>
> >> probably continue development. Currently, on my wish-list there is (1)
> >> a possibility to index arrays by letters OR get ascii code of chars,
> >
> > extension before considering it further. Do you have an example
> > application for which using a character as an array index is a big win?
>
> If I proceed letter-indexed files inside loops, then there are several
> ways how to access filename-related variables.
>
> I'd like, e.g., to fit files Data_<letter>.dat in one loop and used
> the fitted values in another loop.
>
> -------------------------------
> 1, eval, no arrays, so a "classic" way:
> ``
> # filename format: Data_<letter>.dat
> ind(filename) = filename[6:6]
>
> # declare function myvar(x) that decodes myvarX
> cls=' myvar(x)=('
> do for [ i = 1 : 26 ] { cls = sprintf("%s x eq '%c' ? myvar%c :", cls,
> i+96, i+96) }
> cls=cls." 1/0 )
> eval cls
>
> # set all myvarX to NaN
> cls=''
> do for [ i = 1 : 26 ] { cls = sprintf("%s myvar%c = NaN;", cls, i+96) }
> eval cls
>
> # loop1
> do for [ file in files1 ] {
> fit ..... via ____myvar;
> eval "myvar" . ind(file) . " = ____myvar"
> }
>
> # loop2, files2 can differ from files1
> plot for [ file in files2 ] file t sprintf("fit: %.2g", myvar(ind(file)))
>
> # loop3, whole range
> all=''
> do for [ i = 1 : 26 ] { all = sprintf("%s %c", cls, i+96) }
> filename(x)="Data_".x.".dat"
> plot for [ x in all ] filename(x) t sprintf("fit: %.2g", myvar(x))
> ''
> -------------------------------
>
> 2, index an array by associate "internal" varnames ____<letter>____
> for a..z with numbers 1..26:
> ``
> # declare vars ____<letter>____
> cls = ''
> do for [ i = 1 : 26 ] { cls = sprintf("%s ____%c____ = %i;", cls, i+96, i)
> }
> eval cls
> # convert letter to index array (set 1 for "")
> letter2number(c) = ( c eq "" ? 1 : value( "____".c."____") )
> # filename format: Data_<letter>.dat
> ind(filename)=letter2number(filename[6:6])
>
> # set array myvar[26] to NaN
> array myvar[26]
> do for [ i = 1 : 26 ] { myvar[i] = NaN }
>
> # loop1
> do for [ file in files1 ] {
> fit ..... via myvar[ind(file)];
> }
>
> # loop2, files2 can differ from files1
> plot for [ file in files2 ] file t sprintf("fit: %.2g", myvar[ind(file)])
>
> # loop3, whole range
> array all[|myvar|]
> do for [ i = 1 : |all| ] { all[i] = sprintf("%c", i+96) }
> filename(x)="Data_".x.".dat"
> plot for [ i = 1 : |all| ] filename(x = all[i]) t sprintf("fit: %.2g",
> myvar(x))
> ''
> -------------------------------
>
> 3, index arrays via letters:
> # currently not implemented.
>
> ``
> # filename format: Data_<letter>.dat
> ind(filename) = filename[6:6]
>
> # set array myvar["a":"z"] to NaN
> array myvar["a":"z"]
> do for [ x = "a" : "z" ] { myvar[x] = NaN }
>
> # loop1
> do for [ file in files1 ] {
> fit ..... via myvar[ind(file)];
> }
>
> # loop2, files2 can differ from files1
> plot for [ file in files2 ] file t sprintf("fit: %.2g", myvar[ind(file)])
>
> # loop3, whole range
> filename(x)="Data_".x.".dat"
> plot for [ x = "a" : "z" ] filename(x) t sprintf("fit: %.2g", myvar(x))
> ''
> -------------------------------
>
> disclaimer: the example code is not tested so it can miss some bracket etc.
> -------------------------------
>
> As I said I do not miss associative arrays yet, I'd preferred to find
> a way without named letter variables (since they are not universal),
> how to convert basic ascii letters to numbers as well.
>
> Anyhow, implementing basic ascii letters as
> predecessor/successor-system (in a way ``for [ x = "a":"g" ]'' would
> be also nice -- at least looking intuitively in some cases.
>
> Iva
>
|
|
From: ivana r. <iva...@mf...> - 2017-08-14 14:29:24
|
Hi Ethan,
>> I can disable all syscalls on startup at all. Otherwise I need to
>> check if there are commands such 'rm -rf /', 'chmod -R a+r ~/.ssh',
> This idea has been raised before.
> The major problem I see with it is that gnuplot gains a lot of power from
> being able to filter input and output through pipes.
yes, I know. Pipes are nice and useful, but safe-check of other-hand
scripts quite annoying. Maybe it would helpful widespread if there are
strict simple rules for pipes and syscalls which can be demanded
irrevocably at startup via init-file, as:
- exact list of allowed commands including full path (e.g. /bin/grep,
/bin/cat) with possibility to define aliases for them (e.g.,
grep=/bin/grep)
- do not read or write and access files and directories (except
executing the allowed commands) outside the current directory tree at
startup.
- namely allow file extensions for files that can be (over)written.
- allow or not creating new subdirs.
- define permissions for new files and dirs.
>> probably continue development. Currently, on my wish-list there is (1)
>> a possibility to index arrays by letters OR get ascii code of chars,
>
> extension before considering it further. Do you have an example
> application for which using a character as an array index is a big win?
If I proceed letter-indexed files inside loops, then there are several
ways how to access filename-related variables.
I'd like, e.g., to fit files Data_<letter>.dat in one loop and used
the fitted values in another loop.
-------------------------------
1, eval, no arrays, so a "classic" way:
``
# filename format: Data_<letter>.dat
ind(filename) = filename[6:6]
# declare function myvar(x) that decodes myvarX
cls=' myvar(x)=('
do for [ i = 1 : 26 ] { cls = sprintf("%s x eq '%c' ? myvar%c :", cls,
i+96, i+96) }
cls=cls." 1/0 )
eval cls
# set all myvarX to NaN
cls=''
do for [ i = 1 : 26 ] { cls = sprintf("%s myvar%c = NaN;", cls, i+96) }
eval cls
# loop1
do for [ file in files1 ] {
fit ..... via ____myvar;
eval "myvar" . ind(file) . " = ____myvar"
}
# loop2, files2 can differ from files1
plot for [ file in files2 ] file t sprintf("fit: %.2g", myvar(ind(file)))
# loop3, whole range
all=''
do for [ i = 1 : 26 ] { all = sprintf("%s %c", cls, i+96) }
filename(x)="Data_".x.".dat"
plot for [ x in all ] filename(x) t sprintf("fit: %.2g", myvar(x))
''
-------------------------------
2, index an array by associate "internal" varnames ____<letter>____
for a..z with numbers 1..26:
``
# declare vars ____<letter>____
cls = ''
do for [ i = 1 : 26 ] { cls = sprintf("%s ____%c____ = %i;", cls, i+96, i) }
eval cls
# convert letter to index array (set 1 for "")
letter2number(c) = ( c eq "" ? 1 : value( "____".c."____") )
# filename format: Data_<letter>.dat
ind(filename)=letter2number(filename[6:6])
# set array myvar[26] to NaN
array myvar[26]
do for [ i = 1 : 26 ] { myvar[i] = NaN }
# loop1
do for [ file in files1 ] {
fit ..... via myvar[ind(file)];
}
# loop2, files2 can differ from files1
plot for [ file in files2 ] file t sprintf("fit: %.2g", myvar[ind(file)])
# loop3, whole range
array all[|myvar|]
do for [ i = 1 : |all| ] { all[i] = sprintf("%c", i+96) }
filename(x)="Data_".x.".dat"
plot for [ i = 1 : |all| ] filename(x = all[i]) t sprintf("fit: %.2g", myvar(x))
''
-------------------------------
3, index arrays via letters:
# currently not implemented.
``
# filename format: Data_<letter>.dat
ind(filename) = filename[6:6]
# set array myvar["a":"z"] to NaN
array myvar["a":"z"]
do for [ x = "a" : "z" ] { myvar[x] = NaN }
# loop1
do for [ file in files1 ] {
fit ..... via myvar[ind(file)];
}
# loop2, files2 can differ from files1
plot for [ file in files2 ] file t sprintf("fit: %.2g", myvar[ind(file)])
# loop3, whole range
filename(x)="Data_".x.".dat"
plot for [ x = "a" : "z" ] filename(x) t sprintf("fit: %.2g", myvar(x))
''
-------------------------------
disclaimer: the example code is not tested so it can miss some bracket etc.
-------------------------------
As I said I do not miss associative arrays yet, I'd preferred to find
a way without named letter variables (since they are not universal),
how to convert basic ascii letters to numbers as well.
Anyhow, implementing basic ascii letters as
predecessor/successor-system (in a way ``for [ x = "a":"g" ]'' would
be also nice -- at least looking intuitively in some cases.
Iva
|
|
From: Ethan A M. <EAM...@gm...> - 2017-08-13 17:19:36
|
On Sunday, 13 August 2017 11:48:03 ivana richterova wrote:
> 1, gnuplot is a "unix" program. As such, it can do something quite
> well: to plot. It doesn't care about files. It supposes that you know
> what you want to plot and provide requested files.
>
> Under Unix/Linux, It'd be the default solution to generate a plot
> script for each directory outside gnuplot. So, the primary task is how
> simple can be this shell/pearl/... script.
>
> Secondly, it's nice that you can even do inside script as well now in
> V5+, although you need to run syscalls. (Personally, I'd appreciate if
> I can disable all syscalls on startup at all. Otherwise I need to
> check if there are commands such 'rm -rf /', 'chmod -R a+r ~/.ssh',
> etc. in other-hands scripts.)
This idea has been raised before.
The major problem I see with it is that gnuplot gains a lot of power from
being able to filter input and output through pipes. It is common to filter
input data through standard system tools like awk or grep, or convert
output on-the-fly using image conversion or display utilities.
Or both at once:
gnuplot> set term png
gnuplot> set output "| display png:-"
gnuplot> plot "< grep May annual.dat"
The concern is that every time you create a pipe you open a window
of vulnerability. If you are operating in an untrusted environment then
the use of pipes is exactly as dangerous as direct use of system
or shell commands. It would make no sense to disable one but not
the other, and a non-piping gnuplot would be substantially less useful.
Current gnuplot does its initial setup in a restricted mode that
disables both system commands and pipes. Neither is permitted in
a system or private initialization file ~/.gnuplot or $SOMEWHERE/gnuplot.rc
That provides a minimal level of protection against issuing the "gnuplot"
command in a potentially booby-trapped environment, but once the
program is initialized and accepting user commands pipes are reenabled.
> 2, gnuplot is currently highly developed. Iteration and arrays will
> probably continue development. Currently, on my wish-list there is (1)
> a possibility to index arrays by letters OR get ascii code of chars,
> and (2) to manipulate the iterating variable. Both would helpful also
> in your case.
Characters as numerical array indices does not seem feasible.
gnuplot accepts (indeed defaults to) multibyte encoding, usually UTF-8.
You can manipulate a multibyte character easily enough, e.g.
gnuplot> s = "mør"
gnuplot> print s[2:2]
ø
but the only character->numerical mapping that might be feasible is
mapping to a unicode code point.
I suppose one could have associative arrays, or LEAP/SAIL style
associative triplets. I'd want to see a solid use case for such an
extension before considering it further. Do you have an example
application for which using a character as an array index is a big win?
Ethan
|
|
From: ivana r. <iva...@mf...> - 2017-08-13 09:48:11
|
Hi Theo, I've noticed that 'title "" ' erase the corresponding key item, so the code could be bit easier...much easier if onecould be sure that Index3=1 always exists prior to higher values. > I just thought, I overlooked a very simple, short and efficient method. > Seems not to be the case. well, 1, gnuplot is a "unix" program. As such, it can do something quite well: to plot. It doesn't care about files. It supposes that you know what you want to plot and provide requested files. Under Unix/Linux, It'd be the default solution to generate a plot script for each directory outside gnuplot. So, the primary task is how simple can be this shell/pearl/... script. Secondly, it's nice that you can even do inside script as well now in V5+, although you need to run syscalls. (Personally, I'd appreciate if I can disable all syscalls on startup at all. Otherwise I need to check if there are commands such 'rm -rf /', 'chmod -R a+r ~/.ssh', etc. in other-hands scripts.) 2, gnuplot is currently highly developed. Iteration and arrays will probably continue development. Currently, on my wish-list there is (1) a possibility to index arrays by letters OR get ascii code of chars, and (2) to manipulate the iterating variable. Both would helpful also in your case. And you should install Ethan's patch sourceforge.net/p/gnuplot/bugs/_discuss/thread/fcab9784/ af51/attachment/iteration_bug_v5.patch for correct execution of iterations. 3, As I mentioned, the code can be rewritten to be more "word"-oriented. In my opinion, such a code is more straight. You can found one here: pebble.matfyz.cz/for_Theo.gplot (I previously choose the pure-array version since you seem you like it.) 4, note that the code may be simpler if one would know what you prefer to do if something. E.g., do you prefer make empty plots to keep the Index1-based layout or would it be OK if plots fold? Is there sometimes void in Index3 series? Etc. 5, under Unix/Linux, you can avoid warnings redirecting fd2: - run "gnuplot 2>/dev/null" - and inside code 'set print "/dev/stdout"' - note that this disable warnings as well as errors. To see errors, you can run e.g., ``if (GPVAL_ERRNO) { print "Error ", GPVAL_ERRNO, ": ", GPVAL_ERRMSG; reset error; }'' when ever you except any. (I'm not sure how to convert this for Windows, but I guess it should be possible to work with STDOUT and STDERR there.) Sincerely Iva <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virusfritt. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> |