Sat 14 Oct 2017 02:58:18 PM UTC, comment #25:
I checked in version 3 of the patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/196ea1ee99b8). Closing report.
|
Sat 14 Oct 2017 02:46:21 AM UTC, comment #24:
The two bars are the same color, I assume. That would be consistent with the third version, i.e., the equivalence of 'stacked' and 'grouped' when the input data is a vector as opposed to a matrix. That's the most self-consistent in terms of setting individual properties after the initial plot.
|
Fri 13 Oct 2017 06:28:41 AM UTC, comment #23:
@Rik: in both cases, two bars at positions 1 and 2.
|
Thu 12 Oct 2017 06:35:34 PM UTC, comment #22:
@Marco: Could you try the following under Matlab
Do the commands succeed? Is the plot actually a single bar with two parts, or does it plot this as two bars?
|
Sun 01 Oct 2017 06:14:41 AM UTC, comment #21:
I actually convinced myself in post #19 that the third version of the changeset was correct. :-)
Let's take a step back and think about consistency of the data and its interpretation (which I think version 3 is most self-consistent). In version 4, there's this construct:
I think any time the format of the stored data depends on an output property, such as stacked|grouped, it is precarious because somewhere the consistency is likely to fail. [There should be a computer engineering term for such a thing if there isn't one already (I'm a different branch of engineering)... something like transmutable data, i.e., the data can represent one form of presentation or another form of presentation.]
Because all the properties can be altered after the original call to bar(), it's as if the processing of x and y has to be delayed to the final subroutine. If after the fact, I change "barlayout" from a group to a stack, then we have to be certain that if y(:) is fed back through the bar() routine it's going to translate to y(:)', even with all the syntax variations. In this case, I don't think it does that quite right. Try this example:
The first stacked bar graph above is all purple (i.e., a plot of two stacks, one element per stack), the second is purple and yellow (i.e., a plot of one stack of two elements). The original data in both cases was [3; 4], but it has reached a different result depending on the path we took.
This self-consistency is why I started thinking
bar ([3, 4], 'grouped')
bar ([3, 4], 'stacked')
should be thought of as the equivalent plot, i.e., in both cases the [3, 4] is the Y of bar(Y,...).
|
Sun 01 Oct 2017 03:52:28 AM UTC, comment #20:
I completely re-vamped the input validation. See the attached bar.diff4. It now correctly (???) processes
as well as stuff that even Matlab rejects like
(file #42030)
|
Fri 29 Sep 2017 05:10:04 PM UTC, comment #19:
Eh, maybe this is fine:
If we think of the above as being stacked with three stacks and only a single sub-component per stack (rather than a single stack consisting of three sub-components), then it is the equivalent of
thought of as three groups with a single sub-component per group.
|
Fri 29 Sep 2017 04:53:19 PM UTC, comment #18:
Has the uniqueness test, transposing at the end if necessary is good. The one thing I'm still wondering about is how this should behave:
To my way of thinking, that should produce a stacked bar graph.
|
Fri 29 Sep 2017 03:48:59 PM UTC, comment #17:
Okay, I think I've got it working now. Attached is bar.diff3. It is actually more forgiving then Matlab in that it tries both orientations, row or column, when attempting to match the length of the X vector.
(file #41982)
|
Fri 29 Sep 2017 01:19:36 PM UTC, comment #16:
In response to comments #4 and #13: Matlab R2017a
|
Thu 28 Sep 2017 11:17:51 PM UTC, comment #15:
I agree that there is some question as to what is actually a grouped versus conventional bar graph in the vector case.
But the patch you created is close. I think the issue is that you haven't covered every instance of rows/cols with the new mod. My previous post had a "verbatim" issue, so I'm reposting.
The examples work, but it may have broken this case [similar to bar(1:10)]:
Maybe this test:
needs to be on cols(y) rather than rows(y). Also, there is a rows() here after swapping x and y that should be double checked (should it be y = x.'?):
|
Thu 28 Sep 2017 11:12:38 PM UTC, comment #14:
The examples work, but it may have broken this case:
Maybe this test:
|
Thu 28 Sep 2017 11:01:56 PM UTC, comment #13:
Actually, my patch doesn't appear to work for
I think it would be useful to understand how many objects Matlab returns from bar. Is it based on groups, or columns?
|
Thu 28 Sep 2017 10:43:19 PM UTC, comment #12:
Try the attached patch bar.diff2.
It
1) requires the first input to be numeric
2) requires any provided X values to be unique, but not necessarily in ascending order
3) makes all input Y vectors into column vectors which is what the remaining code expects.
It seems to work for me now on the various examples in this bug report.
(file #41955)
|
Thu 28 Sep 2017 09:46:33 PM UTC, comment #11:
Actually, this is a better illustration of my point:
|
Thu 28 Sep 2017 09:34:55 PM UTC, comment #10:
I can go along with that interpretation of bar(Y, width).
But there are a few things wrong with the patch.
The main thing is my original point that the data saved in the newly created property
cannot be conditioned on "stack", i.e., your line
turns a column vector into a row vector. It has to be the same format convention regardless of "stack" or "grouped" because after the initial "bar()" we should be allowed to change back and forth between the "barlayout" property.
As a consequence, there is this result with the patch:
Some other strange behavior (probably not unique to your patch):
produces a plot. Maybe we should also check to make sure the first argument is numeric and not a string.
|
Thu 28 Sep 2017 08:57:28 PM UTC, comment #9:
@Dan: Can you try my attached patch bar.diff? This is an easy bug to fix by changing the input validation. However, your cset doesn't handle this case
where the calling form is
(file #41952)
|
Thu 28 Sep 2017 08:49:11 PM UTC, comment #8:
The attached patch seems to do it by my way of thinking. Let me know what you think. Try:
or (same result)
and follow up with
Note that for some reason the "h = bar()" is returning two handles, both of which seem to control the bar graph appearance. Is that a separate bug?
(file #41951)
|
Thu 28 Sep 2017 08:12:27 PM UTC, comment #7:
I notice this error in the code:
which is not a requirement in the documentation. X can have any order, but there can be no duplicate elements.
|
Thu 28 Sep 2017 07:59:49 PM UTC, comment #6:
Following up on my second point in the previous post, let's add the following example to the list of clarification:
I think this should create a stacked bar chart, not a conventional bar chart. Noting again that it doesn't matter if we think of
as a group or a conventional bar chart because they are pretty much the same.
|
Thu 28 Sep 2017 07:34:36 PM UTC, comment #5:
I don't know. Documentation is quite exactly clear. However, a couple things come to mind.
- It now seems to me that switching the property between grouped|stacked after the fact should not be a problem. They share the same underlying data properties.
- Regardless of how the vertical vector case is treated, it seems to me that in no scenario should the bar(numeric, numeric, ...) treat this as anything other than bar(X, Y, ...). That is, in the following
X should be 1 and Y should be [3, 4]'; args{0} should not be [3 4]'. Further processing would conclude whether that is a sane X/Y pair.
The bug-reporter does have a good point though. If the documentation is taken literally, i.e., "Y being a vector" of no qualification horizontal or vertical, then there is no way of creating a grouped or stacked bar graph of just a single group (stack). (The matrix scenario has no ambiguity.) A single group of course is sort of indistinguishable from a plain bar graph, but a single stack is (well, I suppose if one includes barh, then it does sort of look like a barh plot, if one uses the extra Width property to achieve it). I can see an argument for not doing the y = y(:)'.
|
Thu 28 Sep 2017 04:00:21 PM UTC, comment #4:
For compatibility, what does Matlab do for
If y is a row vector it is clear that each column represents a different group. But in this case, Matlab might error out because two y-values have been specified which ostensibly should belong to different x-locations.
|
Thu 28 Sep 2017 03:31:26 PM UTC, comment #3:
In response to comment #2, the rest of the bar code depends on y being a column vector. We can't just remove it or ordinary bar invocations will fail.
Just for grins, I commented those three lines out. Here are the results
|
Thu 28 Sep 2017 11:28:45 AM UTC, comment #2:
Why is it not possible to simply remove the if block around line 47 in _bar_.m
?
|
Thu 28 Sep 2017 08:49:30 AM UTC, comment #1:
Confirmed. Printing out some info:
looks fine, but not so here:
In the code, because the number of rows (after transpose) of y doesn't equal that of x, the assumption is that the first argument is the Y (type "help bar" for first item on the list of valid formats). As a consequence, the code than treats the second argument as a property of sorts, and that's what the error message pertains to, i.e., [3 4]' is not a character string no less a property name.
So, the existence of 'stacked' needs to be checked first prior to processing the data input variations. It might be kind of tricky though, in the sense that the user might be able to switch 'barlayout' between stacked|grouped. Have to think about what that means if the data is specified in a way that implicitly describes what could only be "stacked" layout.
|
Thu 28 Sep 2017 06:36:29 AM UTC, original submission:
If I call
I see 4 bars, stacked two by two. But if I call
I get an error message, while I would expect two stacked bars. The problem is around line 47 of _bar_.m. For some reason, the second argument y is transformed into a column.
|