Refine breaking control on log-scaled axes

[mikeroswell]

The argument n in divMultBreaks should control the number of breaks, but in most cases has no effect. Perhaps a guide, scales::log_breaks (which is kind of crazy) does have more refined control.

# this is not true, nine gives more, finer breaks than does four (as expected)
all.equal(
   scales::log_breaks(n = 4, base = exp(1))(exp(c(-2, 5)))
   , scales::log_breaks(n = 9, base = exp(1))(exp(c(-2, 5)))
)

# this is true (and shouldn't be)
all.equal(
   divMultBreaks(n = 4)(exp(c(-2, 5)))
   , divMultBreaks(n = 9)(exp(c(-2, 5)))
)

# split argument lets you get finer breaks 
all.equal(
   divMultBreaks(n = 4)(exp(c(-2, 5)))
   , divMultBreaks(n = 4, split = TRUE)(exp(c(-2, 5)))
)

# but still not sensitive to n (and should be)
all.equal(
   divMultBreaks(n = 4, split = TRUE)(exp(c(-2, 5)))
   , divMultBreaks(n = 9, split = TRUE)(exp(c(-2, 5)))
)

[dushoff]

Please don't use T as shorthand for TRUE (even though it often works) unless you are punching cards :-)

[mikeroswell]

When data range straddles 1, we need a good way to generate more breaks. Ideally, these would have symmetrical "divMult" values.

my_limits <- c(0.698, 2.044)
# this is no good
breaks_divMult(my_limits) # only 3 values
# grDevices::axisTicks switches to linear spacing
axisTicks(log(my_limits, base = 10), log = TRUE)

[dushoff]

I feel very much like the original version I wrote took an argument for breaks.

On Mon, Nov 27, 2023 at 9:03 AM Michael Roswell @.***> wrote:

Caution: External email.

When data range straddles 1, we need a good way to generate more breaks. Ideally, these would have symmetrical "divMult" values.

my_limits <- c(0.698, 2.044)

this is no good

breaks_divMult(my_limits) # only 3 values

grDevices::axisTicks switches to linear spacing

axisTicks(log(my_limits, base = 10), log = TRUE)

— Reply to this email directly, view it on GitHub https://github.com/mikeroswell/ratioScales/issues/3#issuecomment-1827893875, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAW5E6LRSBSCRFOBNFH6P6LYGSMTFAVCNFSM5SJCMCOKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSG44DSMZYG42Q . You are receiving this because you were mentioned.Message ID: @.***>

-- Jonathan Dushoff (https://tinyurl.com/jd-pronouns) McMaster University Department of Biology https://mac-theobio.github.io/ http://jd-mathbio.blogspot.com/

[mikeroswell]

@dushoff, Your feeling is correct, but it is still based on the grDevices::axisTicks() machinery and I think that function often essentially ignores the breaks argument... you also wrote up a good workaround that adds breaks at 2,5, 10 or 3, 10 based on orders of magnitude but when the data fall within an order of magnitude this is insufficient...

axisTicks() actually reverts to linear breaking over small-ish data ranges like this which, though it might be a reasonable choice overall, doesn't give very satisfying "divMult" tick locations.

Anyways, I don't think I broke something that you wrote and was previously working, but if you are pretty confident otherwise I'd be eager to revert those changes!!!!

[dushoff]

Not very confident. It might be worth just going back to what I originally sent and confirming that it has the same problem. I'm kind of interested in looking for myself, but realistically not soon.

On Mon, Nov 27, 2023 at 1:30 PM Michael Roswell @.***> wrote:

Caution: External email.

Your feeling is correct, but it is still based on the grDevices::axisTicks() machinery and I think that function often essentially ignores the breaks argument... you also wrote up a good workaround that adds breaks at 2,5, 10 or 3, 10 based on orders of magnitude but when the data fall within an order of magnitude this is insufficient...

axisTicks() actually reverts to linear breaking over small-ish data ranges like this which, though it might be a reasonable choice overall, doesn't give very satisfying "divMult" tick locations.

Anyways, I don't think I broke something that you wrote and was previously working, but if you are pretty confident otherwise I'd be eager to revert those changes!!!!

— Reply to this email directly, view it on GitHub https://github.com/mikeroswell/ratioScales/issues/3#issuecomment-1828393564, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAW5E6PFCUV75DNGRATLQFDYGTLZ3AVCNFSM5SJCMCOKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSHAZTSMZVGY2A . You are receiving this because you were mentioned.Message ID: @.***>

-- Jonathan Dushoff (https://tinyurl.com/jd-pronouns) McMaster University Department of Biology https://mac-theobio.github.io/ http://jd-mathbio.blogspot.com/

[mikeroswell]

Confirming this issue was not previously solved http://dushoff.github.io/notebook/outputs/breaks.Rout.html

We have determined it might be a rabbit hole in the past and tabled it. I just don't want to lose track of it. Symptom is that we kind of need to find data with larger ratio-scale changes in order for divMult scale illustrations to be convincing.

[dushoff]

The last part is true anyway. If ratios are near 1, divmult isn't supposed to change much 😀.

For symmetry, it would help to give a symmetric range (or to have a symmetrize option and apply it to the range).

The original function has an nmin which can be useful, but which does not address symmetry the way you might want (not sure if you kept it), maybe combine that with symmetrizing would address some issues, but not the issue that if everything is close to 1 it all looks the same.

On Tue, Nov 28, 2023 at 3:20 PM Michael Roswell @.***> wrote:

Caution: External email.

Confirming this issue was not previously solved http://dushoff.github.io/notebook/outputs/breaks.Rout.html

We have determined it might be a rabbit hole in the past and tabled it. I just don't want to lose track of it. Symptom is that we kind of need to find data with larger ratio-scale changes in order for divMult scale illustrations to be convincing.

— Reply to this email directly, view it on GitHub https://github.com/mikeroswell/ratioScales/issues/3#issuecomment-1830662034, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAW5E6OK773Y4XRC3FSZ6H3YGZBRXAVCNFSM5SJCMCOKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBTGA3DMMRQGM2A . You are receiving this because you were mentioned.Message ID: @.***>

-- Jonathan Dushoff (https://tinyurl.com/jd-pronouns) McMaster University Department of Biology https://mac-theobio.github.io/ http://jd-mathbio.blogspot.com/

[mikeroswell]

Re: ratios close to 1, yup. But I like the symmetrize options suggestion. I retained nmin but after adding the split_decades function it is often preempted; I'll revisit that. Thanks, I think with symmetry and better discussion between nmin and splits arguments, I can probably get us somewhere better. I'll remove the "needs help" flag from this issue and assign myself on GH.

[mikeroswell]

Discussed two strategies to resolve. First, magic 5 good-looking numbers (like 2,5, 10) to get finer breaks Second, reflect the coarser scale (i.e., the side farther from 1 for divMult) --which might need to be finer than is currently possible (see above).

[dushoff]

The magic breaks are 1.25, 1.6, 2, 2.5, 3.2 4, 5, 6.4, 8, 10. Using just every other one produces its own set of magic breaks (you would start with 1.6); this one could presumably be productively incorporated into the 2, 3 code right now. We could also add a set for 4 breaks (it doesn't appeal to me as much aesthetically, but we shouldn't get stuck on that: 1.8, 3.2, 5.5 would not suck.

It would be cool to have code that tries to use all of the magic breaks (maybe for ranges between 0.5 and 1.5 decades?).

Finally, I think that either the "all of the magic breaks" approach or the "reflection" approach could usefully be supplemented by adding one or two extra ticks (using the current, disliked default) only when one side of the plot would otherwise not have any.

[mikeroswell]

It would be cool to have code that tries to use all of the magic breaks (maybe for ranges between 0.5 and 1.5 decades?).

By this do you mean the 10/5 set and the 4 set, i.e. it would begin 1.25, 1.6, 1.8, 2, 2.5, 3.2 etc?

And what do you mean by "try?" Do you simply mean truncating once you get out of range?

[dushoff]

1. No, I just meant the long list. I added the 4 set later.
2. I don't know why I said "try", but you got the broader intention correctly.