10
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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 :-) $\endgroup$ – joriki Jul 13 '18 at 5:14
  • $\begingroup$ @joriki thank you for your positive feedback. It will also apply to diagram chasing in more specific fields such as module theory $\endgroup$ – I Said Roll Up n Smoke Adjoint Jul 13 '18 at 5:27
  • $\begingroup$ This is very interesting! I would try it. $\endgroup$ – Ivan Di Liberti Jul 13 '18 at 11:26
  • $\begingroup$ UPDATE: I can only offer developer installation instructions (which includes grabbing the source code) until someone can fix the pyinstaller issues, in which an EXE is being produced but it throws a neo4j module not found error upon running. Running directly from source code doesn't do that. See repo / issues for more info. $\endgroup$ – I Said Roll Up n Smoke Adjoint Apr 2 at 7:52
4
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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... $\endgroup$ – I Said Roll Up n Smoke Adjoint Jul 13 '18 at 19:19
  • 5
    $\begingroup$ @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. $\endgroup$ – Derek Elkins Jul 13 '18 at 19:32
  • 1
    $\begingroup$ @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". $\endgroup$ – Derek Elkins Jul 13 '18 at 19:59
  • 1
    $\begingroup$ +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. $\endgroup$ – Larry B. Jul 13 '18 at 21:00
  • 1
    $\begingroup$ @LarryB. See edits to OP, I've released the source. It's not in a good state though, so wait a while like a few weeks. It's to a new design, a database-driven approach. I gave up trying to build my own "proof environment". So now everything is all dependent upon the community of users, who use the tool and at the same time build content for them to refer to later, or for novices to learn from like a linked "storyboard" proof but it was all created and checked by human eye. That's the graph database approach. $\endgroup$ – I Said Roll Up n Smoke Adjoint Mar 25 at 2:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.