octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Bateman
Subject: Re: AW: Re: Rewritten version of bar.m
Date: Wed, 18 Apr 2007 23:17:13 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

John W. Eaton wrote:
> 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
> 

Ok, done.

D.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]