Re: Proposal for Matlab style errorbars (help requested)

[Ben Abbott]

On Apr 30, 2010, at 7:58 AM, Ben Abbott wrote:

> On Apr 29, 2010, at 8:49 PM, Ben Abbott wrote:
> 
>> On Apr 29, 2010, at 3:37 PM, David Bateman wrote:
>> 
>>> Ben Abbott wrote:
>>>> I've modified __errplot__.m to produce Matlab style errorbars, and would 
>>>> like some feedback before pushing.
>>>> 
>>>> I'm not sure how the box style error bars (#) are supposed to look. For my 
>>>> setup they look identical to the normal ones (i.e. "#~>" looks like "~>"). 
>>>> Rather than duplicate the same "look", I made the box styles look like 
>>>> "boxes".
>>>> 
>>>> I haven't pushed this yet, but did add some demos to errorbar.m. I 
>>>> recommend pulling that change to make testing/demoing this changeset 
>>>> easier.
>>>> 
>>>> Of course, as an added bonus, this implementation works with the fltk 
>>>> backend.
>>>> 
>>>> Ben
>>>> 
>>>> p.s. I hope no one minds that I cc'd everyone involved in the discussion 
>>>> on the bug tracker. 
>>>> 
>>> As far as I can see the changes to __errplot__ itself are cosmetic.. The 
>>> big change is in the updata_data subfunction and with the little testing 
>>> i've done it seems ok. I have two points however. If we make this change to 
>>> would be a good idea to try and pick the same parameters using in the 
>>> errorbar lines in the matlab version of this. I don't have matlab. In 
>>> particular is the value of  dx,  etc the same as used in matlab? It would 
>>> also make sense to remove the ldata, udata, xldata and xudata from the line 
>>> objects of Octave, and from __go_draw_axes__ as they will no longer be used 
>>> after this patch. This values will only be in the hggroup itself
>>> 
>>> Cheers
>>> David
>> 
>> 
>> I've verified the width of the error-bar by ...
>> 
>>      xmax = 100;
>>      figure(1)
>>      clf
>>      x = [0, xmax];
>>      y = [0, 0];
>>      dx = diff(x)/100;
>>      err = [1 1]*dx;
>>      errorbar (x, y, err, '-sb')
>>      axis equal
>>      axis ([-2 2 -2 2]*dx)
>> 
>> Independent of the value for xmax, the resulting errorbar fits into a 
>> perfect square. I think this confirms that dx = (max(x)-min(x))/100;
>> 
>> This matches what I saw in the figured linked to below.
>> 
>>      http://www.mathworks.se/matlabcentral/fx_files/22826/4/errorbar_tick.gif
>> 
>> I'll remove the FIXME comment regarding the errorbar width.
>> 
>> It occurred to me today that semilogxerr, semilogyerr, and  loglogerr each 
>> call __errplot__ as well. I'll modify dx so that it works correctly with 
>> axes.scale=="log".
>> 
>> Once I've pushed the change to __errplot__, I'll take care of 
>> __go_draw_axes__.m and graphics.h.in.
>> 
>> Ben
> 
> I've pushed the change below (which supports semilogxerr, semilogyerr, and 
> loglogerr).
> 
>       http://hg.savannah.gnu.org/hgweb/octave/rev/f0a7a72c1fbf
> 
> I plan to work on __go_draw_axes__.m and graphics.h.in this weekend.
> 
> Ben

I've pushed the changes to __go_draw_axes__.m, but when I moved on to 
graphics.h.in I noticed other files were referencing the {l,u,xl,xu}data 
properties.

Specifically, I see references to {l,u,xl,xu}data in graphics.cc, graphics.h, 
graphics-props.cc, and graphics.h.in.

Before I begin a (possibly) futile attempt to remove these references, I 
thought I'd ask for advice as I'm functionally illiterate in c/c++.

Ben

p.s. I don't mind making a feeble attempt at changing these files, but having 
someone more expert in c/c++ do it might be wise.