[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal for Matlab style errorbars (help requested)
From: |
Ben Abbott |
Subject: |
Re: Proposal for Matlab style errorbars (help requested) |
Date: |
Fri, 30 Apr 2010 19:56:54 -0400 |
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.