12

Update:

Screenshots:

Now the users can edit the default colors of arrows, nodes etc. using the ColorEditor: BananaCats color editor

Users can draw diagrams and store them into a Graph Database (Neo4j) seamlessly. BananaCats diagram editor

Here are the videos of the old version.

Please stay tuned to this post (or the repository / project on GitHub) for updates. You'll be able to download and try (on Windows) in < 1 month I project.

Asaf Karagila
  • 405,794
Daniel Donnelly
  • 22,288
  • 1
    I don't do a lot of category theory, so I won't be using it -- but I liked the part where the functor gets applied to the entire diagram automatically :-) – joriki Jul 13 '18 at 05:14
  • @joriki thank you for your positive feedback. It will also apply to diagram chasing in more specific fields such as module theory – Daniel Donnelly Jul 13 '18 at 05:27
  • 1
    This is very interesting! I would try it. – Ivan Di Liberti Jul 13 '18 at 11:26
  • I'm revamping this project. It's going to be Qt / C++ coded in Visual Studio. It will only support $R$-module diagram chases, and then I will expand from there. I like element-based diagram chases over pure abelian category ones. People like taking elements, it's trained into us from the start. It's more natural than element-free, therefore. That's how our minds must work if that's what first came about historically. Thx to the Freyd-Mitchell embedding theorem (I think, but I haven't gotten that far in Weibel yet myself), the results will applly to all abelian categories. – Daniel Donnelly Feb 24 '23 at 21:24

1 Answers1

5

I will make two comments, one from the point of view of a user, and one from the point of view of a developer.

In software development, the MoSCoW method is used to define project priorities. You can use it to define what features your software Must have, what it Should have, what it Could have, and what it Won't have. If I were to define the priorities of this project, here's how I would define it:

Must Have:

  • An Undo Button. If I lose tons of painstaking progress by mistakenly applying a functor and commuting-out other arrows/objects in my category, I would probably quit using this software until it had this feature.
  • In a similar vein, there should be a save feature which allows me to read/write from a file and get the exact state of the diagrams (x/y positions included) or share it with others.

By the way, those are run-of-the-mill features, not specific to Category Theory. I mean, this is really solid if that's all it needs to have! Some polish is needed, but it's a piece of software with a well-define purpose and user base. The rest could be under "want", but are not essential.

Should Have:

  • Extensible commuting, on arrow/functor/natural map/beyond level. This is extremely difficult, but the alternative is custom creation of cones, limits, exponent maps, subobject classifiers, etc. Maybe you could manage this programmatically through specific kinds of Kan Extensions.
  • Keyboard shortcuts. Consider the user with motor function impairment, who might not be able to move the mouse very easily. Accessibility also helps power users, who may want their hands to stay on the keyboard for more inputs-per-second.

Could Have:

  • Diagram commutativity designation. One of the problems I have when studying category theory in general is how difficult it is to figure out whether a diagram is commuting or not. Which diagram has commutativity? Should all the commuting arrows be explicitly shown? Where to draw the line on too much "ink"?
  • Library of Kan Extensions.
  • Label drawing. This is a surprisingly difficult problem.

Won't Have:

  • One of your questions was: "Should I have functors fill in recursively?" Some people might like that, some people might feel that the software is taking over for them (I didn't read this whole article, but I think it's related: the experience of agency in HCI). Besides being overbearing, it might be impossible; imagine a functor loop, and having the categories spam objects and arrows until the software crashes.

As a developer, I have a couple of pieces of advice for the development process.

  • Python is a great prototyping language. As you move forward, you should consider using a statically typed language. I know folks who work on large projects in Python, and they always complain about not knowing what types they're getting from which functions, and runtime errors when dealing with classes that they're not sure about, and the constant referencing of attributes and methods that cannot be automatically pulled by the IDE. Save yourself the pain.
  • Open-source the project. Nothing is sadder when a promising project like is abandoned without details on how to run it, setting up environment, and so on. Community-building is tough. But the interest is there.

I look forward to the progress on this software.

Larry B.
  • 3,544
  • It is harder to integrate an undo/redo feature than to do a whole scene save and simple list of files version control, which is what I have planned. It will then save every minute or so (if there is a change), which should be plenty. If the scene is small enough I can save on every change or have that be an option. I've implemented undo / redo before, and it gets really convoluted with such graph scenes. I'll think on it. Maybe it's not so bad... – Daniel Donnelly Jul 13 '18 at 19:19
  • The idea behind commuting diagrams is that every diagram the user enters is assumed to commute, and the only features allowed for auto-building are ones that preserve commutativity. Thus in the app all diagrams are commutative. When the user places an arrow in a diagram they are asserting commutativity. After all, it is a hybrid use experience (human / machine), not a complete take over of the work, which is probably impossible at least for my level of understanding. – Daniel Donnelly Jul 13 '18 at 19:26
  • If there is some question of whether an operation is valid and the machine cannot be coded to decide this in any elegant way (applicable to other situations, and not bug-inducing), then we could have a voting system, where a high vote means validity (it's been human verified). – Daniel Donnelly Jul 13 '18 at 19:28
  • There is no danger of looping on the recursive arrows idea. The only time the codomain gets filled is when an arrow is attached and you can only do this one at a time. Note that you still have to be smart about using the software, you could probably draw completely crazy things as well, but we limit that were we can such as no arrow can connect to an object outside the category. – Daniel Donnelly Jul 13 '18 at 19:31
  • 6
    @EnjoysMath You should be designing (pretty much all of) your UIs with undo/redo functionality in mind from the very beginning. There are multiple ways of structuring a system to make this easy. It is much harder to retrofit into a system that hasn't been designed for it. I agree with Larry B. that this is very much not an optional feature or (going beyond what Larry B. said) something periodic saving can make up for. It dramatically reduces usability and discoverability when the user must fear losing work with every (potentially mistaken) change. – Derek Elkins left SE Jul 13 '18 at 19:32
  • @DerekElkins okay, that settles it. It's not too late. I've only got 30 files. Qt has undostacks etc. I don't know of an elegant way to code the framework as you mentioned. Do you have a link? – Daniel Donnelly Jul 13 '18 at 19:34
  • 2
    @EnjoysMath There are at least three popular approaches. First, simply store all versions. If you use persistent/functional data structures for you model, this can be quite feasible since most versions will share a large amount of structure. Next, there is command logging which is storing each user action as a "transaction" against the model. You can either replay the commands against a checkpoint, or you can have each command know how to undo itself with complex commands composed of simpler ones, i.e. you can play the log "backwards". – Derek Elkins left SE Jul 13 '18 at 19:59
  • @DerekElkins yes, I'm using __getstate__, __setstate__ which would work. The graphical structures aren't humungus, so I should be able to store say the last 100 versions of each. – Daniel Donnelly Jul 13 '18 at 20:10
  • 1
    +1 to the command & transaction model. BTW, It's never too early to put code on Github if you want to open-source this, and you can get a lot of support this way if you do. Although that sorta closes off the possibility of purchasing software, but it's effectively open-source if you're distributing uncompiled python. – Larry B. Jul 13 '18 at 21:00
  • 1
    I'm going to recommend we move this conversation to a chatroom: https://chat.stackexchange.com/rooms/80144/assitivediagramchaser – Larry B. Jul 13 '18 at 21:07
  • @LarryB. The new version I'm working with takes into account undo / redo and drag / drop and copy / paste from the get go. It even stores your undo/redo stack to the project file so that you can undo / redo after restarting machine (from where you left off in the stack). – Daniel Donnelly May 30 '19 at 00:27
  • @LarryB. I'm starting back up this project. The only logic it will support is enough to express theorems in a category of $R$-modules, where we leave $R$ as general. To say it's integer or $\Bbb{Q}$ or some other structure opens up a whole can of element-based CAS representation questions, and it really depends on how much you can code or how much you understand how to generalize all of math as Lean does. I think if we just want to chase in $R$-mod, we can safely restrict many of the possible constructions, and thus hard-code a bunch. – Daniel Donnelly Feb 24 '23 at 21:27
  • Think about it this way, would you rather hard-code Functor and apply it to full CD's? Or would you rather encode it in the logic system (which is hard-coded) as a commuting triangle. You then must apply many axioms / lemmas (just a few, but repetitively) for large diagrams until the full functorial image gets pasted together from the elements. That's ridiculous if you ask me. Therefore I'm hard-coding functoriality. In that case there's an axiom in the "system" saying that given any CD its functorial image is also a CD. That's equivalent to the commutative triangle one, but more humane. – Daniel Donnelly Feb 24 '23 at 21:30
  • @LarryB. I don't know what I wrote above about undo / redo. But I tried the "save whole scene" method in python, and it was cludgy. So Command Pattern + Undo Stack is about the only way to get forward/reversible proof steps. Yes even rearranging a node or arrow in the scene is a proof step, but we hide or truncate these from the actual proof. Deleting for example is a valid math operation and a usual editing operation. Clearly if a CD commutes, then any subdiagram which is the original diagram with any part deleted, must also commute. That's a rule in the "meta theory/system". – Daniel Donnelly Feb 24 '23 at 21:33