Fri 01 Jul 2016 04:55:13 PM UTC, comment #4:
Wait, actually the long long type did work. I forgot to change the explicit cast from <int> to <long long>. Here's what I see:
So the attached patch works. Again, it seems like there should be a better approach that subtracts out the mean or "median integerized value", if you follow what I'm saying. I.e., so that i1 and i2 become 0 and 7. Part of the reason I say this is that the y-axis labels become meaningless--they all say "15". In gnuplot, something like:
has y axis labels:
15.00000004
15.00000003
15.00000003
15.00000002
15.00000002
15.00000001
15.00000001
15.00000000
That's a little improvement, but still it seems one should be able to write this as 15+##e-8 if you follow.
Anyway, the attached patch works, and I'm inclined to be content with it because of how time-consuming it is to compile the project when the graphics.cc file is touched.
PS: I can guess why the out-of-memory error message of the original bug. In the code is
Matrix tmp_ticks (1, i2-i1+1);
when the i2 and i1 are bogus, it is probably trying to create some huge matrix.
(file #37655)
|
Fri 01 Jul 2016 08:49:23 AM UTC, comment #3:
I followed this one through the code. This is the failing line:
(I put some debug lines in _line_.m and got a plot but there is no y-axis tics or labels.) _go_line_ is internal, in the file graphics.cc as follows:
And GO_BODY is
which takes us to
My best guess is that internally something is going wrong with the line construction or plotting and the return value of _go_line_ is invalid such that Octave thinks it is trying to index something (what should be a returned handle) it doesn't know about. E.g., there is no "ans = -2.1370" or something like it even though my plot is occurring.
The construction of the line and its properties seems pretty straightforward. There is a go.initialize() though, and this function gets called (I placed the fprintf() calls within):
Here is what I'm seeing (snipping out the garbage):
That seems OK, nothing is being lost in the data (e.g., there is no double conversion to float or int or anything).
-verbatim-
Maybe it is this routine:
YES, I think that is where the problem lies. I can say that this is not correct:
The result I see is:
Because the tick_sep turns out to be so small, the division is putting that double value outside the range of an int and the value is wrapping to negative numbers.
I changed the type of i1 and i2 to "long long", but that didn't fix the problem. I suppose it is the double arithmetic that is saturating. But I'm not sure that is the way to fix this anyway. Probably the right thing to do is to subtract the mean value from the data somehow before doing the range integerization. (Takes quite a while to compile though, so I've had enough for now.)
|
Thu 30 Jun 2016 09:04:49 AM UTC, original submission:
I built a debug version of the development sources (see the attached output from _octave_config_info_) and ran the test_plot.m script that is also attached. Results:
|