Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[gef-dev] Rép. : gef-dev digest, Vol 1 #98 - 2 msgs (Réponse automatique)

Je suis absent du mercredi 13 août au mercredi 27 août inclus. 
Pour toute urgence, contacter Jocelyn Carfantan au 55.15.

--------------------------------------------------------------------------------------------------
Antony GUILLOTEAU - Système U Ouest
Service : DSI - Normes / Méthodes / Qualité
Tél        : 02.40.68.59.59  poste 51.08
E-mail   : antony.guilloteau@xxxxxxxxxxxx

>>> "gef-dev@xxxxxxxxxxx" 13/08/03 18h00 >>>

Send gef-dev mailing list submissions to
	gef-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	http://dev.eclipse.org/mailman/listinfo/gef-dev
or, via email, send a message with subject or body 'help' to
	gef-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
	gef-dev-admin@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gef-dev digest..."


Today's Topics:

   1. =?ISO-8859-1?Q?R=E9p.=20:=20gef-dev=20digest,=20Vol=201=20#97=20?=
       =?ISO-8859-1?Q?-=201=20msg=20(R=E9ponse=20automatique)?= (Antony GUILLOTEAU)

--__--__--

Message: 1
Date: Tue, 12 Aug 2003 18:07:56 +0200
From: "Antony GUILLOTEAU" <antony.guilloteau@xxxxxxxxxxxx>
To: <gef-dev@xxxxxxxxxxx>
Subject: [gef-dev] =?ISO-8859-1?Q?R=E9p.=20:=20gef-dev=20digest,=20Vol=201=20#97=20?=
 =?ISO-8859-1?Q?-=201=20msg=20(R=E9ponse=20automatique)?=
Reply-To: gef-dev@xxxxxxxxxxx

Je suis absent du mercredi 13 ao=FBt au mercredi 27 ao=FBt inclus.=20
Pour toute urgence, contacter Jocelyn Carfantan au 55.15.

---------------------------------------------------------------------------=
-----------------------
Antony GUILLOTEAU - Syst=E8me U Ouest
Service : DSI - Normes / M=E9thodes / Qualit=E9
T=E9l        : 02.40.68.59.59  poste 51.08
E-mail   : antony.guilloteau@xxxxxxxxxxxx

>>> "gef-dev@xxxxxxxxxxx" 12/08/03 18h00 >>>

Send gef-dev mailing list submissions to
	gef-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	http://dev.eclipse.org/mailman/listinfo/gef-dev
or, via email, send a message with subject or body 'help' to
	gef-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
	gef-dev-admin@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gef-dev digest..."


Today's Topics:

   1. RE: CDAG layout algorithms (Randy Hudson)

-- __--__-- 

Message: 1
To: gef-dev@xxxxxxxxxxx
Subject: RE: [gef-dev] CDAG layout algorithms
From: Randy Hudson <hudsonr@xxxxxxxxxx>
Date: Mon, 11 Aug 2003 14:29:23 -0400
Reply-To: gef-dev@xxxxxxxxxxx

This is a multipart message in MIME format.
--=3D_alternative 0065BDD785256D7F_=3D
Content-Type: text/plain; charset=3D"US-ASCII"

Any suggestions on how to break cycles without violating subgraph=20
requirements?  It seems like inverting random edges could result in a=20
situation where the bottom of a subgraph is not below all of the nodes=20
inside it.

If possible, I was wondering if I could write one algorithm which =
inverts=20
edges, thus removing cycles, for both directed and compound directed.  =
If=20
not possible, what is the technique for compound graphs?  Perhaps a=20
modification to the greedy algorithm (Graph Drawing 1999), which uses a=20
left and right stack.  The first time a node N belonging to subgraph S =
is=20
added to "left", the top boundary for its subgraph is added first.=20
Something similar for bottom boundaries.

-Randy





"Michael Forster" <forster@xxxxxxxxxxxxxxxxx>
Sent by: gef-dev-admin@xxxxxxxxxxx
08/07/2003 05:11 PM
Please respond to gef-dev
=20
        To:     <gef-dev@xxxxxxxxxxx>
        cc:=20
        Subject:        RE: [gef-dev] CDAG layout algorithms


Hi,

> I've skimmed over your paper.  The sub-optimal reodering=20
> shown in Figure 6 could be corrected by a final pass through=20
> the graph which exchanges "adjacent pairs" of nodes if it=20
> improves the quality of the layout.=20

Of course. This is just a minimal example where Sander's algorithm
fails. So it is not surprising that a simple heuristic can solve this
particular problem. But remember: It still stays a heuristic, and it
does no solve the fundamental problem. So you will definitely get
unneccessary crossings.

> My concern with preserving the containment hierarchy during=20
> the crossing reduction is that this prevents a node from=20
> gradually passing through a subgraph to which it doesn't=20
> belong.=20

This does not happen, and this is proven (Well, the proof is sketched,
at least :-) in the paper.

> It seems like using your algorithm, the node would=20
> have to jump across the whole subgraph (compound node) at=20
> once, or not at all.=20

This is correct, and the nodes make these big jumps. If two subgraphss
which are high in the subgraph hierarchy are exchanged while applying
the crossing reduction to an enclosing subgraph or the root of the
subgraph hierarchy, the dependent (base) nodes "jump" over the whole
other subgraph.

I admit that my algorithm may be harder to understand and implement than
Sander's. But it is better than Sander's by proof. It is even optimal if
only considered according to a single rank (=3Dlayer=3Dlevel). This means,
there will be only unnecessary crossings that come from the underlying
2-level crossing reduction (These occur in both algorithms - the problem
is NP-hard, so you cannot expect global optimality), but _no_ crossings
that come from the application to the clustered graph. Sander's
application generates such crossings. So I am highly convinced that my
algorithm performs better than Sander's. Of course, I am biased, and I
do not have numbers to substantiate my opinion, but the theoretical
results in my paper promise good practical results. By the way: I talked
to Sander last year after my talk at the conference, and he admitted
that my method is more promising than his quick-and-dirty solution.

Note that I do not want to persuade you to use my algorithm, especially,
if you are under deadline pressure and fully understand Sander's
algorithm but not mine. On the contrary: I will be happy to have an
implementation of Sander's algorithm to compare to mine in my thesis
:-).

By the way: Would it be possible, to have a look at your code? It will
be published under the CPL anyway, right?
=20
> Here is a case=20
> where reversing the edge from a cycle is better than removing it.=20
>=20
> Given Subgraph A with members a1, a2, a3=20
> Given Subgraph B with members b1, b2, b3=20
> And a node X.=20
>=20
> Ignoring all edges, here are the final rank orderings:=20
> a1       b1=20
> a2       b2=20
> b3  X  a3=20
>=20
> The two subgraphs are intertwined, with a random node falling=20
> between them.=20
> The cycle A -> B -> X -> A exists.  If you break X -> A, you=20
> then end up with last row of:=20
>         a3  b3  X=20
> But, if you reverse it to be A->X, you have partial ordering=20
> A->X, and A->B, which allows for:=20
>         a3 X b3=20

No, it does not, because you forgot the edge B -> X, which still exists.

In general: If you have a cycle

    X1 -> X2 -> ... -> Xn -> X1

and you break it up at Xn -> X1, it does not matter whether the edge

                       X1 -> Xn

is inserted, because the partial ordering is transitive, and so Xn has
to be right of X1 anyway. This means, the quality depends only on the
concrete implementation of the topological ordering, but not on the edge
X1 -> Xn.


Regards, Mike

_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/gef-dev


--=3D_alternative 0065BDD785256D7F_=3D
Content-Type: text/html; charset=3D"US-ASCII"


<br><font size=3D2 face=3D"sans-serif">Any suggestions on how to break =
cycles
without violating subgraph requirements? &nbsp;It seems like inverting
random edges could result in a situation where the bottom of a subgraph
is not below all of the nodes inside it.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">If possible, I was wondering if I =
could
write one algorithm which inverts edges, thus removing cycles, for both
directed and compound directed. &nbsp;If not possible, what is the =
technique
for compound graphs? &nbsp;Perhaps a modification to the greedy algorithm
(Graph Drawing 1999), which uses a left and right stack. &nbsp;The first
time a node N belonging to subgraph S is added to &quot;left&quot;, the
top boundary for its subgraph is added first. &nbsp;Something similar for
bottom boundaries.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">-Randy</font>
<br>
<br>
<br>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td>
<td><font size=3D1 face=3D"sans-serif"><b>&quot;Michael Forster&quot; =
&lt;forster@xxxxxxxxxxxxxxxxx&gt;</b></font>
<br><font size=3D1 face=3D"sans-serif">Sent by: gef-dev-admin@xxxxxxxxxxx</=
font>
<p><font size=3D1 face=3D"sans-serif">08/07/2003 05:11 PM</font>
<br><font size=3D1 face=3D"sans-serif">Please respond to gef-dev</font>
<td><font size=3D1 face=3D"Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
&nbsp; &nbsp; &nbsp; &nbsp;&lt;gef-dev@xxxxxxxxxxx&gt;</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; =
Subject:
&nbsp; &nbsp; &nbsp; &nbsp;RE: [gef-dev] CDAG layout algorithms</font></tab=
le>
<br>
<br>
<br><font size=3D2><tt>Hi,<br>
<br>
&gt; I've skimmed over your paper. &nbsp;The sub-optimal reodering <br>
&gt; shown in Figure 6 could be corrected by a final pass through <br>
&gt; the graph which exchanges &quot;adjacent pairs&quot; of nodes if it
<br>
&gt; improves the quality of the layout. <br>
<br>
Of course. This is just a minimal example where Sander's algorithm<br>
fails. So it is not surprising that a simple heuristic can solve this<br>
particular problem. But remember: It still stays a heuristic, and it<br>
does no solve the fundamental problem. So you will definitely get<br>
unneccessary crossings.<br>
<br>
&gt; My concern with preserving the containment hierarchy during <br>
&gt; the crossing reduction is that this prevents a node from <br>
&gt; gradually passing through a subgraph to which it doesn't <br>
&gt; belong. &nbsp;<br>
<br>
This does not happen, and this is proven (Well, the proof is sketched,<br>
at least :-) in the paper.<br>
<br>
&gt; It seems like using your algorithm, the node would <br>
&gt; have to jump across the whole subgraph (compound node) at <br>
&gt; once, or not at all. <br>
<br>
This is correct, and the nodes make these big jumps. If two subgraphss<br>
which are high in the subgraph hierarchy are exchanged while applying<br>
the crossing reduction to an enclosing subgraph or the root of the<br>
subgraph hierarchy, the dependent (base) nodes &quot;jump&quot; over the
whole<br>
other subgraph.<br>
<br>
I admit that my algorithm may be harder to understand and implement =
than<br>
Sander's. But it is better than Sander's by proof. It is even optimal =
if<br>
only considered according to a single rank (=3Dlayer=3Dlevel). This =
means,<br>
there will be only unnecessary crossings that come from the underlying<br>
2-level crossing reduction (These occur in both algorithms - the problem<br=
>
is NP-hard, so you cannot expect global optimality), but _no_ crossings<br>=

that come from the application to the clustered graph. Sander's<br>
application generates such crossings. So I am highly convinced that my<br>
algorithm performs better than Sander's. Of course, I am biased, and I<br>
do not have numbers to substantiate my opinion, but the theoretical<br>
results in my paper promise good practical results. By the way: I =
talked<br>
to Sander last year after my talk at the conference, and he admitted<br>
that my method is more promising than his quick-and-dirty solution.<br>
<br>
Note that I do not want to persuade you to use my algorithm, especially,<br=
>
if you are under deadline pressure and fully understand Sander's<br>
algorithm but not mine. On the contrary: I will be happy to have an<br>
implementation of Sander's algorithm to compare to mine in my thesis<br>
:-).<br>
<br>
By the way: Would it be possible, to have a look at your code? It will<br>
be published under the CPL anyway, right?<br>
 <br>
&gt; Here is a case <br>
&gt; where reversing the edge from a cycle is better than removing it.
<br>
&gt; <br>
&gt; Given Subgraph A with members a1, a2, a3 <br>
&gt; Given Subgraph B with members b1, b2, b3 <br>
&gt; And a node X. <br>
&gt; <br>
&gt; Ignoring all edges, here are the final rank orderings: <br>
&gt; a1 &nbsp; &nbsp; &nbsp; b1 <br>
&gt; a2 &nbsp; &nbsp; &nbsp; b2 <br>
&gt; b3 &nbsp;X &nbsp;a3 <br>
&gt; <br>
&gt; The two subgraphs are intertwined, with a random node falling <br>
&gt; between them. <br>
&gt; The cycle A -&gt; B -&gt; X -&gt; A exists. &nbsp;If you break X =
-&gt;
A, you <br>
&gt; then end up with last row of: <br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; a3 &nbsp;b3 &nbsp;X <br>
&gt; But, if you reverse it to be A-&gt;X, you have partial ordering <br>
&gt; A-&gt;X, and A-&gt;B, which allows for: <br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; a3 X b3 <br>
<br>
No, it does not, because you forgot the edge B -&gt; X, which still =
exists.<br>
<br>
In general: If you have a cycle<br>
<br>
 &nbsp; &nbsp;X1 -&gt; X2 -&gt; ... -&gt; Xn -&gt; X1<br>
<br>
and you break it up at Xn -&gt; X1, it does not matter whether the =
edge<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; X1 -&gt; Xn<br>
<br>
is inserted, because the partial ordering is transitive, and so Xn has<br>
to be right of X1 anyway. This means, the quality depends only on the<br>
concrete implementation of the topological ordering, but not on the =
edge<br>
X1 -&gt; Xn.<br>
<br>
<br>
Regards, Mike<br>
<br>
_______________________________________________<br>
gef-dev mailing list<br>
gef-dev@xxxxxxxxxxx<br>
http://dev.eclipse.org/mailman/listinfo/gef-dev<br>
</tt></font>
<br>
--=3D_alternative 0065BDD785256D7F_=3D--


-- __--__-- 

_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/gef-dev


End of gef-dev Digest



--__--__--

_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/gef-dev


End of gef-dev Digest



Back to the top