-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tick marks on log scale are not always well distributed #83
Comments
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 |
code to correct where step size for next decade was miscalculated.
I think this is fixed, and the code is more clear now. See
|
code to correct where step size for next decade was miscalculated.
Actually I found a bug with the fix. I believe it's fixed now. |
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:
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 |
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 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](https://private-user-images.githubusercontent.com/17085823/283212011-95af899d-bf3e-4e12-8939-03a9645b092c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjIyNTM4ODgsIm5iZiI6MTcyMjI1MzU4OCwicGF0aCI6Ii8xNzA4NTgyMy8yODMyMTIwMTEtOTVhZjg5OWQtYmYzZS00ZTEyLTg5MzktMDNhOTY0NWIwOTJjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MjklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzI5VDExNDYyOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTRhNmE2MGU3YjIyMzNjMzkwOTAzZmJmZGE2NWYxZWI3MzM1ZjkzZmRhODg4NTU0NmQzZGUxYzJmOTAzOTE2NmMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.u48TRPgPalk1kSafYf24uCWyjQNm__f33IK55eUO3yU)
![zoomed-in-plot](https://private-user-images.githubusercontent.com/17085823/283212031-541ec635-26cd-4baa-9fed-c2a225c8429c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjIyNTM4ODgsIm5iZiI6MTcyMjI1MzU4OCwicGF0aCI6Ii8xNzA4NTgyMy8yODMyMTIwMzEtNTQxZWM2MzUtMjZjZC00YmFhLTlmZWQtYzJhMjI1Yzg0MjljLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MjklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzI5VDExNDYyOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTc5YWY0MDIyMDZiODBmMjM3Nzk4YTU3MDQwMmQ4ODA4Y2E4NzhiZGQ5NjI2MjhkNzVhYTFmM2E3NDdmMjAyZTImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.siujFFAKJyKJ6ylb5vk7u3r_AId7eNJg67OrPpw_PXU)
![more-zoomed-in](https://private-user-images.githubusercontent.com/17085823/283212069-268d4ef5-f3c7-48d7-85e6-8ac32667c72c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjIyNTM4ODgsIm5iZiI6MTcyMjI1MzU4OCwicGF0aCI6Ii8xNzA4NTgyMy8yODMyMTIwNjktMjY4ZDRlZjUtZjNjNy00OGQ3LTg1ZTYtOGFjMzI2NjdjNzJjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MjklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzI5VDExNDYyOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTlhNGNkZjA1MzU5YjE5M2M3YmI2YTg2YjM1YTUyMjhkMDI5Y2Y3NTBmODFkYWUzZmNlYjNlNGFiZWFlZjkyMDQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.Xx2LUycs2j1o10YRXzA6-Vc-6BUH8uOP49rfyjPR2WI)
The text was updated successfully, but these errors were encountered: