Dear gnuplot developers,

I propose to extend or generalize the current "with circles" style to
allow plotting with circle segments or pie slices. This would also
make pie charts, which seems to be a frequently requested feature,
much easier to generate. This is currently possible in a very
cumbersome way, as one has to place circle objects manually.

I tried to implement this myself, an example image is linked below:

http://imagebin.ca/view/IyH15C.html

This was fairly easy to do, because the plot_circles() function in
graphics.c already uses do_arc() that is able to draw arbitrary pie
slices, but the angle parameters are set to 0 and 360. I just modified
plot_2d.c to read two more coordinates from the data file and passed
those to do_arc in the plot_circles function.

Now if you say that this was already tried and found to be impractical
or problematic for some reason, I'll cease and desist - but if you
think there is some use for this, I'll try to make a proper patch out
of it. (I'm a but unsure about my present approach: I used plot-
>points[i].ylow and plot->points[i].z for passing the arc start and
end angles, respectively; the latter seems to conflict with palette-
mapped variable color. Could I use xhigh and xlow instead, after those
were used to update the axis ranges?)

P=E9ter Juh=E1sz

On Feb 10, 5:26=A0pm, P=E9ter Juh=E1sz <peter.juhas...@gmail.com> wrote:
> Dear gnuplot developers,
>
> I propose to extend or generalize the current "with circles" style to
> allow plotting with circle segments or pie slices. This would also
> make pie charts, which seems to be a frequently requested feature,
> much easier to generate. This is currently possible in a very
> cumbersome way, as one has to place circle objects manually.
>
> I tried to implement this myself, an example image is linked below:
>
> http://imagebin.ca/view/IyH15C.html
>
> This was fairly easy to do, because the plot_circles() function in
> graphics.c already uses do_arc() that is able to draw arbitrary pie
> slices, but the angle parameters are set to 0 and 360. I just modified
> plot_2d.c to read two more coordinates from the data file and passed
> those to do_arc in the plot_circles function.
>
> Now if you say that this was already tried and found to be impractical
> or problematic for some reason, I'll cease and desist - but if you
> think there is some use for this, I'll try to make a proper patch out
> of it. (I'm a but unsure about my present approach: I used plot->points[i=
].ylow and plot->points[i].z for passing the arc start and
>
> end angles, respectively; the latter seems to conflict with palette-
> mapped variable color. Could I use xhigh and xlow instead, after those
> were used to update the axis ranges?)
>
> P=E9ter Juh=E1sz

I uploaded a patch to Sourceforge (anonymously, because I'm not
registered there):

http://sourceforge.net/tracker/?func=3Ddetail&aid=3D2949445&group_id=3D2055=
&atid=3D302055

Comments are appreciated.
P=E9ter Juh=E1sz

On Feb 11, 12:55=A0am, P=E9ter Juh=E1sz <peter.juhas...@gmail.com> wrote:
> On Feb 10, 5:26=A0pm, P=E9ter Juh=E1sz <peter.juhas...@gmail.com> wrote:
>
>
>
> > Dear gnuplot developers,
>
> > I propose to extend or generalize the current "with circles" style to
> > allow plotting with circle segments or pie slices. This would also
> > make pie charts, which seems to be a frequently requested feature,
> > much easier to generate. This is currently possible in a very
> > cumbersome way, as one has to place circle objects manually.
>
> > I tried to implement this myself, an example image is linked below:
>
> >http://imagebin.ca/view/IyH15C.html
>
> > This was fairly easy to do, because the plot_circles() function in
> > graphics.c already uses do_arc() that is able to draw arbitrary pie
> > slices, but the angle parameters are set to 0 and 360. I just modified
> > plot_2d.c to read two more coordinates from the data file and passed
> > those to do_arc in the plot_circles function.
>
> > Now if you say that this was already tried and found to be impractical
> > or problematic for some reason, I'll cease and desist - but if you
> > think there is some use for this, I'll try to make a proper patch out
> > of it. (I'm a but unsure about my present approach: I used plot->points=
[i].ylow and plot->points[i].z for passing the arc start and
>
> > end angles, respectively; the latter seems to conflict with palette-
> > mapped variable color. Could I use xhigh and xlow instead, after those
> > were used to update the axis ranges?)
>
> > P=E9ter Juh=E1sz
>
> I uploaded a patch to Sourceforge (anonymously, because I'm not
> registered there):
>
> http://sourceforge.net/tracker/?func=3Ddetail&aid=3D2949445&group_id=3D20=
55...
>
> Comments are appreciated.
> P=E9ter Juh=E1sz

I uploaded a slightly modified version:

http://sourceforge.net/tracker/?func=3Ddetail&aid=3D2949851&group_id=3D2055=
&atid=3D302055

(Please delete the previous one.)

This patch also fixes a problem that affected autoscaling of the color
axis when the "circles" style was used with palette mapped variable
color.
(The problem was that at the end of the store2d_point() function the
width attribute was assigned to the z coordinate and then that
coordinate was used to update the color axis range. However, in the
case of the "circles" style and a few others, the yhigh attribute is
used to store variable color information.)

Even if the rest of the patch gets rejected, this fix may be worth
looking at.

P=E9ter Juh=E1sz

Péter Juhász wrote:

> On Feb 11, 12:55 am, Péter Juhász <peter.juhas...@gmail.com> wrote:
>>
>> > Dear gnuplot developers,
>>
>> > I propose to extend or generalize the current "with circles" style
>> > to allow plotting with circle segments or pie slices. This would
>> > also make pie charts, which seems to be a frequently requested
>> > feature, much easier to generate. This is currently possible in a
>> > very cumbersome way, as one has to place circle objects manually.
>>
>> > I tried to implement this myself, an example image is linked below:
>>
>> >http://imagebin.ca/view/IyH15C.html

Looks nice.
I'll review the patch code this weekend.

Do you have a self-contained demo that could be included in the demo
collection?   It could replace the manually constructed pie chart in
the 1st plot of "circles.dem".

>>
>> > This was fairly easy to do, because the plot_circles() function in
>> > graphics.c already uses do_arc() that is able to draw arbitrary pie
>> > slices, but the angle parameters are set to 0 and 360. I just
>> > modified plot_2d.c to read two more coordinates from the data file
>> > and passed those to do_arc in the plot_circles function.
>>
>> > Now if you say that this was already tried and found to be
>> > impractical or problematic for some reason, I'll cease and desist -
>> > but if you think there is some use for this, I'll try to make a
>> > proper patch out of it.

Only a few of the terminal types draw circles/arcs smoothly enough
to make a nice picture.  But that by itself isn't an argument against
using them on the terminals that do handle it nicely.

		Ethan




>> > (I'm a but unsure about my present
>> > approach: I used plot->points[i].ylow and plot->points[i].z for
>> > passing the arc start and
>> > end angles, respectively; the latter seems to conflict with
>> > palette- mapped variable color. Could I use xhigh and xlow instead,
>> > after those were used to update the axis ranges?)
>>
>> > Péter Juhász
>>
>> I uploaded a patch to Sourceforge (anonymously, because I'm not
>> registered there):
>>
>> http://sourceforge.net/tracker/?func=detail&aid=2949445&group_id=2055...
>>
>> Comments are appreciated.
>> Péter Juhász
> 
> I uploaded a slightly modified version:
> 
> http://sourceforge.net/tracker/?func=detail&aid=2949851&group_id=2055&atid=302055
> 
> (Please delete the previous one.)
> 
> This patch also fixes a problem that affected autoscaling of the color
> axis when the "circles" style was used with palette mapped variable
> color.
> (The problem was that at the end of the store2d_point() function the
> width attribute was assigned to the z coordinate and then that
> coordinate was used to update the color axis range. However, in the
> case of the "circles" style and a few others, the yhigh attribute is
> used to store variable color information.)
> 
> Even if the rest of the patch gets rejected, this fix may be worth
> looking at.
> 
> Péter Juhász

On Feb 12, 6:51=A0am, sfeam <sf...@users.sourceforge.net> wrote:
> P=E9ter Juh=E1sz wrote:
> > On Feb 11, 12:55 am, P=E9ter Juh=E1sz <peter.juhas...@gmail.com> wrote:
>
> >> > Dear gnuplot developers,
>
> >> > I propose to extend or generalize the current "with circles" style
> >> > to allow plotting with circle segments or pie slices. This would
> >> > also make pie charts, which seems to be a frequently requested
> >> > feature, much easier to generate. This is currently possible in a
> >> > very cumbersome way, as one has to place circle objects manually.
>
> >> > I tried to implement this myself, an example image is linked below:
>
> >> >http://imagebin.ca/view/IyH15C.html
>
> Looks nice.
> I'll review the patch code this weekend.
>
> Do you have a self-contained demo that could be included in the demo
> collection? =A0 It could replace the manually constructed pie chart in
> the 1st plot of "circles.dem".
>

Yes! In fact I rewrote the appropriate section in the documentation
and included an example that builds a pie chart with "plot '-'" inline
data. Maybe it could be fleshed out a bit and moved into a separate
demo.

P=E9ter Juh=E1sz

>
>
> >> > This was fairly easy to do, because the plot_circles() function in
> >> > graphics.c already uses do_arc() that is able to draw arbitrary pie
> >> > slices, but the angle parameters are set to 0 and 360. I just
> >> > modified plot_2d.c to read two more coordinates from the data file
> >> > and passed those to do_arc in the plot_circles function.
>
> >> > Now if you say that this was already tried and found to be
> >> > impractical or problematic for some reason, I'll cease and desist -
> >> > but if you think there is some use for this, I'll try to make a
> >> > proper patch out of it.
>
> Only a few of the terminal types draw circles/arcs smoothly enough
> to make a nice picture. =A0But that by itself isn't an argument against
> using them on the terminals that do handle it nicely.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ethan
>
> >> > (I'm a but unsure about my present
> >> > approach: I used plot->points[i].ylow and plot->points[i].z for
> >> > passing the arc start and
> >> > end angles, respectively; the latter seems to conflict with
> >> > palette- mapped variable color. Could I use xhigh and xlow instead,
> >> > after those were used to update the axis ranges?)
>
> >> > P=E9ter Juh=E1sz
>
> >> I uploaded a patch to Sourceforge (anonymously, because I'm not
> >> registered there):
>
> >>http://sourceforge.net/tracker/?func=3Ddetail&aid=3D2949445&group_id=3D=
2055...
>
> >> Comments are appreciated.
> >> P=E9ter Juh=E1sz
>
> > I uploaded a slightly modified version:
>
> >http://sourceforge.net/tracker/?func=3Ddetail&aid=3D2949851&group_id=3D2=
055...
>
> > (Please delete the previous one.)
>
> > This patch also fixes a problem that affected autoscaling of the color
> > axis when the "circles" style was used with palette mapped variable
> > color.
> > (The problem was that at the end of the store2d_point() function the
> > width attribute was assigned to the z coordinate and then that
> > coordinate was used to update the color axis range. However, in the
> > case of the "circles" style and a few others, the yhigh attribute is
> > used to store variable color information.)
>
> > Even if the rest of the patch gets rejected, this fix may be worth
> > looking at.
>
> > P=E9ter Juh=E1sz

On Feb 12, 10:13=A0am, P=E9ter Juh=E1sz <peter.juhas...@gmail.com> wrote:
> On Feb 12, 6:51=A0am, sfeam <sf...@users.sourceforge.net> wrote:
>
>
>
> > P=E9ter Juh=E1sz wrote:
> > > On Feb 11, 12:55 am, P=E9ter Juh=E1sz <peter.juhas...@gmail.com> wrot=
e:
>
> > >> > Dear gnuplot developers,
>
> > >> > I propose to extend or generalize the current "with circles" style
> > >> > to allow plotting with circle segments or pie slices. This would
> > >> > also make pie charts, which seems to be a frequently requested
> > >> > feature, much easier to generate. This is currently possible in a
> > >> > very cumbersome way, as one has to place circle objects manually.
>
> > >> > I tried to implement this myself, an example image is linked below=
:
>
> > >> >http://imagebin.ca/view/IyH15C.html
>
> > Looks nice.
> > I'll review the patch code this weekend.
>
> > Do you have a self-contained demo that could be included in the demo
> > collection? =A0 It could replace the manually constructed pie chart in
> > the 1st plot of "circles.dem".
>
> Yes! In fact I rewrote the appropriate section in the documentation
> and included an example that builds a pie chart with "plot '-'" inline
> data. Maybe it could be fleshed out a bit and moved into a separate
> demo.
>
> P=E9ter Juh=E1sz
>
>
>
> > >> > This was fairly easy to do, because the plot_circles() function in
> > >> > graphics.c already uses do_arc() that is able to draw arbitrary pi=
e
> > >> > slices, but the angle parameters are set to 0 and 360. I just
> > >> > modified plot_2d.c to read two more coordinates from the data file
> > >> > and passed those to do_arc in the plot_circles function.
>
> > >> > Now if you say that this was already tried and found to be
> > >> > impractical or problematic for some reason, I'll cease and desist =
-
> > >> > but if you think there is some use for this, I'll try to make a
> > >> > proper patch out of it.
>
> > Only a few of the terminal types draw circles/arcs smoothly enough
> > to make a nice picture. =A0But that by itself isn't an argument against
> > using them on the terminals that do handle it nicely.
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ethan
>
> > >> > (I'm a but unsure about my present
> > >> > approach: I used plot->points[i].ylow and plot->points[i].z for
> > >> > passing the arc start and
> > >> > end angles, respectively; the latter seems to conflict with
> > >> > palette- mapped variable color. Could I use xhigh and xlow instead=
,
> > >> > after those were used to update the axis ranges?)
>
> > >> > P=E9ter Juh=E1sz
>
> > >> I uploaded a patch to Sourceforge (anonymously, because I'm not
> > >> registered there):
>
> > >>http://sourceforge.net/tracker/?func=3Ddetail&aid=3D2949445&group_id=
=3D2055...
>
> > >> Comments are appreciated.
> > >> P=E9ter Juh=E1sz
>
> > > I uploaded a slightly modified version:
>
> > >http://sourceforge.net/tracker/?func=3Ddetail&aid=3D2949851&group_id=
=3D2055...
>
> > > (Please delete the previous one.)
>
> > > This patch also fixes a problem that affected autoscaling of the colo=
r
> > > axis when the "circles" style was used with palette mapped variable
> > > color.
> > > (The problem was that at the end of the store2d_point() function the
> > > width attribute was assigned to the z coordinate and then that
> > > coordinate was used to update the color axis range. However, in the
> > > case of the "circles" style and a few others, the yhigh attribute is
> > > used to store variable color information.)
>
> > > Even if the rest of the patch gets rejected, this fix may be worth
> > > looking at.
>
> > > P=E9ter Juh=E1sz

I've re-uploaded the patch, for two reasons.

First, I've added a demo to circles.dem and a data file to feed it.
Second, I noticed that the do_arc routine in term.c doesn't handle the
case where the arc_end is much_bigger is than arc_begin: the number of
segments to be plotted was simply taken from the difference of the two
angles. So the internal structure storing the vertices would overflow
and gnuplot would crash.
So I fixed this too.

Note that this functionality is already exposed to the user - circle
objects can be given an arc parameter - so it is possible to crash
gnuplot this way (I think this is true about the 4.4-rc, too).

Please use this version of the patch and delete the previous one.

P=E9ter Juh=E1sz

Péter Juhász wrote:

> Second, I noticed that the do_arc routine in term.c doesn't handle the
> case where the arc_end is much_bigger is than arc_begin: the number of
> segments to be plotted was simply taken from the difference of the two
> angles. So the internal structure storing the vertices would overflow
> and gnuplot would crash.

Good catch.  But having found the problem you are insufficiently
paranoid while fixing it.
+       /* Fix if arc is more than a full circle */
+       /* lest we cause an overflow */
+    while (arc_end > arc_start + 361.)
+       arc_end -= 360.;
This fix fails for really large numbers due to precision round-off
truncation.  If somehow arc_end == HUGE then
        arc_end -= 360   is still equal to HUGE
and we are now in an infinite loop.  This problem bit us recently in
the time interval code, so it is fresh in my mind.

We can protect against this in the case of individual objects by adding
checks in set.c:
-                       this_circle->arc_begin = real_expression();
+                       arc = real_expression();
+                       if (fabs(arc) > 1000.)
+                           int_error(c_token-1,"Angle out of range");
+                       else
+                           this_circle->arc_begin = arc;
and so on.

It needs something similar for datafile input.  Better to catch it on
input and mark the point UNDEFINED than store a problematic vales and
have to deal with it while plotting. 

Other than that it looks good after a first pass look at the code.

I do have a meta-comment, however.  This approach to the problem
requires that you pre-compute the start and end angles for each wedge
of the pie chart.  It seems more natural to allow input from a column
of unscaled values and let the program figure out automatically what
fraction of the total each one corresponds to, and hence what its
start and end angles should be.  This would make it more similar to
the current stacked histogram plot mode and the new boxplot mode.

But I suppose that would require a separate plot style, not just a
variant of "with circles".   
Or maybe not...  
Maybe you could get by with just an extra flag on the command line 
"plot ... using (x):(y):3 with circles piechart".
It would read in all the values in column 3, then trigger a 
post-processing pass that filled in the start and end angles for
each wedge.  The radius could be some function of the column total.
Not quite the same purpose as the existing routines
histogram_range_fiddling() and boxplot_range_fiddling(), but 
executed at that same stage of processing.   
I'll have to think about this further.

	Ethan

On Feb 13, 6:18=A0am, sfeam <sf...@users.sourceforge.net> wrote:
> P=E9ter Juh=E1sz wrote:
> > Second, I noticed that the do_arc routine in term.c doesn't handle the
> > case where the arc_end is much_bigger is than arc_begin: the number of
> > segments to be plotted was simply taken from the difference of the two
> > angles. So the internal structure storing the vertices would overflow
> > and gnuplot would crash.
>
> Good catch. =A0But having found the problem you are insufficiently
> paranoid while fixing it.
> + =A0 =A0 =A0 /* Fix if arc is more than a full circle */
> + =A0 =A0 =A0 /* lest we cause an overflow */
> + =A0 =A0while (arc_end > arc_start + 361.)
> + =A0 =A0 =A0 arc_end -=3D 360.;
> This fix fails for really large numbers due to precision round-off
> truncation. =A0If somehow arc_end =3D=3D HUGE then
> =A0 =A0 =A0 =A0 arc_end -=3D 360 =A0 is still equal to HUGE
> and we are now in an infinite loop. =A0This problem bit us recently in
> the time interval code, so it is fresh in my mind.
>
> We can protect against this in the case of individual objects by adding
> checks in set.c:
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this_circle->arc_begin =3D =
real_expression();
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 arc =3D real_expression();
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (fabs(arc) > 1000.)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int_error(c_token-1=
,"Angle out of range");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this_circle->arc_be=
gin =3D arc;
> and so on.
>
> It needs something similar for datafile input. =A0Better to catch it on
> input and mark the point UNDEFINED than store a problematic vales and
> have to deal with it while plotting.
>
> Other than that it looks good after a first pass look at the code.
>
> I do have a meta-comment, however. =A0This approach to the problem
> requires that you pre-compute the start and end angles for each wedge
> of the pie chart. =A0It seems more natural to allow input from a column
> of unscaled values and let the program figure out automatically what
> fraction of the total each one corresponds to, and hence what its
> start and end angles should be. =A0This would make it more similar to
> the current stacked histogram plot mode and the new boxplot mode.
>
> But I suppose that would require a separate plot style, not just a
> variant of "with circles". =A0
> Or maybe not... =A0
> Maybe you could get by with just an extra flag on the command line
> "plot ... using (x):(y):3 with circles piechart".
> It would read in all the values in column 3, then trigger a
> post-processing pass that filled in the start and end angles for
> each wedge. =A0The radius could be some function of the column total.
> Not quite the same purpose as the existing routines
> histogram_range_fiddling() and boxplot_range_fiddling(), but
> executed at that same stage of processing. =A0
> I'll have to think about this further.
>
> =A0 =A0 =A0 =A0 Ethan

Thank you for your comments!

I totally missed the potential infinite loop. The approach I took
starts to break down even before the arc_end approaches the limit
where the loss of precision causes the infinite loop (that happens at
about 1e17): even at arc_end =3D 1e12 it takes several seconds to draw
one circle segment, because the code just dumbly keeps subtracting 360
from that huge number until it's close to arc_begin.
Now that I think about it, your original
     while (arc_end < arc_start)
           arc_end +=3D 360.;
suffers from this same problem.

I agree that adding checks at the datafile reading stage and flagging
bad values there is the way to go.

Meta-answer to the meta-comment:

I agree that it is still cumbersome to make pie charts with this
approach as I have to pre-compute each wedge beforehand.
Adding a dedicated pie chart mode wouldn't be too complicated at this
point - but I definitely think that if such a mode is added, it should
be added as a separate plotting style. The reason for this that such a
mode - that reads a whole column and processes it itself, instead of
plotting each line - works fundamentally differently than the majority
of plotting styles. So it should be separated from the circles style,
just as it is with the old candlestick and the new boxplot styles.

The functionality I added has other uses beside the common pie chart:
there is a variant that uses fixed angle segments and the data is
encoded in the radii of the segments (rose plot or Florence
Nightingale plot, as this is sometimes called). Or I can envision a
scatter plot using 30=B0 circle segments where a further dimension of
information is encoded in the angle of each segment.

This one of the great points of gnuplot, I think: it has tools that
are designed to do simple things in a simple way, but are sufficiently
general that complicated and unusual things can be done with them.

And there is one further point to consider. There was an ulterior
motive of not providing a pie chart mode in gnuplot so far: pie charts
are generally not a good way to convey information - even the FAQ says
so.
So I think coding a dedicated pie chart mode should not be a high
priority now. If people want to shoot themselves in the foot with it,
then well, let's provide a way that they can do it, but that way
should be useful for other things, too.

Anyway, thank you for considering my work!

P=E9ter Juh=E1sz