cast-org/cwm-drawtool

Choosing points on axis to label

Closed this issue · 10 comments

Current code always labels 10 points on the axis, regardless of the min and max 
that are chosen.  This leads to awkward labels in many cases.

Here is a recipe for picking better label points.

Given the size of the graphing tool,  somewhere around 5 to 10 labels looks 
reasonable.

The number of tick marks and labels is determined by the difference between 
what the user specifies as X max and X min. 
Call D = Xmax - Xmin

If D is larger than 5 but not larger than 10:
    put labels at every integer (resulting in between 5  and 11 labels)
    Example: if Xmin = 0 and Xmax = 7, labels @ 0, 1, 2, 3, 4, 5, 6, 7 

If D > 10 and   D <= 20
    labels at every multiple of 2  (5 to 11 labels)
    Example: Xmin = 0.5, Xmax = 12.5, labels @ 2, 4, 6, 8, 10, 12

D > 20, D <= 50
    labels at every multiple of 5  (4 to 11 labels)

Repeat the above x 10, x 100, etc:
>50 to 100 : labels @ 10s
>100 to 200: labels @ 20s
>200 to 500: labels @ 50s
>500 to 1000 : labels @ 100s
 and so forth

and the same way the smaller powers of 10:
> 2 to 5 : labels at .5
>1 to 2 : labels at .2
>.5 to 1 : labels at .1
>.2 to .5 : labels at .05
 and so forth

Y axis the same way based on Y min and Y max.

Original issue reported on code.google.com by bgoldow...@gmail.com on 7 Feb 2012 at 1:23

Because the overall code seemed a bit complex, I ended up using a 3rd party lib 
for finding the points, I like the outcome, but it seems to overshoot the end 
point on some settings.  Please check revision 48 and let me know.

Original comment by RobertLe...@gmail.com on 7 Feb 2012 at 5:19

  • Changed state: Started
It's an improvement, but if I put in Xmax = 7, I get a graph that still goes to 
X=10, so there's something not quite right.  If I put in Xmax=3, I get a graph 
that goes to 5.   Is there a way to force it to follow the min and max that are 
put in?

Original comment by bgoldow...@gmail.com on 7 Feb 2012 at 6:21

This should be fixed now.

Original comment by RobertLe...@gmail.com on 9 Feb 2012 at 8:51

Very close.  If I set the min/max at -10/+10, though, I get labels at:
-10, -7, -4, -1, 2, 5, 8, 10.

The asymmetry makes the graph very confusing - it needs to be constrained to 
always choose points that are multiples of something, not offset like this.  
The algorithm I suggested would label -10, -8, -6, -4, -2, 0, 2, 4, 6, 8, 10 
which would look much nicer.

Another test case: currently if I pick Xmin = 0.5 and Xmax = 5, it chooses to 
label .5, 1.5, 2.5 etc -- none of labels falling on round numbers.  It should 
either label every multiple of .5, or every multiple of 1.

Sorry to be persnickety about this, but I think these details are critical to 
help students understand the graphs they are making.

Original comment by bgoldow...@gmail.com on 9 Feb 2012 at 10:19

I added an extra tick mark that seems to make this much more pleasant to look 
at, try it now (revision 53).

Original comment by RobertLe...@gmail.com on 10 Feb 2012 at 5:20

The -10 to 10 case and .5 to 5 cases look better, but the algorithm still 
doesn't correctly pick only multiples of some number.  In other words, it looks 
like it starts at Xmin rather than starting at 0.

Try the following cases:

0.9 to 10
-0.1 to 10
-3.5 to 10

In all these cases, the best points to label would be 0, 1, 2, 3...10.

Original comment by bgoldow...@gmail.com on 10 Feb 2012 at 6:42

Try it now, much more solid.

Original comment by RobertLe...@gmail.com on 10 Feb 2012 at 8:28

Most everything looks good.  It seems willing to pick 1,3,5 rather than 2,4,6 
(multiples of 2) as points, but that may be something we can live with (will 
have to run it by the math teachers).

The -3.5 to 10 case is coming out very weird, though - see screenshot, and note 
the uneven spacing of the ticks on the Y axis.

Original comment by bgoldow...@gmail.com on 10 Feb 2012 at 9:51

Attachments:

This is now fixed (revision 60) problem was that I created the label smallest 
to largest, then reversed them, without reversing the pixel ticks.  Solution 
was to put in better reverse functionality.

Original comment by RobertLe...@gmail.com on 10 Feb 2012 at 10:58

I think we can call this complete.

Original comment by bgoldow...@gmail.com on 22 Feb 2012 at 5:01

  • Changed state: Fixed