jgrapht-developers — A discussion list for JGraphT developers.

[jgrapht-developers] dumping adjacency and laplacian matrices

[Charles F. <cf...@us...>]

Hi,

Last week John invited me to join you, implementing myself some of the
long list of features that I recently requested. While I shall initially
be unable to implement at the same speed which I requested these
features, I do hope to make some contributions to JGraphT, which I have
already found to be enourmously useful, and which I anticipate using for
years to come.

John suggested that I announce my proposed changes on this mailing list
in an effort to solicit discussion on them prior to my implementation
efforts. I will thus start with the first piece of functionality which I
have already implemented externally, that I would like to add to
JGraphT.

Specifically, I would like to add the ability to dump graphs into
matrix representaitons which could in turn be analysed and manipulated
by external matrix software. You can read more about this idea in the
feature request number 1377955.

Sample output for the adjacency matrix would be:

1 2 1
1 3 1
2 1 1
3 1 1
3 4 1
4 3 1
5 5 0

Sample output for the Laplacian matrix would be:

1 1 2
1 2 -1
1 3 -1
2 2 1
2 1 -1
3 3 2
3 1 -1
3 4 -1
4 4 1
4 3 -1
5 5 0

The Laplacian could alternatively be in normalized form:

   http://mathworld.wolfram.com/LaplacianMatrix.html

John already suggested placing this in org._3pq.jgrapht.ext. Perhaps it
could be called MatrixExporter? Possible static method names would be
dumpAdjacencyMatrix and dumpLaplacianMatrix, but I'd love to hear other
ideas.

Any feedback on this proposed functionality is welcome.

thanks,
Charles

-- 
At intersections
Look each way
A harp sounds nice
But it's
Hard to play
Burma-Shave
http://burma-shave.org/jingles/1941/at_intersections

[jgrapht-developers] New branch ivins_Generics_Pre0_7_0 for generics and type-safety

[Hartmut B. <Har...@gm...>]

Hallo,

 

I've started extending the use of generics in jgrapht and getting rid of the
compiler warnings that result from changing to generics.

 

The changes are in a new branch called

ivins_Generics_Pre0_7_0

Aside from the generics and cleaning some of the warnings I added a new
interface DirEdge (should be DirectedEdge, but that name is {currently}
taken by the default implementation of the directed edge).

 

Getting rid of the warnings is important because it will make sure that the
compiler can/did find all potential type incompatibilities and that no
ClassCastException will be thrown afterwards.

 

Hartmut

[jgrapht-developers] Re: Jalopy update

[John V. S. <js...@gm...>]

Some breaking news:  there's a new open-source release of Jalopy
available, and it has been upgraded to support JDK 1.5!  This is a great
example of the open-source model working:  the project was abandonded
when the original author created a closed-source fork for commercial
purposes, but because enough people still needed an open-source version,
others stepped in to revive it.

I'll experiment with the open-source release to see if it's stable enough.

JVS

John V. Sichi wrote:
> One of the things we lost in moving JGraphT to JDK 1.5 was the ability
> to use the old open-source version of Jalopy.  To keep things simple, I
> have purchased a copy of the commercial one and will run it myself.  So,
> you don't need to worry about running Jalopy before checkin; I'll get
> around to modified files sooner or later (at least before each release).
> 
> I just checked in a reformat of the entire codebase.  As part of this, I
> changed the settings to match my style preferences in order to make my
> maintenance job easier.  Probably the most controversial change is to
> collapse imports (e.g. import java.io.*) instead of expanding them.
> These days IDE's all make it easy to see where a class is coming from
> wherever it is used, so I don't think maintaining the class-level
> clutter at the top of the file has any benefit.
> 
> JVS
> 

RE: [jgrapht-developers] Jalopy update

[Barak N. <ba...@3p...>]

> Let's leave this up to the maintainer's preference; when the time comes
> for me to hand off the torch, the next maintainer can review this
> convention.  Or if users start swearing at us, then we'll review it
> sooner.  :)

Ok, sure :)

Barak

Re: [jgrapht-developers] Jalopy update

[John V. S. <js...@gm...>]

Well, when you put it that way...

If I weren't so lazy, I would go write an Emacs macro to strip them all
right now.

JVS

Barak Naveh wrote:
>>I still think the explicit list of import is preferable.  To be
>>argumentative, modern IDE's do indeed show where the class is coming from,
>>but they also do clever folding :)... One can automatically unclutter the
>>import list by letting the IDE fold it (I think it's even the default in
>>Eclipse)...
> 
> 
> Oh, while we're there, the IDE claim could also be used to justify
> eliminating my 'm_' prefixing, because recent IDE's highlight member fields
> differently to local variables.  I think the prefixing is no longer
> justified.  Sorry John, I know you never liked the prefixing anyway.
> 
> Barak 
> 
> 
> 

Re: [jgrapht-developers] Jalopy update

[John V. S. <js...@gm...>]

I've heard the argument below often, but I've used the import pkg.*
convention on many projects before without any such troubles.  In
particular, the Farrago project has a jillion dependencies on
third-party libraries.  And when I upgrade one of them, I commonly have
to deal with semantic mismatches, but only very rarely with namespace
collisions, which are very easy to detect and resolve anyway.  I don't
see why it would be any different for your intrepid JGraphT user
charging off into JDK 1.6 or a new release of JGraph:  the real pain
during an upgrade always comes from semantic changes.

Interestingly, the Sun JDK source code uses a mix of the two conventions.

Let's leave this up to the maintainer's preference; when the time comes
for me to hand off the torch, the next maintainer can review this
convention.  Or if users start swearing at us, then we'll review it
sooner.  :)

JVS

Barak Naveh wrote:
> I still think the explicit list of import is preferable.  To be
> argumentative, modern IDE's do indeed show where the class is coming from,
> but they also do clever folding :)... One can automatically unclutter the
> import list by letting the IDE fold it (I think it's even the default in
> Eclipse)...  
> 
> But now seriously; I have a better reason.  
> Import such as java.util.* "contaminates" the namespace with unrelated
> classes that might cause name collision.  To demonstrate how this
> contamination can cause problems, let's suppose that Sun adds a
> java.util.UndirectedGraph interface in jdk 1.6, and let's also suppose, that
> JGraphT, for good reasons, does not immediately upgrade to 1.6 (we know it
> took a while to update to 1.5). 
> 
> Now, we, in JGraphT, program against 1.5 so everything compiles cheerfully,
> passes the unit tests, and we're happy and proud.  An enthusiastic developer
> who has already rushed to use 1.6 downloads JGraphT, attempts to compile it
> and... starts swearing...  The import section of, say, AbstractBaseGraph,
> contains:
> 
>   import java.util.*;
>   import org._3pq.jgrapht.*;
> 
> which leads to a name collision -- the code doesn't compile.  
> 
> If a name collision with Sun sounds imaginary, a collision with JGraph
> wouldn't be that hard to imagine.  Anyway, the use of wildcards for imports
> (regular or static) can cause problems that happen only in the "field" and
> can easily escape detection and correction in the "lab".  After painfully
> experiencing such problems, one is compelled to decide to never again use
> wildcards for imports, static or otherwise.  And if the clutter could be
> easily handled by the IDE, the decision comes with no sacrifice...
> 
> Would you reconsider?
> 
> Barak 
> 
> 
> 
> 

RE: [jgrapht-developers] Jalopy update

[Barak N. <ba...@3p...>]

> I still think the explicit list of import is preferable.  To be
> argumentative, modern IDE's do indeed show where the class is coming =
from,
> but they also do clever folding :)... One can automatically unclutter =
the
> import list by letting the IDE fold it (I think it's even the default =
in
> Eclipse)...

Oh, while we're there, the IDE claim could also be used to justify
eliminating my 'm_' prefixing, because recent IDE's highlight member =
fields
differently to local variables.  I think the prefixing is no longer
justified.  Sorry John, I know you never liked the prefixing anyway.

Barak=20

RE: [jgrapht-developers] Jalopy update

[Barak N. <ba...@3p...>]

> One of the things we lost in moving JGraphT to JDK 1.5 was the ability
> to use the old open-source version of Jalopy.  To keep things simple, =
I
> have purchased a copy of the commercial one and will run it myself.  =
So,
> you don't need to worry about running Jalopy before checkin; I'll get
> around to modified files sooner or later (at least before each =
release).

Btw, I think there is a cool feature of Jalopy that allows running it on =
the
server-side as a pre-checkin script.  If applicable, it could be useful =
--
that is, transparently format the code whenever a developer checks in.=20

> I just checked in a reformat of the entire codebase.  As part of this, =
I
> changed the settings to match my style preferences in order to make my
> maintenance job easier.  Probably the most controversial change is to
> collapse imports (e.g. import java.io.*) instead of expanding them.
> These days IDE's all make it easy to see where a class is coming from
> wherever it is used, so I don't think maintaining the class-level
> clutter at the top of the file has any benefit.

I still think the explicit list of import is preferable.  To be
argumentative, modern IDE's do indeed show where the class is coming =
from,
but they also do clever folding :)... One can automatically unclutter =
the
import list by letting the IDE fold it (I think it's even the default in
Eclipse)... =20

But now seriously; I have a better reason. =20
Import such as java.util.* "contaminates" the namespace with unrelated
classes that might cause name collision.  To demonstrate how this
contamination can cause problems, let's suppose that Sun adds a
java.util.UndirectedGraph interface in jdk 1.6, and let's also suppose, =
that
JGraphT, for good reasons, does not immediately upgrade to 1.6 (we know =
it
took a while to update to 1.5).=20

Now, we, in JGraphT, program against 1.5 so everything compiles =
cheerfully,
passes the unit tests, and we're happy and proud.  An enthusiastic =
developer
who has already rushed to use 1.6 downloads JGraphT, attempts to compile =
it
and... starts swearing...  The import section of, say, =
AbstractBaseGraph,
contains:

  import java.util.*;
  import org._3pq.jgrapht.*;

which leads to a name collision -- the code doesn't compile. =20

If a name collision with Sun sounds imaginary, a collision with JGraph
wouldn't be that hard to imagine.  Anyway, the use of wildcards for =
imports
(regular or static) can cause problems that happen only in the "field" =
and
can easily escape detection and correction in the "lab".  After =
painfully
experiencing such problems, one is compelled to decide to never again =
use
wildcards for imports, static or otherwise.  And if the clutter could be
easily handled by the IDE, the decision comes with no sacrifice...

Would you reconsider?

Barak=20

[jgrapht-developers] Jalopy update

[John V. S. <js...@gm...>]

One of the things we lost in moving JGraphT to JDK 1.5 was the ability
to use the old open-source version of Jalopy.  To keep things simple, I
have purchased a copy of the commercial one and will run it myself.  So,
you don't need to worry about running Jalopy before checkin; I'll get
around to modified files sooner or later (at least before each release).

I just checked in a reformat of the entire codebase.  As part of this, I
changed the settings to match my style preferences in order to make my
maintenance job easier.  Probably the most controversial change is to
collapse imports (e.g. import java.io.*) instead of expanding them.
These days IDE's all make it easy to see where a class is coming from
wherever it is used, so I don't think maintaining the class-level
clutter at the top of the file has any benefit.

JVS

Re: [jgrapht-developers] JGraphT backport

[John V. S. <js...@gm...>]

I was going to do that, but then I thought:

- Once we have multiple versions, it's probably better to name them 
explicitly to avoid confusion.

- This isn't the only painful JDK upgrade in history (look at 1.1->1.2), 
and somehow I doubt it's the last one.  For the painless ones, we can 
just avoid bumping the version number; this will indicate backwards 
compatibility.

JVS

Barak Naveh wrote:
>>jgrapht-jdk1.4.jar (retrowoven version)
>>jgrapht-jdk1.5.jar (standard compile)
> 
>  
> Actually, the standard compile could be simply called 'jgrapht.jar' to avoid
> the naming convention becoming obsolete with the jdk1.6 release.
> 
> 
> 
> 
> 

Re: [jgrapht-developers] JGraphT backport

[John V. S. <js...@gm...>]

Barak Naveh wrote:
>>jgrapht-jdk1.4.jar (retrowoven version)
>>jgrapht-jdk1.5.jar (standard compile)
> 
> 
> Such a naming convention indeed eases upgrading.  However, there should be a
> way to easily identify the version of each jar (if separated from the
> distribution).  Perhaps each jar should include a 'version.txt' file at its
> top-level; the 'version.txt' could be generated automatically and include
> the respective JGraphT version info.

Good point.  Instead of a separate version.txt, I have changed the build 
to burn the build/version information into the jar manifest.  I used the 
standard "Specification-Version" attribute for the version number, and 
for "Implementation-Version", appended the jdk1.4/jdk1.5 suffix as well.

JVS

RE: [jgrapht-developers] JGraphT backport

[Barak N. <bar...@us...>]

> jgrapht-jdk1.4.jar (retrowoven version)
> jgrapht-jdk1.5.jar (standard compile)
=20
Actually, the standard compile could be simply called 'jgrapht.jar' to =
avoid
the naming convention becoming obsolete with the jdk1.6 release.

RE: [jgrapht-developers] JGraphT backport

[Barak N. <bar...@us...>]

> - I created file etc/build.properties.template with the documented =
(but
> commented-out) property definitions in CVS.  In a distribution, this
> becomes etc/build.properties.  The reason I gave it a different name =
in
> CVS is to avoid developers accidentally editing it and committing
> site-specific changes.  Instead, developers should copy the template =
to
> etc/build.properties and edit that.  Distribution users can just edit
> etc/build.properties directly.

That's a good idea -- it allows developers to add their customized
etc/build.properties to their .cvsignore.

> In addition, I also made a change to the jar naming convention.  The =
jar
> name used to be based on the release version, but I have found this to
> be a pain in dependent projects, because it means with every upgrade I
> have to edit the dependent build file to reference the new version.
> Instead, the jar names are now:
>=20
> jgrapht-jdk1.4.jar (retrowoven version)
> jgrapht-jdk1.5.jar (standard compile)

Such a naming convention indeed eases upgrading.  However, there should =
be a
way to easily identify the version of each jar (if separated from the
distribution).  Perhaps each jar should include a 'version.txt' file at =
its
top-level; the 'version.txt' could be generated automatically and =
include
the respective JGraphT version info.

Barak=20

Re: [jgrapht-developers] JGraphT backport

[John V. S. <js...@gm...>]

In line with Barak's suggestions below, I made the following changes:

- Instead of customBuild.properties, build.xml now reads 
etc/build.properties (if it exists).

- I created file etc/build.properties.template with the documented (but 
commented-out) property definitions in CVS.  In a distribution, this 
becomes etc/build.properties.  The reason I gave it a different name in 
CVS is to avoid developers accidentally editing it and committing 
site-specific changes.  Instead, developers should copy the template to 
etc/build.properties and edit that.  Distribution users can just edit 
etc/build.properties directly.

- I renamed the property from retro.jre.dir to jre1.4.dir

In addition, I also made a change to the jar naming convention.  The jar 
name used to be based on the release version, but I have found this to 
be a pain in dependent projects, because it means with every upgrade I 
have to edit the dependent build file to reference the new version. 
Instead, the jar names are now:

jgrapht-jdk1.4.jar (retrowoven version)
jgrapht-jdk1.5.jar (standard compile)

README.html explains when to use one or the other or both depending on 
your compile/deploy dependencies.

JVS

Barak Naveh wrote:
> Come to think of it, maybe it would be useful to extend the idea and instead
> of having 'customBuild.properties', we can have 'build.properties'.  Such a
> file might help with all kinds of custom of builds (release, cvstag,...),
> present and future.
> 
> The build.properties could have the form of commented sections, one section
> for each alternative build (one for retro).  When someone wants to build a
> retro, he just uncomments the params in the retro section and fills in the
> paths according to the documented instruction within the 'build.properties'
> itself.  In such a way, custom builds can be a no-brainer.  Of course, the
> file in its distributed form contains only comments, so that a casual "ant
> all" on the distribution doesn't do funny things...
> 
> 
> A little naming suggestion:
> 
> 
>>retro.jre.dir=/path/to/jre1.4
> 
> 
> Since the only JREs supported here are 1.4*, I think a variable name such as
> 'jre1_4.dir' or 'jre1.4.dir' will be more self-explanatory. 
> 
> Barak 
> 
> 
> 
>>-----Original Message-----
>>
>>The JGraphT development version (0.7.0alpha) in CVS requires JDK 1.5 to
>>build, but I've just checked in backport support to allow it to run on
>>JRE 1.4.  To use it, install Retroweaver (and JRE 1.4), then create a
>>file named customBuild.properties in the same directory as build.xml and
>>add these two lines:
>>
>>retroweaver.dir=/path/to/full/distribution/of/retroweaver
>>retro.jre.dir=/path/to/jre1.4
>>
>>Then run ant.  The "all" target will perform a normal build/test/jar
>>sequence, and then run the backport (overwriting the class files in
>>place with their retrowoven versions).  Then it will re-run all tests
>>against JRE 1.4 to make sure that no dependencies on JRE 1.5 have crept
>>in.  Finally, it will create an extra jar with the retrowoven classes as
>>part of the distribution.
>>
>>If you have comments on this process, please let me know.
>>
>>JVS
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>jgrapht-developers mailing list
>>jgr...@li...
>>https://lists.sourceforge.net/lists/listinfo/jgrapht-developers
> 
> 
> 
> 

RE: [jgrapht-developers] JGraphT backport

[Barak N. <bar...@us...>]

Come to think of it, maybe it would be useful to extend the idea and =
instead
of having 'customBuild.properties', we can have 'build.properties'.  =
Such a
file might help with all kinds of custom of builds (release, =
cvstag,...),
present and future.

The build.properties could have the form of commented sections, one =
section
for each alternative build (such as retro).  When someone wants to build =
a
retro, he just uncomments the params in the retro section and fills in =
the
paths according to the documented instruction within the =
'build.properties'.
In such a way, custom builds can be relatively simple.  Of course, the =
file
in its distributed form should contain only comments, so that a casual =
"ant
all" on the distribution doesn't do funny things...


A little naming suggestion:

> retro.jre.dir=3D/path/to/jre1.4

Since the only JREs supported here are 1.4*, I think a variable name =
such as
'jre1_4.dir' or 'jre1.4.dir' will be more self-explanatory.=20

Barak=20



> -----Original Message-----
>=20
> The JGraphT development version (0.7.0alpha) in CVS requires JDK 1.5 =
to
> build, but I've just checked in backport support to allow it to run on
> JRE 1.4.  To use it, install Retroweaver (and JRE 1.4), then create a
> file named customBuild.properties in the same directory as build.xml =
and
> add these two lines:
>=20
> retroweaver.dir=3D/path/to/full/distribution/of/retroweaver
> retro.jre.dir=3D/path/to/jre1.4
>=20
> Then run ant.  The "all" target will perform a normal build/test/jar
> sequence, and then run the backport (overwriting the class files in
> place with their retrowoven versions).  Then it will re-run all tests
> against JRE 1.4 to make sure that no dependencies on JRE 1.5 have =
crept
> in.  Finally, it will create an extra jar with the retrowoven classes =
as
> part of the distribution.
>=20
> If you have comments on this process, please let me know.
>=20
> JVS
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> jgrapht-developers mailing list
> jgr...@li...
> https://lists.sourceforge.net/lists/listinfo/jgrapht-developers

[jgrapht-developers] JGraphT backport

[John V. S. <js...@gm...>]

The JGraphT development version (0.7.0alpha) in CVS requires JDK 1.5 to 
build, but I've just checked in backport support to allow it to run on 
JRE 1.4.  To use it, install Retroweaver (and JRE 1.4), then create a 
file named customBuild.properties in the same directory as build.xml and 
add these two lines:

retroweaver.dir=/path/to/full/distribution/of/retroweaver
retro.jre.dir=/path/to/jre1.4

Then run ant.  The "all" target will perform a normal build/test/jar 
sequence, and then run the backport (overwriting the class files in 
place with their retrowoven versions).  Then it will re-run all tests 
against JRE 1.4 to make sure that no dependencies on JRE 1.5 have crept 
in.  Finally, it will create an extra jar with the retrowoven classes as 
part of the distribution.

If you have comments on this process, please let me know.

JVS

Re: [jgrapht-developers] subclassing CrossComponetIterator

[John V. S. <js...@gm...>]

Sun's java.util provides classes like AbstractList and AbstractSet to 
make it very easy to whip up custom implementations of collection 
classes.  You only have to implement a few methods, and the base class 
does the rest.  And this way, if you want, you can optimize the 
complexity of the size() method, whereas if you only provided an 
iterator() method, then an algorithm needing the size would be forced to 
iterate and count.

Concerning the edgeSet() and vertexSet() methods of Graph, we have no 
plans to replace them.  The two methods you mention (iterator and size) 
are exactly the ones you need to override in AbstractSet, so it's 
already very easy to produce custom implementations.  We had two very 
good reasons for declaring these methods the way they are:

1) In every textbook on graph theory, a graph is defined in terms of a 
pair (V,E) where V is a set of vertices and E is a set of edges.  So, a 
good graph interface should stick as close as possible to this 
formalism.  Since Sun already provides the Set concept, we use it directly.

2) Sets are useful for other operations such as membership test, union, 
intersect, set equality test, etc.  For example, if we did what you 
suggested, then we'd have to clutter up the interface with more methods 
like containsEdge.  Even though you don't currently use these methods, 
other users may (including your future self).

I appreciate your critique, and I hope this discussion helps to explain 
these aspects of the library's design.

JVS

gu boulmi wrote:
> Why not, but if I want the returned list to be
> coherent, I must implement not only the #iterator()
> method but also the others methods of the List
> interface such that #size() whose complexity would
> become O(size of the list) because we would have to
> iterate over all elements to know the size.
> 
> Furthermore the complexity of Graph#vertexSet and
> Graph#edgeSet would become O(number of vertices) and
> O(number of edges) for the same reason.
> 
> 
> Concerning the Graph#edgeSet() method, what about
> replacing it by 2 methods #edgeIterator and
> #getNbEdges ? Actually, from my point of view I use
> the edgeSet() method either to know the number of
> edges or to iterate ver them.
> With this modification if someone wants to store the
> edges differently, it would be easier to implement
> only these 2 methods instead of implementing all the
> methods of the Set interface.
> 
> 
> Best regards
> 
> Guillaume
> 
> 
> --- "John V. Sichi" <js...@gm...> a écrit :
> 
> 
>>If the complexity of edgesOf is your concern, that's
>>easy to address. 
>>Instead of returning a standard implementation such
>>as ArrayList, your 
>>custom Subgraph class can return a custom List
>>implementation which 
>>defers the filtering process to its Iterator
>>implementation.
>>
>>JVS
>>
>>gu boulmi wrote:
>>
>>>Why not, it seems easy.
>>>Nevertheless I think it will be slow.
>>>Indeed, whereas the complexity of
>>>AbstractBaseGraph#edgesOf is O(1), the complexity
>>
>>of
>>
>>>Subgraph#edgesOf is O(number of outgoing edges in
>>
>>the
>>
>>>super-graph) and I care about time consuming.
>>>
>>>A method edgesOfIterator (to iterate over outgoing
>>>edges like an Iterator) in Graph could allow us to
>>>save time when iterating over edges of a vertex.
>>>
>>>Furthermore, it is not exactly what I want because
>>>"forbidden vertices" are not vertices that are not
>>
>>in
>>
>>>the subgraph. In contrary they are in the graph
>>
>>but
>>
>>>such that I do not want any path to cross them
>>
>>when
>>
>>>using a CrossComponentIterator : a vertex could
>>
>>not be
>>
>>>reached via a forbidden vertex (except if the
>>>forbidden vertex is the source vertex).
>>>
>>>I will appreciate any help.
>>>Thanks.
>>>
>>>
>>>
>>>--- "John V. Sichi" <js...@gm...> a écrit :
>>>
>>>
>>>
>>>>Instead of subclassing the iterator, have you
>>>>considered using a 
>>>>Subgraph instead?  It sounds like that's really
>>
>>what
>>
>>>>you want. 
>>>>Subclassing the iterator would be clumsy, because
>>>>there are already 
>>>>subclasses for the various traversal types (DFS,
>>>>BFS, CFS).
>>>>
>>>>The existing Subgraph implementation is "additive"
>>>>in the sense that you 
>>>>give it an underlying graph and a mask for which
>>>>vertices and edges you 
>>>>want to see.  For your purposes, it sounds like a
>>>>"subtractive" subgraph 
>>>>might be more appropriate; you would give it a
>>
>>mask
>>
>>>>for which vertices 
>>>>and edges you DON'T want to see.
>>>>
>>>>JVS
>>>>
>>>>gu boulmi wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>>I want to subclass CrossComponetIterator in order
>>>>
>>>>to
>>>>
>>>>
>>>>>take into account forbidden vertices and
>>
>>forbidden
>>
>>>>>edges.
>>>>>
>>>>>Actually, here what I want :
>>>>>- I do not want to change the structure of the
>>>>
>>>>graph
>>>>
>>>>
>>>>>via removeVertex and remmoveEdge because it is
>>>>
>>>>slow
>>>>
>>>>
>>>>>(regarding to CPU time).
>>>>>- I want to prevent somme edges from being
>>>>
>>>>traversed
>>>>
>>>>
>>>>>and I say "this edge is forbidden".
>>>>>- For some vertices I do not want at all to
>>>>
>>>>examine
>>>>
>>>>
>>>>>its edges ant I say "this vertex is forbidden".
>>>>>
>>>>>Here ideas I have to tackle this matter (but it
>>>>
>>>>will
>>>>
>>>>
>>>>>need to modify few lines of the core jgrapht
>>>>
>>>>source
>>>>
>>>>
>>>>>code) :
>>>>>- for the 3d point : let the method
>>>>>addUnseenChildrenOf be protected (instead of
>>>>
>>>>private)
>>>>
>>>>
>>>>>such that I could override it like that : "if
>>>>
>>>>vertex
>>>>
>>>>
>>>>>is forbidden then do nothing else
>>>>>super.addUnseenChildrenOf".
>>>>>- for the 2d point : add a protected method
>>>>>"edgesOfIterator(Vertex)" and a graph member
>>>>
>>>>instead
>>>>
>>>>
>>>>>of "Specifics" classes (each time we used
>>>>
>>>>Specifics,
>>>>
>>>>
>>>>>it is to iterate over the edges of a vertex
>>>>
>>>>depending
>>>>
>>>>
>>>>>on the directed/undirected feature of the graph).
>>>>
>>>>Thus
>>>>
>>>>
>>>>>I would have to override this "edgesOfIterator"
>>>>
>>>>and
>>>>
>>>>
>>>>>ignore forbidden edges when returning the "next"
>>>>
>>>>edge.
>>>>
>>>>
>>>>>What do you think about it ?
>>>>>If you agree with me, I would appreciate if these
>>>>>changes could be in the next 0.6 release.
>>>>>
>>>>>Thanks
>>>>>
>>>>>Guillaume
>>>>>
>>>>>
>>>>>	
>>>>>
>>>>>	
>>>>>		
>>>>>
>>>>
> ___________________________________________________________________________
> 
>>>>>Appel audio GRATUIT partout dans le monde avec le
>>>>
>>>>nouveau Yahoo! Messenger 
>>>>
>>>>
>>>>>Téléchargez cette version sur
>>>>
>>>>http://fr.messenger.yahoo.com
>>>>
>>>>
>>>>>
> -------------------------------------------------------
> 
>>>>>SF.Net email is sponsored by: Discover Easy Linux
>>>>
>>>>Migration Strategies
>>>>
>>>>>from IBM. Find simple to follow Roadmaps,
>>>>
>>>>straightforward articles,
>>>>
>>>>
>>>>>informative Webcasts and more! Get everything you
>>>>
>>>>need to get up to
>>>>
>>>>
>>>>>speed, fast.
>>>>
> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> 
>>>>>_______________________________________________
>>>>>jgrapht-developers mailing list
>>>>>jgr...@li...
>>>>>
>>>>
> https://lists.sourceforge.net/lists/listinfo/jgrapht-developers
> 
> === message truncated ===
> 
> 
> 
> 	
> 
> 	
> 		
> ___________________________________________________________________________ 
> Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
> Téléchargez cette version sur http://fr.messenger.yahoo.com
> 

Re: [jgrapht-developers] subclassing CrossComponetIterator

[gu b. <bou...@ya...>]

Why not, but if I want the returned list to be
coherent, I must implement not only the #iterator()
method but also the others methods of the List
interface such that #size() whose complexity would
become O(size of the list) because we would have to
iterate over all elements to know the size.

Furthermore the complexity of Graph#vertexSet and
Graph#edgeSet would become O(number of vertices) and
O(number of edges) for the same reason.


Concerning the Graph#edgeSet() method, what about
replacing it by 2 methods #edgeIterator and
#getNbEdges ? Actually, from my point of view I use
the edgeSet() method either to know the number of
edges or to iterate ver them.
With this modification if someone wants to store the
edges differently, it would be easier to implement
only these 2 methods instead of implementing all the
methods of the Set interface.


Best regards

Guillaume


--- "John V. Sichi" <js...@gm...> a écrit :

> If the complexity of edgesOf is your concern, that's
> easy to address. 
> Instead of returning a standard implementation such
> as ArrayList, your 
> custom Subgraph class can return a custom List
> implementation which 
> defers the filtering process to its Iterator
> implementation.
> 
> JVS
> 
> gu boulmi wrote:
> > Why not, it seems easy.
> > Nevertheless I think it will be slow.
> > Indeed, whereas the complexity of
> > AbstractBaseGraph#edgesOf is O(1), the complexity
> of
> > Subgraph#edgesOf is O(number of outgoing edges in
> the
> > super-graph) and I care about time consuming.
> > 
> > A method edgesOfIterator (to iterate over outgoing
> > edges like an Iterator) in Graph could allow us to
> > save time when iterating over edges of a vertex.
> > 
> > Furthermore, it is not exactly what I want because
> > "forbidden vertices" are not vertices that are not
> in
> > the subgraph. In contrary they are in the graph
> but
> > such that I do not want any path to cross them
> when
> > using a CrossComponentIterator : a vertex could
> not be
> > reached via a forbidden vertex (except if the
> > forbidden vertex is the source vertex).
> > 
> > I will appreciate any help.
> > Thanks.
> > 
> > 
> > 
> > --- "John V. Sichi" <js...@gm...> a écrit :
> > 
> > 
> >>Instead of subclassing the iterator, have you
> >>considered using a 
> >>Subgraph instead?  It sounds like that's really
> what
> >>you want. 
> >>Subclassing the iterator would be clumsy, because
> >>there are already 
> >>subclasses for the various traversal types (DFS,
> >>BFS, CFS).
> >>
> >>The existing Subgraph implementation is "additive"
> >>in the sense that you 
> >>give it an underlying graph and a mask for which
> >>vertices and edges you 
> >>want to see.  For your purposes, it sounds like a
> >>"subtractive" subgraph 
> >>might be more appropriate; you would give it a
> mask
> >>for which vertices 
> >>and edges you DON'T want to see.
> >>
> >>JVS
> >>
> >>gu boulmi wrote:
> >>
> >>>  Hi,
> >>>
> >>>I want to subclass CrossComponetIterator in order
> >>
> >>to
> >>
> >>>take into account forbidden vertices and
> forbidden
> >>>edges.
> >>>
> >>>Actually, here what I want :
> >>>- I do not want to change the structure of the
> >>
> >>graph
> >>
> >>>via removeVertex and remmoveEdge because it is
> >>
> >>slow
> >>
> >>>(regarding to CPU time).
> >>>- I want to prevent somme edges from being
> >>
> >>traversed
> >>
> >>>and I say "this edge is forbidden".
> >>>- For some vertices I do not want at all to
> >>
> >>examine
> >>
> >>>its edges ant I say "this vertex is forbidden".
> >>>
> >>>Here ideas I have to tackle this matter (but it
> >>
> >>will
> >>
> >>>need to modify few lines of the core jgrapht
> >>
> >>source
> >>
> >>>code) :
> >>>- for the 3d point : let the method
> >>>addUnseenChildrenOf be protected (instead of
> >>
> >>private)
> >>
> >>>such that I could override it like that : "if
> >>
> >>vertex
> >>
> >>>is forbidden then do nothing else
> >>>super.addUnseenChildrenOf".
> >>>- for the 2d point : add a protected method
> >>>"edgesOfIterator(Vertex)" and a graph member
> >>
> >>instead
> >>
> >>>of "Specifics" classes (each time we used
> >>
> >>Specifics,
> >>
> >>>it is to iterate over the edges of a vertex
> >>
> >>depending
> >>
> >>>on the directed/undirected feature of the graph).
> >>
> >>Thus
> >>
> >>>I would have to override this "edgesOfIterator"
> >>
> >>and
> >>
> >>>ignore forbidden edges when returning the "next"
> >>
> >>edge.
> >>
> >>>What do you think about it ?
> >>>If you agree with me, I would appreciate if these
> >>>changes could be in the next 0.6 release.
> >>>
> >>>Thanks
> >>>
> >>>Guillaume
> >>>
> >>>
> >>>	
> >>>
> >>>	
> >>>		
> >>>
> >>
> >
>
___________________________________________________________________________
> > 
> >>>Appel audio GRATUIT partout dans le monde avec le
> >>
> >>nouveau Yahoo! Messenger 
> >>
> >>>Téléchargez cette version sur
> >>
> >>http://fr.messenger.yahoo.com
> >>
> >>>
> >>>
> >
>
-------------------------------------------------------
> > 
> >>>SF.Net email is sponsored by: Discover Easy Linux
> >>
> >>Migration Strategies
> >>
> >>>from IBM. Find simple to follow Roadmaps,
> >>
> >>straightforward articles,
> >>
> >>>informative Webcasts and more! Get everything you
> >>
> >>need to get up to
> >>
> >>>speed, fast.
> >>
> >
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > 
> >>>_______________________________________________
> >>>jgrapht-developers mailing list
> >>>jgr...@li...
> >>>
> >>
> >
>
https://lists.sourceforge.net/lists/listinfo/jgrapht-developers
> 
=== message truncated ===



	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

[jgrapht-developers] JGraphT role changes

[Barak N. <bar...@us...>]

Dear JGraphT community,

I started JGraphT because I needed a graph library and no existing =
library
suited my needs.  I needed high performance graphs with low memory
consumption, and wanted the vertices to be of ANY type (annoyingly, many
libraries require the vertices to implement some Vertex interface). =20

At some point I realized that others might find JGraphT useful, so I =
made
the project open-source.  People indeed used it, reported bugs, =
requested
features, and contributed code.  Some even joined in and the whole thing
became a lot more fun than I anticipated!  The quality of the library =
has
improved continuously thanks to the received contributions and criticism =
--
it was a very convincing example how open source development produces =
better
software!

In the last year I became less and less available to admin JGraphT.  =
This
situation is unlikely to change in the near future, so we are making a =
role
change.  John V. Sichi, who has been a JGraphT developer and a co-admin =
for
a long time, is now taking the lead.  John is now the chief maintainer =
of
JGraphT, and although I'm staying involved, you should address project
issues to John.

JGraphT is going forward!  Version 0.6.0 was recently released and =
version
0.7.0 that will support Generics is now cooking...  The move to Java 5.0 =
is
thanks to the contribution of Christian Hammer.  If you can't wait for =
the
new candies, you might want to lend a hand and help making 0.7.0 ready
sooner...
 =20
Thanks to everyone for making it so much fun, and special thanks to John =
V.
Sichi who volunteered to lead JGraphT onwards.

Yours,
Barak Naveh

[jgrapht-developers] JDK 1.5 support under development in CVS

[John V. S. <js...@gm...>]

Christian Hammer has submitted changes to the core JGraphT data 
structures to take advantage of JDK 1.5 language features, in particular 
generics.  This will become the basis for JGraphT 0.7.0.

If you check out the latest from CVS, you'll need to start using JDK 1.5 
to compile.  Backwards compatibility support for running on JVM 1.4 is 
planned via the RetroWeaver project.

If you'd like to help out with the next release, there are a number of 
subpackages of org._3pq.jgrapht (e.g. generate, ext) which should be 
updated with support for generics, as well as the entire testsrc 
directory (the goal should be to build without any -Xlint:unchecked 
warnings).

JVS

[jgrapht-developers] JGraphT 0.6.0

[John V. S. <js...@gm...>]

At long last, JGraphT version 0.6.0 has been released and is now
available to download from http://jgrapht.sf.net. Please address any
problems with the release to me.

Enjoy,
JVS

Re: [jgrapht-developers] subclassing CrossComponetIterator

[John V. S. <js...@gm...>]

If the complexity of edgesOf is your concern, that's easy to address. 
Instead of returning a standard implementation such as ArrayList, your 
custom Subgraph class can return a custom List implementation which 
defers the filtering process to its Iterator implementation.

JVS

gu boulmi wrote:
> Why not, it seems easy.
> Nevertheless I think it will be slow.
> Indeed, whereas the complexity of
> AbstractBaseGraph#edgesOf is O(1), the complexity of
> Subgraph#edgesOf is O(number of outgoing edges in the
> super-graph) and I care about time consuming.
> 
> A method edgesOfIterator (to iterate over outgoing
> edges like an Iterator) in Graph could allow us to
> save time when iterating over edges of a vertex.
> 
> Furthermore, it is not exactly what I want because
> "forbidden vertices" are not vertices that are not in
> the subgraph. In contrary they are in the graph but
> such that I do not want any path to cross them when
> using a CrossComponentIterator : a vertex could not be
> reached via a forbidden vertex (except if the
> forbidden vertex is the source vertex).
> 
> I will appreciate any help.
> Thanks.
> 
> 
> 
> --- "John V. Sichi" <js...@gm...> a écrit :
> 
> 
>>Instead of subclassing the iterator, have you
>>considered using a 
>>Subgraph instead?  It sounds like that's really what
>>you want. 
>>Subclassing the iterator would be clumsy, because
>>there are already 
>>subclasses for the various traversal types (DFS,
>>BFS, CFS).
>>
>>The existing Subgraph implementation is "additive"
>>in the sense that you 
>>give it an underlying graph and a mask for which
>>vertices and edges you 
>>want to see.  For your purposes, it sounds like a
>>"subtractive" subgraph 
>>might be more appropriate; you would give it a mask
>>for which vertices 
>>and edges you DON'T want to see.
>>
>>JVS
>>
>>gu boulmi wrote:
>>
>>>  Hi,
>>>
>>>I want to subclass CrossComponetIterator in order
>>
>>to
>>
>>>take into account forbidden vertices and forbidden
>>>edges.
>>>
>>>Actually, here what I want :
>>>- I do not want to change the structure of the
>>
>>graph
>>
>>>via removeVertex and remmoveEdge because it is
>>
>>slow
>>
>>>(regarding to CPU time).
>>>- I want to prevent somme edges from being
>>
>>traversed
>>
>>>and I say "this edge is forbidden".
>>>- For some vertices I do not want at all to
>>
>>examine
>>
>>>its edges ant I say "this vertex is forbidden".
>>>
>>>Here ideas I have to tackle this matter (but it
>>
>>will
>>
>>>need to modify few lines of the core jgrapht
>>
>>source
>>
>>>code) :
>>>- for the 3d point : let the method
>>>addUnseenChildrenOf be protected (instead of
>>
>>private)
>>
>>>such that I could override it like that : "if
>>
>>vertex
>>
>>>is forbidden then do nothing else
>>>super.addUnseenChildrenOf".
>>>- for the 2d point : add a protected method
>>>"edgesOfIterator(Vertex)" and a graph member
>>
>>instead
>>
>>>of "Specifics" classes (each time we used
>>
>>Specifics,
>>
>>>it is to iterate over the edges of a vertex
>>
>>depending
>>
>>>on the directed/undirected feature of the graph).
>>
>>Thus
>>
>>>I would have to override this "edgesOfIterator"
>>
>>and
>>
>>>ignore forbidden edges when returning the "next"
>>
>>edge.
>>
>>>What do you think about it ?
>>>If you agree with me, I would appreciate if these
>>>changes could be in the next 0.6 release.
>>>
>>>Thanks
>>>
>>>Guillaume
>>>
>>>
>>>	
>>>
>>>	
>>>		
>>>
>>
> ___________________________________________________________________________
> 
>>>Appel audio GRATUIT partout dans le monde avec le
>>
>>nouveau Yahoo! Messenger 
>>
>>>Téléchargez cette version sur
>>
>>http://fr.messenger.yahoo.com
>>
>>>
>>>
> -------------------------------------------------------
> 
>>>SF.Net email is sponsored by: Discover Easy Linux
>>
>>Migration Strategies
>>
>>>from IBM. Find simple to follow Roadmaps,
>>
>>straightforward articles,
>>
>>>informative Webcasts and more! Get everything you
>>
>>need to get up to
>>
>>>speed, fast.
>>
> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> 
>>>_______________________________________________
>>>jgrapht-developers mailing list
>>>jgr...@li...
>>>
>>
> https://lists.sourceforge.net/lists/listinfo/jgrapht-developers
> 
>>
>>
> -------------------------------------------------------
> 
>>SF.Net email is sponsored by: Discover Easy Linux
>>Migration Strategies
>>from IBM. Find simple to follow Roadmaps,
>>straightforward articles,
>>informative Webcasts and more! Get everything you
>>need to get up to
>>speed, fast.
>>
> 
> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> 
>>_______________________________________________
>>jgrapht-developers mailing list
>>jgr...@li...
>>
> 
> https://lists.sourceforge.net/lists/listinfo/jgrapht-developers
> 
> 
> 
> 
> 	
> 
> 	
> 		
> ___________________________________________________________________________ 
> Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
> Téléchargez cette version sur http://fr.messenger.yahoo.com
> 

Re: [jgrapht-developers] subclassing CrossComponetIterator

[gu b. <bou...@ya...>]

Why not, it seems easy.
Nevertheless I think it will be slow.
Indeed, whereas the complexity of
AbstractBaseGraph#edgesOf is O(1), the complexity of
Subgraph#edgesOf is O(number of outgoing edges in the
super-graph) and I care about time consuming.

A method edgesOfIterator (to iterate over outgoing
edges like an Iterator) in Graph could allow us to
save time when iterating over edges of a vertex.

Furthermore, it is not exactly what I want because
"forbidden vertices" are not vertices that are not in
the subgraph. In contrary they are in the graph but
such that I do not want any path to cross them when
using a CrossComponentIterator : a vertex could not be
reached via a forbidden vertex (except if the
forbidden vertex is the source vertex).

I will appreciate any help.
Thanks.



--- "John V. Sichi" <js...@gm...> a écrit :

> Instead of subclassing the iterator, have you
> considered using a 
> Subgraph instead?  It sounds like that's really what
> you want. 
> Subclassing the iterator would be clumsy, because
> there are already 
> subclasses for the various traversal types (DFS,
> BFS, CFS).
> 
> The existing Subgraph implementation is "additive"
> in the sense that you 
> give it an underlying graph and a mask for which
> vertices and edges you 
> want to see.  For your purposes, it sounds like a
> "subtractive" subgraph 
> might be more appropriate; you would give it a mask
> for which vertices 
> and edges you DON'T want to see.
> 
> JVS
> 
> gu boulmi wrote:
> >   Hi,
> > 
> > I want to subclass CrossComponetIterator in order
> to
> > take into account forbidden vertices and forbidden
> > edges.
> > 
> > Actually, here what I want :
> > - I do not want to change the structure of the
> graph
> > via removeVertex and remmoveEdge because it is
> slow
> > (regarding to CPU time).
> > - I want to prevent somme edges from being
> traversed
> > and I say "this edge is forbidden".
> > - For some vertices I do not want at all to
> examine
> > its edges ant I say "this vertex is forbidden".
> > 
> > Here ideas I have to tackle this matter (but it
> will
> > need to modify few lines of the core jgrapht
> source
> > code) :
> > - for the 3d point : let the method
> > addUnseenChildrenOf be protected (instead of
> private)
> > such that I could override it like that : "if
> vertex
> > is forbidden then do nothing else
> > super.addUnseenChildrenOf".
> > - for the 2d point : add a protected method
> > "edgesOfIterator(Vertex)" and a graph member
> instead
> > of "Specifics" classes (each time we used
> Specifics,
> > it is to iterate over the edges of a vertex
> depending
> > on the directed/undirected feature of the graph).
> Thus
> > I would have to override this "edgesOfIterator"
> and
> > ignore forbidden edges when returning the "next"
> edge.
> > 
> > What do you think about it ?
> > If you agree with me, I would appreciate if these
> > changes could be in the next 0.6 release.
> > 
> > Thanks
> > 
> > Guillaume
> > 
> > 
> > 	
> > 
> > 	
> > 		
> >
>
___________________________________________________________________________
> 
> > Appel audio GRATUIT partout dans le monde avec le
> nouveau Yahoo! Messenger 
> > Téléchargez cette version sur
> http://fr.messenger.yahoo.com
> > 
> > 
> >
>
-------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> > from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> > informative Webcasts and more! Get everything you
> need to get up to
> > speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > jgrapht-developers mailing list
> > jgr...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/jgrapht-developers
> > 
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> informative Webcasts and more! Get everything you
> need to get up to
> speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> jgrapht-developers mailing list
> jgr...@li...
>
https://lists.sourceforge.net/lists/listinfo/jgrapht-developers
> 



	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: [jgrapht-developers] subclassing CrossComponetIterator

[John V. S. <js...@gm...>]

Instead of subclassing the iterator, have you considered using a 
Subgraph instead?  It sounds like that's really what you want. 
Subclassing the iterator would be clumsy, because there are already 
subclasses for the various traversal types (DFS, BFS, CFS).

The existing Subgraph implementation is "additive" in the sense that you 
give it an underlying graph and a mask for which vertices and edges you 
want to see.  For your purposes, it sounds like a "subtractive" subgraph 
might be more appropriate; you would give it a mask for which vertices 
and edges you DON'T want to see.

JVS

gu boulmi wrote:
>   Hi,
> 
> I want to subclass CrossComponetIterator in order to
> take into account forbidden vertices and forbidden
> edges.
> 
> Actually, here what I want :
> - I do not want to change the structure of the graph
> via removeVertex and remmoveEdge because it is slow
> (regarding to CPU time).
> - I want to prevent somme edges from being traversed
> and I say "this edge is forbidden".
> - For some vertices I do not want at all to examine
> its edges ant I say "this vertex is forbidden".
> 
> Here ideas I have to tackle this matter (but it will
> need to modify few lines of the core jgrapht source
> code) :
> - for the 3d point : let the method
> addUnseenChildrenOf be protected (instead of private)
> such that I could override it like that : "if vertex
> is forbidden then do nothing else
> super.addUnseenChildrenOf".
> - for the 2d point : add a protected method
> "edgesOfIterator(Vertex)" and a graph member instead
> of "Specifics" classes (each time we used Specifics,
> it is to iterate over the edges of a vertex depending
> on the directed/undirected feature of the graph). Thus
> I would have to override this "edgesOfIterator" and
> ignore forbidden edges when returning the "next" edge.
> 
> What do you think about it ?
> If you agree with me, I would appreciate if these
> changes could be in the next 0.6 release.
> 
> Thanks
> 
> Guillaume
> 
> 
> 	
> 
> 	
> 		
> ___________________________________________________________________________ 
> Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
> Téléchargez cette version sur http://fr.messenger.yahoo.com
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> jgrapht-developers mailing list
> jgr...@li...
> https://lists.sourceforge.net/lists/listinfo/jgrapht-developers
> 

[jgrapht-developers] subclassing CrossComponetIterator

[gu b. <bou...@ya...>]

  Hi,

I want to subclass CrossComponetIterator in order to
take into account forbidden vertices and forbidden
edges.

Actually, here what I want :
- I do not want to change the structure of the graph
via removeVertex and remmoveEdge because it is slow
(regarding to CPU time).
- I want to prevent somme edges from being traversed
and I say "this edge is forbidden".
- For some vertices I do not want at all to examine
its edges ant I say "this vertex is forbidden".

Here ideas I have to tackle this matter (but it will
need to modify few lines of the core jgrapht source
code) :
- for the 3d point : let the method
addUnseenChildrenOf be protected (instead of private)
such that I could override it like that : "if vertex
is forbidden then do nothing else
super.addUnseenChildrenOf".
- for the 2d point : add a protected method
"edgesOfIterator(Vertex)" and a graph member instead
of "Specifics" classes (each time we used Specifics,
it is to iterate over the edges of a vertex depending
on the directed/undirected feature of the graph). Thus
I would have to override this "edgesOfIterator" and
ignore forbidden edges when returning the "next" edge.

What do you think about it ?
If you agree with me, I would appreciate if these
changes could be in the next 0.6 release.

Thanks

Guillaume


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com