[flagged]
It would have been slightly weird terminology even back then; it seems to have always been much more common to use the word 'children'.
Data structures as topological spaces (2002) [pdf]
11–20 of 48 posts
Re: Data structures as topological spaces (2002) [pdf]
#12> So, the expression
> 1, 1+1, 2+1, ():set
> builds the set with the three elements 1, 2 and 3
Regarding the "():set" part, and the "():something" idiom repeating in the article, is that from the same competition for the most absurd syntax where Golang got most of its awkwardness?
Re: Data structures as topological spaces (2002) [pdf]
#13[flagged]
It would have been slightly weird terminology even back then; it seems to have always been much more common to use the word 'children'.
I suspect that English isn't the first language of the authors and there has been a translation from a language where all nouns are gendered. The phrase "an hexagon" also suggests that they don't pronounce 'h'.
Re: Data structures as topological spaces (2002) [pdf]
#14How is this fundamentally different than considering data structures as graphs?
Graphs are discrete, topologies are potentially continuous. Moreover, you can do different things with them such as create homeomorphisms to another topology much more easily than you can create bijections between graphs. In general, continuity lets you assume things that are impossible in discrete spaces. For example, many optimization problems are really easy in continuous spaces but really hard in discrete ones (l…
> Moreover, you can do different things with them such as create homeomorphisms to another topology much more easily than you can create bijections between graphs. In general, continuity lets you assume things that are impossible in discrete spaces.
If you argue with more generality: why not consider sites (and, relatedly, topoi) instead of topological spaces then:
Re: Data structures as topological spaces (2002) [pdf]
#15It feels like the following PDF better expresses what they're trying to accomplish.
http://mgs.spatial-computing.org/PUBLICATIONS/lami-RR72--com...
As far as I can tell, they're trying to model things like chemical reactions (and other stuff) where given a bunch of "stuff" in some solution it will combine with other "stuff" if it's in the same topological neighborhood (which I think is basically the idea that ALL of the "stuff" doesn't have to be next to each other b/c if you let a solution just sit there eventually reactions are going to react).
It's kind of neat, but their website seems to indicate that it is not being actively supported. Or at the very least they don't seem to have any reason to make publicly available documentation after since around 2010.
EDIT: So for example, you could use their "trans" transform primitive to implement conway's game of life by defining the birth rule as a pattern of an empty cell with three alive cells and a transform that results in the empty cell being alive and the alive cells being the same. The death rules in similar fashion. Neighbor here would be defined as being physically next to something (but the point is that because this is about topologies, then neighbor doesn't have to mean physical proximity ... although I'm not sure where that's defined ... in the collection maybe?).
And then you just run the transform on a collection with some initial state.
EDIT EDIT: Yeah, the notion of neighbor is defined on the collection. This allows you to use the same transform on different collection types and get the appropriate result.
ALSO checkout figure 5 in the PDF I linked because it's an incredibly concise description of exactly what they're doing.
EDIT EDIT EDIT:
This also feels vaguely similar to what the Egison language is doing with their pattern matching. Documentation for Egison feels better at least to me.
However, I don't think that egison allows you to define arbitrary notions of neighbors in a collection like MGS does. But I haven't exactly tried to use it very much.
Re: Data structures as topological spaces (2002) [pdf]
#16Stephen Wolfram's ruliad seems to be some sort of concurrent topological computations.
There are some beautiful pictures.
https://content.wolfram.com/sites/43/2021/11/1110swimg46.png
https://writings.stephenwolfram.com/2021/11/the-concept-of-t...
Re: Data structures as topological spaces (2002) [pdf]
#17I wonder if this article is related to homotopy type theory at all, since they propose similar ideas.
Ultimately, I don't think so. All the HoTT stuff seems to really be focusing on constructing proof objects so that the computer can run them on mathematics which would otherwise not have any computer verification run on it.
More or less advanced type checking for math.
Meanwhile, the MGS language's topological collections and associated transforms seems to be about simulating things like chemical reactions. Not really verification so much as exploration.
Although, to be sure, I think both are examples of how mathematics (even highly abstract mathematics like topology) can be useful to other disciplines.
Re: Data structures as topological spaces (2002) [pdf]
#18Earlier quoted context omitted.
It would have been slightly weird terminology even back then; it seems to have always been much more common to use the word 'children'.
I suspect that English isn't the first language of the authors and there has been a translation from a language where all nouns are gendered. The phrase "an hexagon" also suggests that they don't pronounce 'h'.
That's correct. It's (and they are) French.
Re: Data structures as topological spaces (2002) [pdf]
#19How is this fundamentally different than considering data structures as graphs?
Graphs are discrete, topologies are potentially continuous. Moreover, you can do different things with them such as create homeomorphisms to another topology much more easily than you can create bijections between graphs. In general, continuity lets you assume things that are impossible in discrete spaces. For example, many optimization problems are really easy in continuous spaces but really hard in discrete ones (l…
Topologies are necessarily continuous
Re: Data structures as topological spaces (2002) [pdf]
#20Earlier quoted context omitted.
Graphs are discrete, topologies are potentially continuous. Moreover, you can do different things with them such as create homeomorphisms to another topology much more easily than you can create bijections between graphs. In general, continuity lets you assume things that are impossible in discrete spaces. For example, many optimization problems are really easy in continuous spaces but really hard in discrete ones (l…
Topologies are necessarily continuous
Perhaps the confusion is that I should have said topological spaces can be continuous. There are discrete topological spaces. Topologies (which I believe is typically used to refer to the collection of open sets in a topological space) are not functions or relations themselves, so I'm not sure a useful notion of continuity applies there, but if I'm wrong, please inform.