Fri 20 May 2016 07:29:48 PM UTC, comment #6:
Matlab R2015b
test 1:
plot appeared, image attached as comment5_test1.png
after test 2:
plot appeared, image attached as comment5_test2.png
after test 3:
plot appeared, image attached as comment5_test3.png
after test 4:
plot appeared, image attached as comment5_test4.png
(file #37215, file #37216, file #37217, file #37218)
|
Fri 20 May 2016 07:25:48 PM UTC, comment #5:
Here the output of Matlab R2016a
First test:
"I believe this will create a 4-row column of labels at every point." - No.
Second test:
"I believe this will create a single label at each point." - Yes.
Third test:
"Maybe it is supposed to error out." - Yes.
Fourth test:
"I believe thiss will create a single label at each point as in the second test." - Yes
|
Fri 13 May 2016 12:06:28 AM UTC, comment #4:
Can someone run the following code under Matlab and report back?
First test:
I believe this will create a 4-row column of labels at every point.
Second test:
I believe this will create a single label at each point.
Third test:
No idea what this will do. Maybe it is supposed to error out.
Fourth test:
I believe thiss will create a single label at each point as in the second test.
|
Thu 12 May 2016 01:10:35 AM UTC, original submission:
In my experience, filing a long or detailed bug report leads to fewer people reading or responding to it, so I've including a TL;DR for the lazy.
TL;DR: see attached screenshots. There's little I've said below that isn't summed up in the first screenshot.
I'm relatively new to Octave, but I was encouraged to report this when I was helped on IRC. I'm not experienced enough to demand Octave's behaviour is changed, but I can give you an idea of the experience which seems very suboptimal.
I made a minimal example and duplicated it four times with minimal changes to show a comparison of different configurations. You can run it once at see three random scatter plots with slightly different inputs.
The first subplot is 500 random points with 500 text labels, given as a 500x2 char vector (vector of strings). The 'x2' is because 2 characters is the max length of a label in this example. Renders correctly.
The second is also 500 random points with 500 text labels, but this time given as a cell array (500x1). Renders correctly.
The third is 500 random points with 499 text labels (to simulate an "off by one" user error). Text data is given as a vector of strings (char 499x2). This causes the first label text to be used for all labels, and the others to be ignored. This behaviour seems kinda weird. Perhaps it's acceptable to do this without a warning? I don't know.
The forth is 500 random points with 499 text labels, given as a cell array (499x1). This causes all 499 labels to be rendered for every one of the 500 points. This takes around 20 seconds to render on Windows (i7 2600 / GTX 460). This might be expectedly slow for Octave, but it is a performance issue, it's difficult to debug the off-by-one user error because of the performance issue, and it's very weird/unexpected behaviour even if it is vaguely documented to do this (though I'm not sure if it is).
The code:
A screenshot is attached of the output (awful_text_example_4_subplots.png).
The text output of the code (required, as one title is obscured in the screenshot):
Some might say the output is expected and desired, but I'll steam roll ahead and offer some suggestions to make the user experience better. Perhaps the community could come up with something which better matches how Octave does things and allows better backwards compatibility with existing code bases. Mostly I hope this bug report might be a launching point for discussion which motivates someone to develop Octave's code base further and make it a better open source product.
Recommended fixes:
1. At a minimum: Display a warning to the user if there is a mismatch between the number of labels and the number of data points when calling text(), unless there is only one label and it is only one line in length.
2. Change the behaviour of text() so it treats cell arrays similarly to vector arrays. i.e. create some consistency, although both behaviours seem bad when there are mismatched input lengths.
3. Implement a separate function (or require an additional parameter) to render the same lines of text multiple times (as what is currently default for cell data), or to force data to be ignored (as what is currently default for vector of strings input)
Those seem like the obvious answers, but perhaps the community could come up with and agree to a better solution.
More general recommendations:
4. Improve rendering times. I don't know anything about the internals of Octave's rendering engine, but I can't see why the first three examples should take 4+ seconds to render. Coming from a game development background, drawing 500 anti-aliased circles with 2-character labels should take microseconds, not seconds. If rendering times were improved, then debugging would become easier. Removing 20 seconds from the debug cycle allows more experimentation by the user. (See "Motivation / background" below for how this directly impacted my debugging of this)
5. Use a separate thread to respond quickly to user input. Closing the "Figure 1" window should not take 20 seconds (as you wait for it to finish rendering). And the software should not appear to be hung just because because you resized a window.
6. Display an "Executing..." message with a barber's pole or something to tell the user a script is still running and hasn't crashed.
7. Implement the table data type and readtable(), e.g. bug #44571 -- my initial bug would have been unlikely to come up if I was importing data in a uniform way. Instead I hacked together a couple of different methods to import the text and numeric data from a CSV.
8. Prevent subplots from rendering outside of their area. I would have liked to present my examples on a 2x2 subplot grid. :)
Motivation / background:
I was trying to draw a scatter plot of some CSV data I had generated elsewhere. I'd accidentally left the heading row in some of the data and it created a monstrosity (see real_world_example.png). When I was initially trying to debug my code, as I didn't know the problem, I just saw a lot of text filling up my scatter plot. So I reduced the number of labels from 512 to just 50 so it would render fast enough that I could debug. Doing that also cut down the clutter enough that I could see what it was actually going on (all labels being rendered at all points). At some point I fixed the off-by-one mismatch, but as I had cut down the number of labels being displayed, the weird rendering continued. I assumed it was the data format of labels. I went onto #octave to ask how to convert cells to a string array. IRC user jwe asked the right questions and pointed out the size mismatch of the data, and then encouraged me to file this bug report. I still don't know how to convert cell data to a vector of strings. Thanks for reading. I hope this bug report encourages you to work on improving Octave.
|