How to represent connected components? Dr. Arne Babenhauserheide (03 Sep 2023 11:11 UTC)
Re: How to represent connected components? John Cowan (03 Sep 2023 15:20 UTC)
Re: How to represent connected components? Arthur A. Gleckler (03 Sep 2023 16:29 UTC)
Re: How to represent connected components? Jakob Wuhrer (03 Sep 2023 19:27 UTC)
Re: How to represent connected components? Dr. Arne Babenhauserheide (04 Sep 2023 08:26 UTC)

Re: How to represent connected components? Dr. Arne Babenhauserheide 04 Sep 2023 07:57 UTC

> Hi,
>
> "Dr. Arne Babenhauserheide" <xxxxxx@web.de> writes:
>> one topic that came up in the discussion about finishing topological
>> sorting is to provide a way to calculate the strongly connected
>> components.
>>
>> How should we represent these?

>> Is '(0 0 0 3 3 5 5 7) understandable?
>>
>> Should we provide bags of elements instead? '(0 1 2)(3 4)(5 6)(7)

John Cowan <xxxxxx@ccil.org> writes:
> I think the latter would be better, although either will do.

"Arthur A. Gleckler" <xxxxxx@speechcode.com> writes:
> The latter is certainly clearer.

Jakob Wuhrer <xxxxxx@gmail.com> writes:
> I would personally prefer a function that computes the strongly
> connected components as lists of vertices '((0 1 2) (3 4) (5 6) (7)) (or
> as sets of vertices)

Then I’ll do that. Thank you for your answers!

> though there may be value in providing both such a
> function and a function that computes '(0 0 0 3 3 5 5 7).

> It'd also be great if there were a way to compute connected components,
> but that may be out of scope for this srfi
>
> That brings me to another, semi-related question: are there (pre)srfis
> to convert between / abstract over different representations and types
> of graphs?  I was unable to find anything with some cursory googling,
> but it seems like something like that could be quite useful

Do you mean graphs that are optimized for some algorithms?

Here I only implemented conversion from and to edgelists, because that’s
how it’s easiest for me to understand graphs and it is a canonical
representation used (and exported) by many tools.

> And finally: Would creating a "comparator" (as in srfi 128) of the
> generated order fall within the scope of this srfi?

Would this require making a comparator with a procedure that takes the
graph and caches the result for quick access?

In my opinion it is almost always a good idea to add compatibility to
other SRFI’s, so if it can be done well I think that could be a good
addition.

Maybe (make-topological-comparator graph)?

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de