das-developers / das2java

The original das2 library. Provides interactive publication-ready 2-D plotting
https://das2.org
GNU Lesser General Public License v3.0
4 stars 0 forks source link

Tick marks on log scale are not always well distributed #83

Open DiamondJim87 opened 7 months ago

DiamondJim87 commented 7 months ago

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.

original-plot zoomed-in-plot more-zoomed-in
DiamondJim87 commented 7 months ago

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

jbfaden commented 7 months ago

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

image

jbfaden commented 7 months ago

I think this is fixed, and the code is more clear now. See https://github.com/das-developers/das2java/blob/196d2ac18ed82604ef92f9cbc2d5ad29526d98f0/dasCoreDatum/src/org/das2/datum/LogLinDomainDivider.java#L72

jbfaden commented 7 months ago

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

DiamondJim87 commented 7 months ago

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.

Screenshot 2023-11-16 at 8 34 36 AM
jbfaden commented 7 months ago

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.

jbfaden commented 7 months ago

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.

jbfaden commented 7 months ago

See the change here, which simply falls back to linear when the ratio of the max to the min is less than 3.5: https://github.com/das-developers/das2java/commit/32c473ce9e096c7a048c532adb1610a9345a0379

DiamondJim87 commented 7 months ago

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:

Screenshot 2023-11-16 at 10 56 37 AM
jbfaden commented 7 months ago

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:

image

jbfaden commented 7 months ago

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

VoyagerPWS commented 7 months ago

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.

jbfaden commented 7 months ago

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!

jbfaden commented 7 months ago

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