Closed jbfaden closed 1 year ago
This shows the beginning of the corrected logic, just to illustrate. On the left is the current algorithm, on the right is the new being tested (which still needs work).
Looks nice. What method are you thinking about using to avoid tick crowding in decades 5+ ? Jump to one every 0.2, then maybe one every 0.5 ? I don't have an opinion, just curious.
Yes, that's the idea. Within each cycle, it will use the linear algorithm to pick nice ticks.
Do you know of a Python plotting code that has nice ticks? I tried MatPlotLib's plot this morning, thinking that surely it was more complete than the DasAxis is, but I wasn't able to get anywhere with it.
I've been reminded about the DomainDividers Ed Jackson wrote, and I see that there is an implementation that has this logic. See org.das2.datum.LogLinDomainDivider. It looks like this still needs some work (for example, it does not have the logic to step by 2 or 5), but this might be a cleaner way to contain this logic.
Almost everything I know about matplotlib (which isn't much) is contained the examples folder over in das2py. This Galileo plot has a log frequency axis, but too many decades are displayed to be relevant to the topic at hand. The source *.py code is adjacent to the png file in the repository.
I've committed a first version of this, where when one or two cycles are shown, the LogLinDomainDivider is used to generate ticks.
This is done
For years the logic for the log axis ticks when only about one cycle is visible is to use linear ticks. This isn't quite right, where really it should be linear ticks within the log cycles: 1,2,3,4,5,6,7,8,9,10,20,30,40,50,60,70,80,etc. I'm noticing other systems are getting this right and Das2 plots look sloppy here. Further, the logic here has multiple paths, so if you drag the axis it will flicker as different algorithms are used. This should be corrected with one, consistent logic.