Sage 4.3.2 spkg dependency graph
Pat LeSmithe
http://www.sagenb.org/home/pub/1530/
Comments, corrections, etc., are welcome!
William Stein
That would be an awesome T-shirt!
William
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Robert Miller
http://sage.math.washington.edu/home/rlmill/deps.png
I still have the scripts, layout, etc. saved so it probably wouldn't
be much work to update it for 4.3.2.
--
Robert L. Miller
http://www.rlmiller.org/
mhampton
Is there a simple answer to why GAP is in such an unusual position?
-Marshall
William Stein
> Those are both very cool.
>
> Is there a simple answer to why GAP is in such an unusual position?
This might be partly accounted for by the following surprising and
amazing fact:
GAP does not depend on or use GMP (or MPIR)!
Yes, somehow you can do everything GAP claims to do without ever even
making use of fast integer arithmetic. I've always been amazed by
this.
The explanation for the plot itself is the line for GAP in the
spkg/standard/deps file, which is:
# gap requires SAGE so that gap_reset_workspace works.
$(INST)/$(GAP): $(BASE) $(INST)/$(MPIR) $(INST)/$(TERMCAP)
$(INST)/$(READLINE) $(INST)/$(SAGE)
$(SAGE_SPKG) $(GAP) 2>&1
Anything that depends on the core Sage library itself is going to look
funny in this plot.
It's a mistake that $(INST)/$(MPIR) is explicitly listed as a
dependency of GAP above, by the way. I probably put it there. I
was actually pretty shocked last summer when I was writing libgap and
learned that GAP doesn't have any fast integer arithmetic
capabilities.
-- William
>
> -Marshall
Nils Bruin
A very nice picture, but it made me notice something about the default
graph lay-out:
There are cases where a vertex lies almost perfectly on an edge. This
makes it look like the edge is incident with the vertex. If there
would be a small white "shadow" around the vertex, it would be clear
that the edge passes "under" the vertex.
If someone feels an urgent need to improve graph plotting, this might
be a thing that could use some attention. A rough start could be:
* plot the edges
* plot the vertices on top of a slightly larger white "shadow"
* fill in the heads and tails of the edges to make sure they actually
connect to the vertices.
Of course, avoiding crossings like this as much as possible is a much
more difficult and interesting problem to solve (curve edges to avoid
edges they aren't incident with?)
Alex Ghitza
> A very nice picture, but it made me notice something about the default
> graph lay-out:
> There are cases where a vertex lies almost perfectly on an edge. This
> makes it look like the edge is incident with the vertex. If there
> would be a small white "shadow" around the vertex, it would be clear
> that the edge passes "under" the vertex.
> If someone feels an urgent need to improve graph plotting, this might
> be a thing that could use some attention. A rough start could be:
> * plot the edges
> * plot the vertices on top of a slightly larger white "shadow"
> * fill in the heads and tails of the edges to make sure they actually
> connect to the vertices.
>
> Of course, avoiding crossings like this as much as possible is a much
> more difficult and interesting problem to solve (curve edges to avoid
> edges they aren't incident with?)
^^^^^ should be vertices.
This sounds like a good idea though.
Alex
--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/