Data structures as topological spaces (2002) [pdf](mgs.spatial-computing.org) |
Data structures as topological spaces (2002) [pdf](mgs.spatial-computing.org) |
https://www.algebraicjulia.org/
There's some blog posts that are also interesting:
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.
Is that right?
It looks like they've got a pure functional thing going on.
Ok, I quickly browsed through it, but a chemical reaction where two identical molecules react into those same molecules plus another molecule? How can this be possible?
It's a DSL for computational biology where very little documentation has apparently made it to a public forum. I can decode the programming language part of it but I'm not up to scratch on computational biology so I'm not sure exactly what they want it for.
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...
Given the recent success with vectors as a general model for data (as witnessed by the continued success with deep neural networks), it's an interesting discussion to have.
If you argue with more generality: why not consider sites (and, relatedly, topoi) instead of topological spaces then:
> 2. computes a new collection C as a function f of B and its neighbors,
> 3. and specifies the insertion of C in place of B into A.
This sounds a lot like the presentation of comonads as directed containers (e.g. https://arxiv.org/abs/1408.5809).
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.
I disagree. There's a migration from Haskell to Lean 4, which is influenced by HoTT, and is a credible general purpose programming language.
Arguably, _the_ credible general purpose programming language, if one believes that programming should feel like doing mathematics. Languages are shaped by their target tasks, and writing tactics for proofs subsumes any other task one might consider. Programming is recognizing pattern, and pattern runs deep in Lean.
When we're young, but past existential BS, we start to think that ten years of training will yield productive years that outstrip decades of muddling in ad hoc languages if we hadn't made the commitment. But soon, few want to make the commitment.
If programming is ever going to become far more advanced, it will take the form of successors to Haskell and Lean.
> 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?
I thought linear programming would be something everyone knows, and I am not the original author so I can't speak for why they chose topological spaces instead of anything listed here. I think their e-mails are on the paper. Perhaps e-mailing them will help elucidate their choice.
In the usual mathematical sense of the words you are using, topologies aren’t even the right type of object to admit a notion of continuity. Your statement doesn’t even make sense. It’s maps between them that can be continuous.
In fact, a topological space is sort of the minimal amount of structure a set needs to have to be able to talk about continuity of maps to/from it.
Being able to define a neighborhood or a concept of closeness is required, but the concept of distance is not required.
If you can define a distance a topological space is a metric space
If it is locally euclidean it may be a manifold.
Really the union and finite intersection of subsets is the formal way of showing something is a topological space. Too har do describe here but that is where the concept of continuity arises.
