Some set combinations produce bad location of numbers and different colors in venn3

[joaquinabian]

This is matplotlib_venn vs 0.9 on MS Windows 7 64 bits.
Same efffect in Windows XP 32 bits

The following image is as expected for venn3([8, 74, 7, 50, 8, 433, 83]) :

but when using venn3([5, 35, 6, 81, 21, 621, 178]), I got different colors and wrong location of numbers:

btw, thanks for this nice app. I use it continously for my work.

[konstantint]

Hey. What you discovered is an example of one annoying bug that I kind-of know of, but so far have been trying to avoid facing it, because a proper fix requires some rewriting of the most annoying place in the whole code (basically, the "patch generation" function has to be changed from an ad-hoc solution to a nice mathematical one, using a path intersection algorithm). Now that you brought it up, I'll probably try to find time in the next month or so to deal with it.

In the meantime, let me explain what happens, and perhaps you'll be able to code around, temporarily. Namely, as the set C becomes larger, the circle positioning algorithm ends up with a solution, where the patches for ABC and for AB~C become curved polygons built on four vertices, rather than 2 or 3 as is the case in 99.9% situations otherwise. The algorithm currently cannot deal with this case and goes crazy with the corresponding patches. You can see what happens by doing:

v = venn3([5, 35, 6, 81, 21, 621, 178])
v.get_patch_by_id('111').set_lw(3)
v.get_patch_by_id('111').set_edgecolor("black")

and

v = venn3([5, 35, 6, 81, 21, 621, 178])
v.get_patch_by_id('110').set_lw(3)
v.get_patch_by_id('110').set_edgecolor("black")

A temporary ugly hack to fix your particular case would be to hide the first of the wrong patches completely, ignore the fact that the second wrong patch is affecting one of the colors ever so slightly, and move some labels around manually:

v = venn3([5, 35, 6, 81, 21, 621, 178])
v.get_patch_by_id('111').set_alpha(0)
v.get_label_by_id('100').set_x(-0.55)
v.get_label_by_id('010').set_y(0.52)

[joaquinabian]

Thanks Konstantin, for your fast response.
I will give a look at your suggestion. I am generating venns automatically
from my data so I never know what kind of weird combination I will get.
Hope the patch give you less headaches than you expect.
J

On 2 September 2014 21:40, Konstantin Tretyakov notifications@github.com
wrote:

Hey. What you discovered is an example of one annoying bug that I kind-of
know of, but so far have been trying to avoid facing it, because a proper
fix requires some rewriting of the most annoying place in the whole code
(basically, the "patch generation" function has to be changed from an
ad-hoc solution to a nice mathematical one, using a path intersection
algorithm). Now that you brought it up, I'll probably try to find time in
the next month or so to deal with it.

In the meantime, let me explain what happens, and perhaps you'll be able
to code around, temporarily. Namely, as the set C becomes larger, the
circle positioning algorithm ends up with a solution, where the patches for
ABC and for AB~C become curved polygons built on four vertices, rather than
2 or three as is the case in 99.9% situations otherwise. The algorithm
currently cannot deal with this case and goes crazy for the corresponding
patches. You can see what happens by doing:

v = venn3([5, 35, 6, 81, 21, 621, 178])
v.get_patch_by_id('111').set_lw(3)
v.get_patch_by_id('111').set_edgecolor("black")

and

v = venn3([5, 35, 6, 81, 21, 621, 178])
v.get_patch_by_id('110').set_lw(3)
v.get_patch_by_id('110').set_edgecolor("black")

A kind of a temporary fix would be to hide the first of the wrong patches
completely, ignore the fact that the second wrong patch is affecting one of
the colors ever so slightly, and move some labels around manually:

v = venn3([5, 35, 6, 81, 21, 621, 178])
v.get_patch_by_id('111').set_alpha(0)
v.get_label_by_id('100').set_x(-0.55)
v.get_label_by_id('010').set_y(0.52)

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[funnell]

I've just come across this bug as well.

[konstantint]

funnell, once you're at it, you could post your particular example code. The more examples I have, the better can I test the fix.

[funnell]

Here you go: venn3([12, 424, 18, 13, 1, 139, 8], ['a', 'b', 'c'])

[funnell]

For now, I'm using venn3_unweighted

[konstantint]

Issue fixed in version 0.10.