Skip to content

Ticks orientation #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hareyakana opened this issue Nov 30, 2015 · 13 comments
Closed

Ticks orientation #37

hareyakana opened this issue Nov 30, 2015 · 13 comments

Comments

@hareyakana
Copy link

Im sorry for post this issue as it has been discussed before but things does not work the way i expected.

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)
d.bottom_axis_label(r"$\nu_e$",fontsize=20)
d._redraw_labels()

d.ticks(axis='brl',multiple=0.1)
p.axis('off')
point1=[(0.34669820676138435,0.3336302826666826,0.31967151057193305)]
d.scatter(point1, marker='D', color='green', label=r"$(\frac{1}{3},\frac{2}{3},0)$")
d.resize_drawing_canvas(scale=1.05)
d.legend()
d.show()

untitled

from the plot above, the point i plotted corresponds to the 3 value in point1, but if I were to read off from the plot the ticks labels are reversed. from @marcharper u suggested adding an argument to ticks, so i tried but it gave me error when i replace the ticks line to

d.ticks(axis='brl',multiple=0.1,ticks=[1.0, 0.9, 0.8, 0.7, 0.6, 0.5, 0.4, 0.3, 0.2, 0.1, 0.0])

TypeError: 'NoneType' object is not iterable

apologies again as this has been discuss before, but is annoying that the orientation of tick does not show the correct value I'm plotting.

edit: the value in point 1 correspond nu e,mu,tau respectively.

@marcharper
Copy link
Owner

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.

@hareyakana
Copy link
Author

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?

@marcharper
Copy link
Owner

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:

@hareyakana
Copy link
Author

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()

1

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?

@CorySimon
Copy link
Contributor

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)]

@hareyakana
Copy link
Author

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

@hareyakana
Copy link
Author

@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

@CorySimon
Copy link
Contributor

@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.

@hareyakana
Copy link
Author

@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

@CorySimon
Copy link
Contributor

@hareyakana what line of code?

@hareyakana
Copy link
Author

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

@marcharper
Copy link
Owner

@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.

@marcharper
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants