Tick marks on log scale are not always well distributed

I have a plot that has about 3.5 decades of log scale for the X axis. The initial tick marks every decade are great. But if I zoom in, the ticks don't smoothly/evenly cover the available space in a nice-to-read way. The attached screen shots show the issue pretty clearly.

Don't know if this is related, but our console has a bunch of messages like this that happen as I zoom in and out:

Nov 15, 2023 11:49:52 AM org.das2.qds.ops.Ops findex
WARNING: alarming extrapolation in findex is suspicious: count:1 uu:1.0 to 2047.0 vv:6.76430E6 to 6.76430E6
Nov 15, 2023 11:49:52 AM org.das2.qds.ops.Ops findex
WARNING: alarming extrapolation in findex is suspicious: count:1 uu:1.0 to 2047.0 vv:6.76430E6 to 6.76430E6
Nov 15, 2023 11:49:52 AM org.das2.qds.ops.Ops findex
WARNING: alarming extrapolation in findex is suspicious: count:1 uu:1.0 to 2047.0 vv:6.76430E6 to 6.76430E6
Nov 15, 2023 11:49:52 AM org.das2.qds.ops.Ops findex
W

This code demos the bug in Autoplot:
plot( None, xlog=True, xrange='90.0 to 600.0', ylog=True, yrange='90.0 to 600.0' )

I think this is fixed, and the code is more clear now. See

das2java/dasCoreDatum/src/org/das2/datum/LogLinDomainDivider.java

Line 72 in 196d2ac

while ( m.value()<nextDecade*0.9999 ) { // kludge for real number fuzz...

Actually I found a bug with the fix. I believe it's fixed now.

It is definitely greatly improved! In most cases it makes useful choices. When straddling a decade boundary, there can still be cases like this. I would love it if there were one more tick on the right side, preferably right at the right-most boundary. I feel like such a prima donna for asking, but I'm thinking like my users now, who would be able to read this, but would like it better if they knew what number to ascribe to the right side of the plot.

I don't mind your asking, but it might be a little tricky. I think in this case, where it's using the LogLin algorithm, it should have the smarts to know that Lin (linear) is what's best here. Then you would have ticks at 90,95,100,105,110. A narrow range on log axis is essentially a linear axis, and linear axis ticks should be used. I think there's some mode where the log axis flips over to Lin, and maybe I was naive in thinking that the new LogLin could replace that mode.

Either way we need to have a bunch of tests identifying these conditions, and the most acceptable set of ticks.

Why not here:

range, 1000 pixels	ticks
90-110	+5/5
90-400	90,95,100,150,200,250,300,350,400

It looks like you can edit it.

See the change here, which simply falls back to linear when the ratio of the max to the min is less than 3.5: 32c473c

This is really great -- this totally solves the odd corner cases and I think it works well most everything I tried. I do still have numbers running into each other at times on log scale, but this appears to be unrelated to these most recent changes:

Interesting, because that's using the old code. I wonder if the solution is to allow non-uniform ticks. I always figured it would get confusing if the ticks didn't immediate jump out as having log spacing. I wonder what it would look like to have 100,150,200,250,300,350,400,500,600,700,800,900,1000/5:

Another goal I've got with all of this is to have a nice way of expressing the algorithm used, so that you can force it. For example, we* could have +50,+100/5 meaning it could choose from either spacing.

(*) See how I did that, you are part of the solution team now...

The algorithm essentially just breaks "awkward" log intervals into sub-intervals, right? (Too-crowded bumps the scale up and too sparse bumps the scale down.) Also, an important measure to take into account for axes is the size in M.

Larry, yes, there's another thing I need to do with this algorithm. Most of the algorithms account for the font size, but I think this one doesn't do that. Thanks for reminding me!

Also I noticed *1E2, which should skip every other decade, draws minor ticks for the first decade but not for the second.

I just got a case where only one tick is drawn, which should never happen, see screenshot. This is 7.8E-18 to 9.7E-17 , log, 432-56 pixels high.

Also I noticed a case Bill had where the major ticks were 2,4,6,8,10,30,50. In this case 2,4,6,8,10,20,40,60,80 should be used.

I believe this is fixed, where the conditions resulted in 1 tick. The check for the number of ticks had some fuzz added to the calculation which accounted for numerical precision was too loose, including a tick where the axis fuzz logic wouldn't. The check was made tighter. See https://github.com/autoplot/dev/blob/master/bugs/ghdas2/0083/demoOneTickLog.jy

I've corrected the bug where Bill's plot had 2,4,6,8,10,30,50. See https://github.com/autoplot/dev/blob/master/bugs/ghdas2/0083/demoOddLogLin.jy.