@seancorfield The algebraic topology library is coming along alright. I am getting the answers I expect for balls of arbitrary dimension. But, Javaplex doesn't like the data you put in it to be anything but integers (and arrays of integers). I'm trying to write something that will let me consider, say, the triangle [:a :b :c]
just as easily as the triangle [0 1 2]
.
Here's a failing test: https://github.com/mathpunk/simplexity/blob/1.2/test/simplexity/data/simplex_test.clj#L20
And here's an attempt to pass the test, which failed: https://github.com/mathpunk/simplexity/blob/1.2/src/simplexity/simplex.clj
If you have any thoughts on how I can approach this problem, do tell.
Also note, I found this quite interesting http://blog.cognitect.com/blog/2017/6/19/improving-on-types-specing-a-java-library and while it's guiding how I think of the problem of getting Javaplex to work in general, right now I'm in the weeds on how to design a great Clojure API.
@mathpunk That's some heady stuff... I'm not in a space to process most of that (just come back from a friend's "Friday 13th" dinner party) so I'll try to take a look over the weekend. On the labeled stuff, it feels like you ought to be able to include a preprocess step that build a map of symbol/keyword to integer and that walks the array/array of arrays etc and replaces each previously unseen symbol with the next increasing integer? So [[:a :b :c] [:b :c :d] [:d :a :b]]
would become [[0 1 2] [1 2 3] [3 0 1]]
with a lookup of {:a 0, :b 1, :c 2, :d 3}
.
Stu's article is reaching for invariants -- I don't know the math well enough to know what that would look like for Javaplex, but maybe you do. There are probably some interesting properties you could derive -- even if they are only, essentially, lowest bounding conditions from input to output. Specs don't have to be very specific -- that's one of their great benefits: they can be "just specific enough" to be useful. A lot of people try to over-specify their data and functions, when they first get started with spec.