Sat 04 Feb 2012 03:32:27 PM UTC, comment #32:
OK, I checked in one additional change on the stable branch:
http://hg.savannah.gnu.org/hgweb/octave/rev/a646cee995cf
With this change, zooming should work for positive log scale axes with the mouse wheel or the zoom box, but it should be disabled for any negative log scale axis.
|
Sat 04 Feb 2012 12:24:51 PM UTC, comment #31:
I found that zooming foe negative logs is disabled for the mouse wheel but not for the right mouse box.
Using the right mouse button (button 3) zoom still works but all the values change to positive values.
|
Sat 04 Feb 2012 02:41:46 AM UTC, comment #30:
I verified that the pixel positions seem to be correct now in linear, log, and negative log plots.
In fact, FLTK does a better job now than gnuplot. On gnuplot, plots with negative log axes are still shown as positive. The absolute value of the coordinate is correct, but they apparently forgot to take care of the minus sign.
I will close this bug and all the others related to mouse coordinates.
|
Sat 04 Feb 2012 01:03:43 AM UTC, comment #29:
I checked in a few more changes:
First, on the stable branch, I fixed a problem with minor tick marks for log scale plots, then disabled zooming for logscale axes. I disabled it because I don't see a way to make this work without some interface changes that could break binary compatibility. Maybe I went too far with that though. Perhaps it could be made to work with positive values but not negative?
http://hg.savannah.gnu.org/hgweb/octave/rev/a9a42d630bd5
http://hg.savannah.gnu.org/hgweb/octave/rev/45f5a5d5656f
Next, I fixed (I think) the pixel position to graph coordinate transformation for log scale plots with negative values.
http://hg.savannah.gnu.org/hgweb/octave/rev/5a2b012b10c7
So I think the zooming and panning problems are finally fixed on the default branch. Can someone verify?
Also, it appears to me that the cursor is now showing the correct values for plot coordinates in linear, log, and negative log plots. If all those things appear to be working, I think we can close this report.
|
Fri 03 Feb 2012 02:31:11 AM UTC, comment #28:
val = std::log10 (-val); this is line 6578
i changed it to
val = std::log10 (val); this is line 6578
Now the mouse weel zoom works OK but
the zoom box with the right mouse button
changes the negative values of the y axis to positive when zooming.
:-)
I will keep looking
|
Fri 03 Feb 2012 02:05:48 AM UTC, comment #27:
I think I found the nan problem on line 6578 of graphics.cc
if (is_logscale)
{
if (is_negative)
{
double tmp = hi;
hi = std::log10 (-lo);
lo = std::log10 (-tmp);
val = std::log10 (-val); this is line 6578
}
val is pos when we get here and this makes nans
I will recompile and try my fix
|
Thu 02 Feb 2012 10:14:04 PM UTC, comment #26:
Hmm, zooming or panning for loglog with negative values doesn't work at all for me.
For example:
I'm pretty sure the problem is with the conversion from pixel position to graph coordinate.
Look at the coordinate value that is displayed when you move the mouse around. For me, it is not negative, and not the value corresponding to points on the plot. Is it a log value? It doesn't match what I would expect, but I know there is another bug with coordinate values.
In any case, the code in do_zoom code expects VAL to be the position of the mouse pointer in axes coordinate values. Fix that, and I think zooming will work correctly.
I don't understand the coordinate transformation code. Maybe Michael Goffioul can help with this problem?
|
Thu 02 Feb 2012 08:40:25 PM UTC, comment #25:
Rik is correct I am at
doug@doug-desktop:~/octavecompile/octave$ hg id
17de694961f5
|
Thu 02 Feb 2012 08:36:52 PM UTC, comment #24:
Doug,
Are you sure you are at the tip? 'hg tip' reports what the tip of the repository is, but that is not the same as where your local directory is. Try 'hg id' to identify the current revision of your directory.
I am at revision 14317 on the stable branch and I can zoom correctly. This is on an Ubuntu Linux system.
|
Thu 02 Feb 2012 08:04:06 PM UTC, comment #23:
using
octave$ hg tip
changeset: 14317:7dee2bb231c1
branch: stable
this
graphics_toolkit fltk;
a = logspace (-5, 1, 10);
b =-logspace (-5, 1, 10);
loglog (a, b);
## Now try to pan the plot and it goes blank and the axis gets set to NaN.
also gives nans and blank screen when zooming
|
Thu 02 Feb 2012 06:18:20 PM UTC, comment #22:
Zooming and panning now work with log axes on the development branch.
There is one exception. If you create a loglog plot with negative values and attempt panning, before zooming, then the plot goes blank. If you zoom first, which must initialize some values, then the plot behaves correctly.
I'm in the process of closing down the other duplicate bugs for this behavior.
|
Thu 02 Feb 2012 05:15:49 PM UTC, comment #21:
I checked in some changes:
stable branch:
http://hg.savannah.gnu.org/hgweb/octave/rev/d4f37aa5d126
http://hg.savannah.gnu.org/hgweb/octave/rev/1734c3a48f31
followed by a merge from stable to default, then the following change on the default branch:
http://hg.savannah.gnu.org/hgweb/octave/rev/17de694961f5
Could someone please verify that these solve the reported problems in this and other related bug reports and if so, close the reports?
|
Thu 02 Feb 2012 04:16:51 PM UTC, comment #20:
The patch works good for me.
Zooming with mouse wheel is OK.
Zooming with right mouse button is OK.
Panning is OK.
|
Thu 02 Feb 2012 05:03:33 AM UTC, comment #19:
The attached patch seems to fix the problem for me for both zooming and panning, but I haven't done a lot of testing.
Unfortunately, it requires a change to a signature of a public function to fix the panning problem, so I don't think that portion of the fix can be included in 3.6.1. But if this fix is OK, then we could use the zooming part of the fix and simply disable panning for logscale to avoid the error.
Then this problem could be fully fixed in the next major release.
There may be another similar problem for rotation. I haven't checked that.
(file #24954)
|
Thu 02 Feb 2012 03:12:51 AM UTC, comment #18:
in graphics.cc in the area of line 5949 we have
if (is_logscale && ! (xisinf (hi) || xisinf (lo)))
{
// FIXME - what if (hi-lo) < tick_sep?
// ex: loglog ([1 1.1])
tick_sep = std::max (tick_sep, 1.);
tick_sep = std::ceil (tick_sep);
}
farther down we have:
Matrix tmp_mticks (1, n * (tmp_ticks.numel () - 1));
when it crashes tmp_ticks.numel () is zero
and therefore it tries to make an array with dim (1,-7).
It seem to be when the x range is less than 1 log cycle
so the fixme likely needs fixing.
I will look at it more, but just wanted to document where the problem is.
|
Tue 24 Jan 2012 03:24:07 PM UTC, comment #17:
I haven't looked at the zoom problem, but I do see an error with trying to click and drag on the plot window when log axes are involved.
The problem there seems to be that moving the plot needs to be done in terms of screen coordinates but the delta_x delta_y that are given to axes_properties::translate_view are based on data values, and we don't know where the mouse is. For example, if you have a plot that goes from 10^1 to 10^3 and delta is 10, it has a much different meaning if the mouse position is near 10^1 vs. 10^3, but the translate_view function doesn't have that information. So even if you adjust delta for the log scale, I don't see how the calculation of the new limits can be correct.
I don't see how to untangle this mess without major surgery, but maybe one of you will see a way to make it work. OTOH, if you do, I'm afraid that the result will be even messier and harder to maintain than what we currently have.
|
Thu 19 Jan 2012 07:21:45 PM UTC, comment #16:
In particular, I think the class log_scaler::scale may not behave well if it is fed weird data.
|
Thu 19 Jan 2012 07:18:18 PM UTC, comment #15:
I think the problem lies in graphics.cc. You might want to take a look at these changesets in Mercurial which appear to be related.
|
Thu 19 Jan 2012 06:58:08 PM UTC, comment #14:
loglog plots also crash on zoom with mouse wheel.
I am using gdb an bt to see if there is a common point where these crashes intersect.
|
Thu 19 Jan 2012 06:47:26 PM UTC, comment #13:
loglog plots also crash on panning
|
Thu 19 Jan 2012 06:15:39 PM UTC, comment #12:
Thanks for your help Rik
I will look at the log problem.
|
Thu 19 Jan 2012 05:58:04 PM UTC, comment #11:
Doug,
Thanks for the patch. I modified it slightly to conform to Octave coding standards. I did the following
1) Use spaces, rather than tabs, with an indent of 2
2) Limit lines, if possible, to less than 80 characters
3) Commit message changed to Octave syntax. We always refer to the bug # in the tracker in the first line of the commit message.
If you want to become a regular contributor try the "Tips and Standards" and "Contributing Guidelines" chapters in the Octave manual.
I also moved the mark_modified () call outside of the if block which checks for a minimum size selection region. Otherwise, the screen is not updated if the selection area was too small and this will leave little blue rectangles on the plot where the user failed to make a proper zoom selection.
I committed the changeset here if you want to take a look. (http://hg.savannah.gnu.org/hgweb/octave/rev/358b59706656)
So, this solves the first part of the problem which Doug reported. I still have a problem with right-mouse zooming with logarithmic axes and I am going to re-title the bug report to reflect that.
|
Thu 19 Jan 2012 02:43:41 PM UTC, comment #10:
I have attached a fix for this problem.
The problem was that if you tried to zoom in using the right mouse button, but did not drag the mouse , then the zoom factor would be infinite and cause a crash.
I have set the smallest zoom box to be 4X4 pixels whis gives a nice maximum zoom and stops very large unintentional zooms.
(file #24847)
|
Fri 13 Jan 2012 07:48:27 AM UTC, comment #9:
The bug seems to be same as
http://savannah.gnu.org/bugs/?35159
|
Thu 12 Jan 2012 06:22:09 PM UTC, comment #8:
I've got a hunch this has nothing to do with the bode plot code, but rather with logarithmic axes. The following code crashes for me.
If someone else can verify this behavior then I think we can make the bug report more specific.
The handling of logarithmic axes in FLTK has been a problem in the past.
|
Thu 12 Jan 2012 01:35:33 AM UTC, comment #7:
I'm marking this as a problem for any operating system. However, I'm not able to duplicate it on MacOS using fltk 1.3.
|
Thu 12 Jan 2012 12:25:33 AM UTC, comment #6:
Yes it crashes 3.6.0 the same way.
|
Thu 12 Jan 2012 12:15:23 AM UTC, comment #5:
ok. Changing the category.
Doug does 3.6.0 crash for you as well ?
|
Thu 12 Jan 2012 12:12:22 AM UTC, comment #4:
I have done some more investigating of this problem.
It is not just with the Bode plot. It seems to be a problem with any plot. I tried step, impulse and bode and plot, and they seemed to work the same. With any plot window you can resize it and zoom with the mouse wheel, and zoom with the right button, but if you press and release the right button without moving the mouse, then you get the crash. But if you do some activity with the left button (pan) then it wont crash on the right button until you do it 2 or 3 times.
So there is a problem when the mouse has not moved and some kind of a stack problem.
Doug Stewart
|
Wed 11 Jan 2012 11:51:40 PM UTC, comment #3:
It is with fltk only.
gnuplot does not crash for me.
Doug
|
Wed 11 Jan 2012 11:29:45 PM UTC, comment #2:
Does this work with fltk, but not with gnuplot ?
|
Wed 11 Jan 2012 08:28:44 PM UTC, comment #1:
this also crashes on octave 3.5.92 and Ubuntu 10.04
octave:10> g1 = tf([200],conv([1 1],[1 4]))
Transfer function 'g1' from input 'u1' to output ...
200
y1: -------------
s^2 + 5 s + 4
Continuous-time model.
octave:11> bode(g1)
octave:12> terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
panic: Aborted -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Aborted
doug@doug-desktop:~/oct395/octave-3.5.92$
Doug Stewart
|
Wed 11 Jan 2012 08:14:53 PM UTC, original submission:
I am using the Octave Control Systems Toolbox, http://www.obihiro.ac.jp/~suzukim/masuda/octave/html/octave_125.html.
When I use the bode function, which plots two graphs, the program crashes when I use the right mouse click zoom. I have tried zooming in on graphs from other functions in the control package and I haven't had the same problem.
Here is the code I am using:
g1 = tf([200],conv([1 1],[1 4])) #This is a transfer funcion I am interested in
bode(g1)
|