problem in displaying graphs
pong
k=graphs.CompleteGraph(6)
show(k)
displays K_6 but the vertices got truncated. I don't have this problem
on a linux machine running SAGE 4.1.1 notebook on firefox.
Any help?
I would like to include the pic but I don't see how on using this
discussion group.
Thanks in advance
William Stein
That's definitely an annoying bug. The only workaround I could easily
find (without just fixing the bug) is:
k=graphs.CompleteGraph(6)
k.plot(graph_border=1)
William
pong
Is it a bug of SAGE 4.1.2 or just the Mac distribution? I guess my
question is if I upgrade SAGE to the latest version on my linux
machine, will I get the same problem?
On Oct 22, 10:22 pm, William Stein <wst...@gmail.com> wrote:
Jason Grout
I think this is because the graph plotting code sets the min/max x/y
positions to the coordinates of the vertices, without allowing for the
radii of the circles representing the vertices. If the graph_border
option is given, then a border is added to the picture and the
xmin/xmax, ymin/ymax parameters are expanded.
To fix this, try replacing the line:
G.set_axes_range(self.xmin, self.xmax, self.ymin, self.ymax)
(line 767 in graphs/graph_plot.py)
with the following two lines:
v_radius = sqrt(self._options['vertex_size']/pi)*1.5 #
vertex_size is the area of the vertex circle, then pad a bit
G.set_axes_range(self.xmin-v_radius, self.xmax+v_radius,
self.ymin-v_radius, self.ymax+v_radius)
to allow space for the radii of the vertices. I can't test this right
now because of problems with my Sage installation.
Thanks,
Jason
--
Jason Grout
Jason Grout
A work-around is to pad the graphic:
k=graphs.CompleteGraph(6)
show(k,axes_pad=.1)
This adds 10% of the width to both the left and right (so the figure is
120% its original width) and 10% of the height to the top and bottom (so
the figure is 120% of the original height).
See my other message for a better fix that uses the vertex size to
figure out how much to pad the graphic.
William Stein
<jason...@creativetrax.com> wrote:
>
> William Stein wrote:
>> On Thu, Oct 22, 2009 at 10:09 PM, pong <wypo...@gmail.com> wrote:
>>> I am using SAGE 4.1.2 notebook on firefox on a Mac.
>>>
>>> k=graphs.CompleteGraph(6)
>>> show(k)
>>>
>>> displays K_6 but the vertices got truncated. I don't have this problem
>>> on a linux machine running SAGE 4.1.1 notebook on firefox.
>>>
>>> Any help?
>>> I would like to include the pic but I don't see how on using this
>>> discussion group.
>>
>> That's definitely an annoying bug. The only workaround I could easily
>> find (without just fixing the bug) is:
>>
>> k=graphs.CompleteGraph(6)
>> k.plot(graph_border=1)
>>
>
> A work-around is to pad the graphic:
>
> k=graphs.CompleteGraph(6)
> show(k,axes_pad=.1)
minutes before in response to the original email, and axes_pad isn't
even there. That would have been useful many times in my class
last year. That will teach me to read the source more.
> This adds 10% of the width to both the left and right (so the figure is
> 120% its original width) and 10% of the height to the top and bottom (so
> the figure is 120% of the original height).
>
> See my other message for a better fix that uses the vertex size to
> figure out how much to pad the graphic.
>
> Thanks,
>
> Jason
>
> --
> Jason Grout
>
>
> >
>
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
pong
Setting axes_pad=.1 does work. Thanks! However, I tried your
codes in the previous email. The resulting graph has nodes "clump
together". I guess the problem is with the value 1.5. When I changed
that to a smaller value say .05 then things work just fine. Even
though, sqrt(area/pi) is the radius... I'm not sure what's the
problem of your originally codes.
Jason Grout
> Hi Jason,
>
> Setting axes_pad=.1 does work. Thanks! However, I tried your
> codes in the previous email. The resulting graph has nodes "clump
> together". I guess the problem is with the value 1.5. When I changed
> that to a smaller value say .05 then things work just fine. Even
> though, sqrt(area/pi) is the radius... I'm not sure what's the
> problem of your originally codes.
>
I forgot that the area unit is points^2, so we'll need to convert
between points and data coordinates to deal with this. That will be a
bit harder, as the axes padding may have to come at a slightly later stage.
Jason
--
Jason Grout
Jason Grout
> Thanks! And, argh! I stared at the output of k.plot? for 10-15
> minutes before in response to the original email, and axes_pad isn't
> even there. That would have been useful many times in my class
> last year. That will teach me to read the source more.
It's an option to show() (and documented there). I added it in August
when we redid the matplotlib backend with the new axes code, so I don't
think it would have been useful last year :). The default is .02 (so
the picture is 4% wider and 4% taller than originally specified), so
that we don't clip plotted points, etc.
Jason
--
Jason Grout
William Stein
<jason...@creativetrax.com> wrote:
>
> William Stein wrote:
>
>> Thanks! And, argh! I stared at the output of k.plot? for 10-15
>> minutes before in response to the original email, and axes_pad isn't
>> even there. That would have been useful many times in my class
>> last year. That will teach me to read the source more.
>
>
> It's an option to show() (and documented there).
I see, so it has absolutely nothing at all to do a priori with
plotting graphs. Fair enough.
> I added it in August
> when we redid the matplotlib backend with the new axes code, so I don't
> think it would have been useful last year :). The default is .02 (so
> the picture is 4% wider and 4% taller than originally specified), so
> that we don't clip plotted points, etc.
That's one of those quick hackish design decisions that comes back to
haunt us over the years... can one just query matplotlib for a range
that contains all the elements in the plot?
-- William
Jason Grout
>
> That's one of those quick hackish design decisions that comes back to
> haunt us over the years... can one just query matplotlib for a range
> that contains all the elements in the plot?
Indeed!
Some discussion:
For tick labels and other things that extend beyond the axes, you can
shrink the entire plot to fit inside of the figure. I wrote some code
to do that, but it is not finished yet. I posted a short example to the
matplotlib mailing list to include in their documentation (based on a
more limited example already in their FAQ):
http://www.nabble.com/Automatically-make-room-for-tick-labels-FAQ-entry-td25251691.html
That code takes care of tick labels extending out, but could be expanded
to look at all interesting graphical objects in a plot. This doesn't
address the clipping at axes boundaries, though (see below).
Another thing to deal with is not clipping the circles at the axes
boundaries (plot a graph and do frame=True and axes_pad=0 in show to see
what I mean, or try plotting a bunch of points with axes_pad=0). There
is a bug in our current version of matplotlib (fixed in matplotlib svn)
where the clipping parameter is ignored for scatter plots (which is what
our vertices are), so we can't turn off clipping right now. See
http://www.mail-archive.com/matplotl...@lists.sourceforge.net/msg05486.html
for the relevant discussion.
I think you're mentioning something different, though---calculate a
(tight) bounding box around the figures and resize the axes coordinates
based on that. It is slightly nontrivial, since the scatter plot sizes
are specified in points, so we don't know the data coordinate sizes of
the vertices until we actually draw them (and thus have the dpi).
However, there is a way to have a callback adjust things as we draw the
figure (see paragraph (1) above for an example).
Thanks,
Jason