Ticks orientation about python-ternary HOT 13 CLOSED

I know this is a bit confusing, but ternary does show the correct values -- it's just that the labels have to change appropriately for each orientation and the library does not do that for you. Look at the diagram in the second comment on issue #18: when the orientation is changed, so too are the axes to which each component corresponds: component 0 was on the bottom (left to right) but now component 2 is (right to left). The later comments (especially the fourth and sixth comments) go into even more detail.

The label API is such that you tell ternary what label to put on the bottom axis, and it does that -- it does not permute the labels when you change the value of clockwise, rather it assumes that you are telling it the proper label. So if you change orientations, it's up to you to change the labels. I was also confused by this at one time, and it's not the only valid point of view. However if I make the library permute the labels based on the value of clockwise, that will be (IMO) more confusing.

The reason you got an error in the call for ticks() is because locations must also be specified. The library doesn't know where you want the ticks, though perhaps it could make an assumption in this case since the length of ticks is equal to scale / multiple. I'll think about that case and possibly patch accordingly.

from python-ternary.

I am not very sure what you meant there. got even more confused after i go through the second comment on #18.

but for example the bottom axis, in my case the axis goes anti-clockwise, so the bottom axis value i assume will go from left to right? if that the case, then the value suppose to increase rather than decrease from left to right of the bottom axis?

from python-ternary.

The bottom axis will go from left to right in the counter-clockwise case. Think about tracing counter-clockwise around the triangle starting from any corner -- the values will be increasing in the direction of rotation. The same is true for the clockwise case. If that is not how the tick labels render for you, it could be another mac/anaconda difference. I just tested both orientations with your example code and they look correct to me. I could look into adding directional arrows like ggtern does.

@CorySimon reported something similar with the ticks in issue #31, and said that this site helped understand ternary plots.

If you are still convinced that the values are not being plotted correctly, please post code with a specific point (0.1, 0.4, 0.5). But note that the orientation permutes the indices as follows:

from python-ternary.

import pylab as p
import ternary as t

figure, d=t.figure(scale=1)

d.boundary(linewidth=2.0)
d.gridlines(multiple=0.1,color="blue",linewidth=0.8)

d.set_title(r"source flavour composition $\nu_e,\nu_\mu,\nu_\tau$",fontsize=20)
d.left_axis_label(r"$\nu_\tau$",fontsize=20,offset=0.12)
d.right_axis_label(r"$\nu_\mu$",fontsize=20,offset=-0.01)
d.bottom_axis_label(r"$\nu_e$",fontsize=20,offset=0.01)
d._redraw_labels()

point2=[(0.552,0.243,0.203)]
d.ticks(axis='brl',multiple=0.1,clockwise=False)
p.axis('off')
d.scatter(point2, marker='^', color='red', label=r"$(1,0,0)$",s=100)

d.resize_drawing_canvas(scale=1.15)
d.legend()
d.show()

I am pretty sure my plot are accurate as I am trying to reproduce a result of the paper I researching on and the point located pictorially for each value are almost the same.

the red triangle in plot has the value (0.55,0.24,0.20), which is what i entered. but if i were to read off from the plot, is was (0.45, 0.76, 0.8)

perhaps the anaconda i'm using renders different to yours?

from python-ternary.

Note that I had to reverse the order of the tick labels in my example to get the labels on the axes correct.
If you do this, will it give you the correct location?

https://github.com/marcharper/python-ternary/blob/master/examples/color_coded_heatmap.py

ticks=["%.1f" % (1.0 - 1.0 * i / scale) for i in range(scale+1)]

from python-ternary.

this is the one where i put clockwise=True, and the problem is the same as before

from python-ternary.

@CorySimon it looks like I may have to do that, could you show me how I could modify my code? as I try to follow ur example but failed to get it modified for myself

from python-ternary.

@hareyakana

d.ticks(axis='brl',multiple=0.1, ticks=["%.1f" % (1.0 - 1.0 * i / 10.0) for i in range(11)])

should work to reverse the ticks.

@marcharper The way I view these plots, I agree with @hareyakana that the labels may be backwards in the defaults.

from python-ternary.

@CorySimon I tired but i got this error instead.
TypeError: 'NoneType' object is not iterable

I also tried list the value individually as an argument into ticks before and did get the same error

from python-ternary.

@hareyakana what line of code?

from python-ternary.

Traceback (most recent call last):

File "", line 1, in
runfile('/Users/hareyakana/Desktop/Master project/flavour composition/ternaryplot.py', wdir='/Users/hareyakana/Desktop/Master project/flavour composition')

File "//anaconda/lib/python3.4/site-packages/spyderlib/widgets/externalshell/sitecustomize.py", line 685, in runfile
execfile(filename, namespace)

File "//anaconda/lib/python3.4/site-packages/spyderlib/widgets/externalshell/sitecustomize.py", line 85, in execfile
exec(compile(open(filename, 'rb').read(), filename, 'exec'), namespace)

File "/Users/hareyakana/Desktop/Master project/flavour composition/ternaryplot.py", line 40, in
d.ticks(axis='brl',multiple=0.1, ticks=["%.1f" %(1.0-1.0*i/10.0) for i in range(11)])

File "//anaconda/lib/python3.4/site-packages/ternary/ternary_axes_subplot.py", line 264, in ticks
axes_colors=axes_colors, **kwargs)

File "//anaconda/lib/python3.4/site-packages/ternary/lines.py", line 241, in ticks
for index, i in enumerate(locations):

TypeError: 'NoneType' object is not iterable

i suppose the line d.ticks

from python-ternary.

@hareyakana As I said above, with tax.ticks(), if you specify the ticks, you must also specify the locations. Edit: ternary will now make a reasonable assumption and you don't need to specify the locations.

As for the location of the points... for the clockwise=True example above, the point seems to be where the projection would place it, 0.55 to the right (starting at the bottom-left corner) and then 0.24 up-right. If you follow the up-left gridline to the axis it hits 0.21. For the clockwise=False I can see why you may think the point is not where it was intended if the labels are not rotated, and would prefer a mapping of x --> 1 - x. But if you rotate the axis labels around like in the ggtern made plots above, then the points are correct. The way to visualize it is to move from the top corner down-right 0.55, then down-left 0.21. Following the gridline to the left axis and you hit 0.24. I think perhaps clockwise=True and False are simply flipped, but the tick values are in the correct orientation. So I'll patch that.

There is still confusion on the following point. When you change the orientation, it changes the axes, just as in the ggtern plots, not just the tick mark directions and tick labels. This library, however, does not change the axes labels for you. If you say you want $\nu_e$ as the label on the bottom axis, that's where ternary puts it, because we don't have a data frame to know which label is associated with which coordinate like ggplot does. If I change the behavior of e.g. bottom_axis_label to put the label on the right axis when the orientation argument is toggled, then people are going to post issues saying that the manner in which the labels are magically moved around is confusing. The reason that the plots are made this way is in the earlier issues referenced above -- there are two valid ways to interpret each plot for each of the six possible permutations of the variables, and you get one with clockwise=True and the other with clockwise=False.

It is clear that the documentation needs to explain this much better, since it's not really reasonable to expect people to look back through earlier issues to understand this. So I'll update the readme to include some more explicit information.

from python-ternary.

Ok, I've made a few changes. The standard ticks should work fine now and I've updated the example appropriately. The clockwise options should be more like what you expect, but note that the axis labels are unchanged as per the above comment.

from python-ternary.