Hi from adjustText

[Phlya]

Hi Christoffer!

Just discovered your package! Very interesting and cool, and your approach looks great! Just last week I pushed a new waaay faster version of adjustText, which also simply uses numpy to calculate overlaps. Wondering how the performance compares now, and whether the results look "better" with one or the other approach... Would you be open to doing some comparisons together, and seeing whether the packages can benefit each other?

Best wishes,
Ilya

[ckjellson]

Hi Ilya, sure that could be an interesting exercise. I created this package because adjustText was a bit too slow for my use-case, and it was less time-consuming for me to try an alternative approach than to learn and contribute to yours, great that you have now improved it! What do you want to do?

[Phlya]

Totally understandable, I myself have been annoyed at how slow it was, but just couldn't fine the time to re-implement it in a faster way. I think the code is also more maintainable and easier to understand now too.

I think would be nice at first to simply compare side by side the results in some complicated cases, see whether combining the two approaches can get the best of both worlds (e.g. first run allocate_text, and then if there are still some overlaps, try adjust_text... first step in adust_text is like a minimal version of your approach already - it simply "explodes" the texts away from all nearby texts and other objects), or perhaps whether some functions can be reused across the libraries to add functionality to one or both of them.

I can't say I have a lot of time to work on this, but I also would like not to abandon this project like I basically did for a few years.

[ckjellson]

Alright, before I can say something about if I think any sort of combination is a good idea I will have to take another look at adjustText and how it works. I will try to do that when I can find some free time, and maybe also run some comparative tests. Let me know if you have some challenging examples in store 😉

[ckjellson]

Made some initial tests here: https://colab.research.google.com/drive/1brEbNkEwd5EC0rqMdL-YoqfJIpr1lfmM?usp=sharing. Have not tweaked any adjustText parameters yet because I have to look at the forces first, feel free to edit!

[Phlya]

Thanks a lot for starting the ball rolling! Very interesting, textalloc is performing really well. I'll try to play a little with it when I have some time.

[Phlya]

I tried running the notebook on colab and I am getting ModuleNotFoundError: No module named 'textalloc' :( I have to say I've never used colab, maybe I am missing something...

[ckjellson]

Strange, I wanted to install the latest versions from github, but seems like it doesn't work for textalloc (thought it did), so changed it so that textalloc is installed normally, should work now!

[Phlya]

I see, thank you! I'm more and more thinking your algorithm just works better. Much simpler idea and procedure, sort of guaranteed to work reasonably well, and doesn't produce strange unexpected stuff.

[Phlya]

I think I found a very simple example where adjust_txt performs better, it's a very simple modification of the first one, basically. It's in the notebook. I thought textalloc would be very robust to such small changes, but perhaps not?..

Also btw, for the timing - the new adjust_text actually has a time limit for the algorithm as an argument, and in simple cases it can be reduced (default is 0.5 sec, but often 0.1 sec is basically just as good) and produces still very good results.

[ckjellson]

Nice with the time-limit feature! I guess the corresponding parameter in textalloc is nbr_candidates, which if decreased decreases runtime, but gives a slightly worse result.

I don't think the default parameters for textalloc are very good right now as you have discovered, I should change defaults to margin=0.0,max_distance=0.2,nbr_candidates=200, which will probably give better results in most cases, including the one you added (added this in all function calls in the notebook).

I think it is difficult to compare when you can have very different plots while the default parameters are probably set for different scenarios for the two packages. I think it's fair to say that textalloc is quite good and fast for large plots, but In my opinion the other main point of improvement for both is to be able to produce a good output without having to tweak any parameters (time_lim and expand for adjustText, min_distance and margin for textalloc), and then it would be easier to compare them by only using the default values.