An HFI user had Y scale set to log mode with range 10e-9 to 10e-7. First, and possibly not related but I'm not sure, the tick marks were at "strange" locations/values/intervals - 2.6e-8 4.6e-8 6.4e-8 and 8.1e-8. Then the user tried to change range to 10e-8 ... 10e-7 and it went all strange on him. There was a weird label written on the y axis (10e-7) and the tick marks were in very strange locations and values.
It would be more useful if you could attach screen captures with bug descriptions like these. A picture is worth a thousand words. -----Original Message----- From: George Staikos [mailto:staikos@kde.org] Sent: Sunday, November 07, 2004 6:10 AM To: kst@kde.org Subject: [Kst] [Bug 92855] New: Major problem with ticks and axis scaling ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=92855 Summary: Major problem with ticks and axis scaling Product: kst Version: CVS-HEAD Platform: Compiled Sources OS/Version: Linux Status: NEW Severity: major Priority: NOR Component: plotting AssignedTo: kst kde org ReportedBy: staikos kde org An HFI user had Y scale set to log mode with range 10e-9 to 10e-7. First, and possibly not related but I'm not sure, the tick marks were at "strange" locations/values/intervals - 2.6e-8 4.6e-8 6.4e-8 and 8.1e-8. Then the user tried to change range to 10e-8 ... 10e-7 and it went all strange on him. There was a weird label written on the y axis (10e-7) and the tick marks were in very strange locations and values. _______________________________________________ Kst mailing list Kst@kde.org https://mail.kde.org/mailman/listinfo/kst
Created attachment 8208 [details] First snapshot, shows the first tick at ~2.8
Created attachment 8209 [details] Second snapshot shows the weird label
CVS commit by arwalker: Always use 0 or 10 minor ticks for default value for minor ticks when in log mode. If you are in log mode and the data range is too small (i.e. log(range) < 2) then you really shouldn't be in log mode. Under these conditions you can either give minor ticks at regular intervals which are seemingly random numbers, or minor ticks at irrgeular intervals which are round numbers. Neither is very satisfactory. As a result the current behaviour has been left unchanged. Also, fixed a problem where some major ticks were not displayed in log mode. Do we want to check this into HEAD? CCMAIL: 92855@bugs.kde.org M +38 -30 kst2dplot.cpp 1.299.2.1 --- kdeextragear-2/kst/kst/kst2dplot.cpp #1.299:1.299.2.1 @@ -1589,6 +1589,6 @@ void Kst2DPlot::genAxisTickLabels(QPaint setTicks(tp.tick, tp.org, Max*scale, Min*scale, bLog, isX); - tp.tick/=scale; - tp.org/=scale; + tp.tick /= scale; + tp.org /= scale; tp.iLo = (int)((Min-tp.org)/tp.tick); @@ -2455,16 +2455,8 @@ void Kst2DPlot::setTicks(double& tick, d int majorDensity = isX ? _xMajorTicks : _yMajorTicks; - if (is_log && max - min < 11 && max - min > 1) { - tick = 1.0; - } else { - // - // determine tick interval... - // - St = (max - min) / (double)majorDensity; - Exp = pow(10.0, floor(log10(St))); - // // check for hysteresis of y-axis tick spacing... // + St = (max - min) / (double)majorDensity; if (!isX && is_log == _isLogLast && _stLast != 0.0 && St/_stLast < TICK_HYSTERESIS_FACTOR && @@ -2473,5 +2465,18 @@ void Kst2DPlot::setTicks(double& tick, d tick = _tickYLast; auto_tick = _autoTickYLast; + } else if (is_log) { + if (max - min <= (double)majorDensity && max - min > 1.5) { + auto_tick = 9; + tick = 1.0; + } else if (max - min >= (double)majorDensity) { + auto_tick = 0; + tick = floor((max - min) / (double)majorDensity); + if (tick == 1.0) { + auto_tick = 9; + } } else { + auto_tick = 0; + Exp = pow(10.0, floor(log10(St))); + tick = ticks[0] * Exp; for (int i=1; i<iNumTicks; i++) { @@ -2480,15 +2485,19 @@ void Kst2DPlot::setTicks(double& tick, d } } - if (tick == 2.0*Exp || tick == 4.0*Exp) { - auto_tick = 4; } + } else { + // + // determine tick interval... + // + Exp = pow(10.0, floor(log10(St))); + + tick = ticks[0] * Exp; + for (int i=1; i<iNumTicks; i++) { + if (fabs((ticks[i] * Exp) - St) < fabs(tick - St)) { + tick = ticks[i] * Exp; } } - - if (is_log) { - if (max - min > 50.0) { - auto_tick = 1; - } else if (max - min > 20.0) { - auto_tick /= 2; + if (tick == 2.0*Exp || tick == 4.0*Exp) { + auto_tick = 4; } } @@ -5571,6 +5580,5 @@ void Kst2DPlot::plotAxes(QPainter& p, QR // if (_xLog) { - i = (int)floor((double)_xMinorTicks* - (xleft_bdr_px - 1.0 - x_orig_px)/xtick_px); + i = (int)floor((double)_xMajorTicks*(xleft_bdr_px - 1.0 - x_orig_px)/xtick_px); for (;xtick_px * i + x_orig_px < x_px - xright_bdr_px + 1; i++) { // @@ -5639,5 +5647,5 @@ void Kst2DPlot::plotAxes(QPainter& p, QR // if (_yLog) { - i = (int)floor( (double)_yMinorTicks * ( ytop_bdr_px - 1.0 - y_orig_px ) / ytick_px ); + i = (int)floor( (double)_yMajorTicks * ( ytop_bdr_px - 1.0 - y_orig_px ) / ytick_px ); for (; ytick_px * i + y_orig_px < y_px - ybot_bdr_px + 1; i++) { //
The remaining problem with the log axis tick marks is the assumption in the code that all major tick marks are placed at regular intervals. This works in log mode as long as the major tick marks go at multiples of 10. However, when the range is small (i.e. log(max)-log(min) < 1.5) this is no longer suitable. As major ticks must go at regular intervals the values associated with these tick marks now become "strange". The correct solution to this problem would be to remove the regular interval assumption in log mode, which means re-working a lot (if not all) of the axis code. Is this something we want to do? For which release?
Not for 1.0.0! Perhaps for now, we can disable log mode if the range is too small. cbn On November 8, 2004 01:34 pm, Andrew Walker wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=92855 > > > > > ------- Additional Comments From arwalker sumusltd com 2004-11-08 19:34 > ------- The remaining problem with the log axis tick marks is the > assumption in the code that all major tick marks are placed at regular > intervals. This works in log mode as long as the major tick marks go at > multiples of 10. However, when the range is small (i.e. log(max)-log(min) < > 1.5) this is no longer suitable. As major ticks must go at regular > intervals the values associated with these tick marks now become "strange". > > The correct solution to this problem would be to remove the regular > interval assumption in log mode, which means re-working a lot (if not all) > of the axis code. Is this something we want to do? For which release? > _______________________________________________ > Kst mailing list > Kst@kde.org > https://mail.kde.org/mailman/listinfo/kst
On Monday 08 November 2004 15:00, netterfield@astro.utoronto.ca wrote: > ------- Additional Comments From netterfield astro utoronto ca 2004-11-08 > 21:00 ------- Not for 1.0.0! > > Perhaps for now, we can disable log mode if the range is too small. It happens when the range is 10e8:10e9 too. Is that too small? On a log sense it's 1 step, but it's still a big range. Anyway it certainly shouldn't go in 1.0, but we might need to find a quickfix for HFI.
Yes that range is too small, as log(10e9)-log(10e8)=1, which is too small. Its the same as a range from 1:10. If we disable log mode when the range is too small then we would also have to disable zooming in if it would make the range too small in log mode. Is this something I should do? For which branches?
On Monday 08 November 2004 16:51, Andrew Walker wrote: > ------- Yes that range is too small, as log(10e9)-log(10e8)=1, > which is too small. Its the same as a range from 1:10. > > If we disable log mode when the range is too small then > we would also have to disable zooming in if it would make > the range too small in log mode. I don't think the people here feel that is the case. Perhaps I'm missing something, but why is range=1 too small for log mode? Do we need to take log of numbers less than range? I have to admit I haven't really read this code. All I know is what I'm told by people who would otherwise be reporting themselves, but are using me as bugzilla instead. > Is this something I should do? For which branches? Would have to be developed as a patch attached to this report for now and applied later. I definitely can't put anything in HFI branch that isn't fully tested by me in their environment first. They go live tomorrow or wednesday.
Okay, here's my attempt to explain why this a problem. If we have a large range [log(max)-log(min)>2 say] then the major ticks are evenly spaced at powers of 10. Now, If we have a small range [1:10 say, the exact same argument applies to 10e8:10e9] then regardless of where we pick the major ticks [1,5,10 or 2,4,6,8,10, etc] they are not evenly spaced. If we put the major ticks at evenly spaced intervals then we end up with something like 1, 3.162, 10 for the labels. The current code assumes the major ticks are evenly spaced. I still feel that it doesn't make sense to be in log mode when you're dealing with a range of less than a factor of 100. If people there think it is possible then simply have them sketch out what they want, scan it in, and attach it to the bug report.
Does it make sense to drop the log base to 100 (or more as necessary)? Hrm I really do need to ask them why they want this. I'll do that tomorrow.
If we dropped the base to 5 or 2 as appropriate this would help handle a smaller range. Then we would need to store the base in the plot, and modify the max, min values appropriately.
On Monday 08 November 2004 18:41, Andrew Walker wrote: > ------- If we dropped the base to 5 or 2 as appropriate this > would help handle a smaller range. Then we would need > to store the base in the plot, and modify the max, min > values appropriately. Well I don't know what to say at this point. the guy who reported this as a problem is away anyways. Let's postpone this until after 1.0 for sure and deal with it when it comes up again.
I'll merge this patch into HEAD when I do the branch merging, for now, and we can consider new approaches later.
It appears that PLOT in IDL with /XLOG just drops labels all together once the range drops below 1 decade. What we do is at least marginally better (ie, it looks bad, but tells the truth. The correct solution is to use unevenly spaced major ticks when in log mode, and the range drops below a decade. This will be hard with the current code, and not currently worth it. Otherwise, best I can tell, it does what one would want. I'm going to close this; if someone gripes, we can re-open.
Change version to 1.x