Re: AW: Re: Rewritten version of bar.m

[John W. Eaton]

On 18-Apr-2007, David Bateman wrote:

| See the attached version, where I vectorized the code as much as
| possible, though I'm not sure it makes much sense to have a large number
| of bars on the plot, and so we probably won't profit from the vectorization.
| 
| > The bar/barh arguments can be (almost) in any order and it will 
| > work!
| > BTW, matlabs code is much more complex without to know why ...
| > 
| 
| I believe X and Y have to be the first and second argument of bar/barh.
| I see no reason to accept them in any other position.
| 
| Most of the arguments passed to bar/barh are plot properties and can be
| passed to the underlying patch or plot command to treat. Only the width,
| "grouped" or "stacked" argument needs to be treated locally. So
| identifying these arguments and removing them before. One complexity is
| that properties come in pair, but bar/barh can have a LineSpec that is a
| single argument, so something like
| 
| bar(x,y,'g',0.7,'LineWidth','1.5')
| 
| won't be easy to parse, using pltopt should simplify it though.

Right, I think plot does this more or less correctly now, using
pltopt.  If there are options, then I think the linespec arg comes
first followed by the other property/value pairs.

| tried to treat all of these issues previously, but missed the pltopt
| issue. The attached version fixes that as well. As plot/patch does most
| of the work the code is fairly simple relative to the octplot version.

OK, please check in these changes.

Thanks,

jwe