The Almost There (Chapter 1)

This week I have come ridiculously close to finalising the second major part of my GSoC work: diagram plotting. Before submitting the two pull requests, I only have to add proper docstrings to a couple classes and to integrate the plotting with sympy.printing.preview for easier use. (Well, there also is a FiniteSet-related issue, but I hope to be able to fix it more or less swiftly.) The main functionality is ready, however, and that gives me hopes 🙂

In terms of material progress, this week has been rather unimpressive: I haven’t written that many lines of code and that which I have written has introduced seemingly inessential changes to the aspect of the diagrams. Nevertheless, I think this week can be marked as one of the most thought-intensive.

In the beginning of this week I have extended the drawing of curved morphisms to take into account the situations when there are multiple morphisms between the same two pair of objects. This allows to automatically typeset diagrams such as Diagram 1.

A diagram with multiple curved morphisms.

Diagram 1. Multiple curved morphisms.

The next two days I have been smashing my head against the simplest approach to the problem of positioning morphisms labels such that they don’t get intersected by morphisms. The upsetting part is that, despite the amount of thinking I have done and the amount of code and comments I have written, the actual output hasn’t really got much better. (It may be considered to be a success, though, that it hasn’t got much worse either 🙂 ). Consider Diagram 2. No special care about the position of the labels is taken.

Diagram 2.  Arbitrary placement of morphism labels.

Diagram 2. Arbitrary placement of morphism labels.

Now consider Diagram 3; notice that the labels are now on the outer sides of the diagram. The trick basically (very basically) consists in detecting those morphisms which form the outer edges of the diagram and then placing their labels on the proper side. While for vertical and horizontal morphisms the procedure is pretty straightforward, for diagonal morphisms I resolved to apply some basic ideas from analytic geometry and yes, I even do floating-point computations (although I of course try to do them as little as possible). Nevertheless, the approach I have implemented feels very far from perfect. I hope though that I have managed to achieve some balance between code that works sufficiently fast and well and code that is intelligible. Note that the positioning of the labels of the morphsisms which are in the bowels of the visual structure of the diagram remains pretty arbitrary, which may sometimes get ugly.

Diagram 3.  Explicit positioning of labels of outer morphisms.

Diagram 3. Explicit positioning of labels of outer morphisms.

The next feature I have added is the possibility to draw “loop” morphisms, i.e., morphisms which have the same domains and codomains. While proper layout of such morphisms is not guaranteed for very crowded diagrams, this functionality is of some use, as can be seen in Diagram 4.

Diagram 4. Typesetting of loop morphisms.

Diagram 4. Typesetting of loop morphisms.

Finally, I have implemented the support for custom arrow formatters. Arrow formatters are associated to morphisms properties. Whenever a morphism with some properties is typeset, after the necessary thinking has been carried out, the resulting data is passed to the formatter. The formatter is free to modify anything it wants in order to influence the appearance of the arrow. A common usage is shown in Diagram 5. This effect was achieved with a two-line formatter.

Diagram 5. Use of formatters

Diagram 5. Use of formatters

I must confess that dealing with hash randomisation-related issues takes up much more time that I always expect. I have been constantly getting back to certain bits of my code and adding new and new invocations of sorted to assure stable output. Working on this, as well as on some obscure tuning of small details of the diagram is actually what has consumed the bulk of my time this week. The visual input of such modifications is usually minimal; yet, I do believe they bear a rather important role.


7 responses to “The Almost There (Chapter 1)

  1. Not to discount what you’ve done, but I noticed another issue. With diagram 1, the baseline of the labels should always be h. Otherwise, it appears that h is lower than h1 and h2 because it’s lining up with the 1 and the 2.

    Also, is it just me, or do the labels all appear skewed toward the arrow side of the line? I think they are actually centered on the line, but visually, we see the line as ending somewhere near the arrow base, so it appears skewed.

    How much control do you have over arrow heads, by the way? They need to be angled more on the loops. Also, are your loops intensionally not circles?

  2. I believe we are seeing some imperfections of xy-pic here (in what aaron mentions). I could be wrong, of course ^^.

    Anyway, this looks much better than the pictures from the beginning of last week. I’m looking forward to your pull request.

    • Yes, I just read through the xy-pic docs, and I think these issues are all based on the xy-pic defaults (except maybe the baseline issue). So probably it would be better to ask the authors concerning the aesthetic issues to see if they had good reasons for them, or if they otherwise would want to change them.

      • In Xy-pic docs, the authors say that the labels are positioned in the middle of the distance between the centers of the cells the arrow connects. This can be changed, and I’ll add the possibility to set the general format of the arrows (applied independently of properties) to approach this issue.

        The baseline issue is an Xy-pic issue as well, because, apparently, Xy-pic positions the centers of the labels, which causes the baselines of h_1 and h_2 to be placed higher than h. I’m not really sure how to solve that Xy-pic-ishly (I don’t remember this referenced in the docs). However, using h_{~} instead of h solves the problem.

        The other issues are Xy-pic-related as well. I will currently focus on merging the existing code, however. Note that besides the ~25-page Xy-pic guide the also is a 100+-page Xy-pic reference, which goes into very much detail and which, eventually, may allow fixing arrow angles in loops. I don’t think I’ll manage to read it sufficiently fast now, though.

      • Good. There is little over a month left, so we need to get this in fast if we want to revise this code before the end of GSOC (based on user feedback)! It would be great if you get the PRs ready by 7pm UTC wednesday or so, I have a couple of hours tomorrow evening to do the reviewing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s