matplotlib-devel Mailing List for matplotlib

Whoops, yes, that should be True... Also realized a slight error in
the description of how the mimum is set - both of those are fixed in
the attached diff.

On Tue, Aug 24, 2010 at 1:53 PM, Eric Firing <ef...@ha...> wrote:
> On 08/24/2010 08:39 AM, Erik Tollerud wrote:
>> I just realized the patch I sent before includes some other changes...
>> the attached version should only be the fix for this particular bug.
>
> +            if log is true:
> +                minimum = 1.0
>
>
> Don't you mean True, not true?
>
> Eric
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Erik Tollerud

On 08/24/2010 08:39 AM, Erik Tollerud wrote:
> I just realized the patch I sent before includes some other changes...
> the attached version should only be the fix for this particular bug.

+            if log is true:
+                minimum = 1.0


Don't you mean True, not true?

Eric

On Tue, Aug 24, 2010 at 1:48 PM, Erik Tollerud <eri...@gm...>wrote:

> Sorry for the re-ping if it was taken care of in some way I didn't
> undertand, but this doesn't seem to have been changed on the trunk
> svn... should it have been, or is there some other branch that this
> stuff is being worked on?
>
> On Tue, Jul 27, 2010 at 10:14 AM, Erik Tollerud <eri...@gm...>
> wrote:
> > Great - if anything's unclear, I can fairly easily make a test case as
> > Benjamin suggested, so just let me know if that's necessary - thank!
> >
> > On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres <re...@he...>
> wrote:
> >> Hi Erik,
> >>
> >> Sorry for the delay. From just looking at the diff I would say it's a
> >> great addition. I'll test tomorrow and push it if it works (which I
> >> assume it does).
> >>
> >> Cheers,
> >> Reinier
> >>
> >> On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud <eri...@gm...>
> wrote:
> >>> Just a quick ping about this - did it get applied, or was there
> >>> something wrong with it? (Or am I just too impatient?)
> >>>
> >>> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <
> eri...@gm...> wrote:
> >>>> I noticed some odd behavior when trying to set ticks on 3d plots made
> >>>> using mplot3d.Axes3D ... specifically, if you tries to access any of
> >>>> the 3D axes and change the ticks, it would result in a plot all
> >>>> squashed to one side (indicating some sort of projection problem).
> >>>> After a bit of digging, I discovered the source of the problem:
> >>>> axis.XAxis, the base of the 3D Axis class, calls set_view_interval,
> >>>> which is not overridden in mplot3d.axis3d.Axis, causing the wrong
> >>>> interval to get the range assigned when ticks were added.  So the
> >>>> solution was to implement set_view_interval on the 3D Axis.  That fix
> >>>> is attached as a diff against the current svn in mpl3d-ticks-fix.diff
> >>>> .  Now setting ticks seems to work just fine, so I've included another
> >>>> diff that additionally implements set_?ticks3d and get_?ticks3d
> >>>> methods for Axes3D - that's attached as
> >>>> mpl3d-ticks-fix-add-methods.diff .
> >>>>
> >>>> --
> >>>> Erik Tollerud
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Erik Tollerud
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> The Palm PDK Hot Apps Program offers developers who use the
> >>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> >>> of $1 Million in cash or HP Products. Visit us here for more details:
> >>> http://ad.doubleclick.net/clk;226879339;13503038;l?
> >>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
> >>> _______________________________________________
> >>> Matplotlib-devel mailing list
> >>> Mat...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>>
> >>
> >>
> >>
> >> --
> >> Reinier Heeres
> >> Tel: +31 6 10852639
> >>
> >
> >
> >
> > --
> > Erik Tollerud
> >
>
>
>
> --
> Erik Tollerud
>
>
I don't believe so, and I think this was shortly before Reinier went on
vacation.  Erik, my question still applies.  If you can make a nice short
example that demonstrates the problem, we can then include it as a test to
make sure it will always work properly.

If the patch passes the test, I can apply it myself now.

Ben Root

Sorry for the re-ping if it was taken care of in some way I didn't
undertand, but this doesn't seem to have been changed on the trunk
svn... should it have been, or is there some other branch that this
stuff is being worked on?

On Tue, Jul 27, 2010 at 10:14 AM, Erik Tollerud <eri...@gm...> wrote:
> Great - if anything's unclear, I can fairly easily make a test case as
> Benjamin suggested, so just let me know if that's necessary - thank!
>
> On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres <re...@he...> wrote:
>> Hi Erik,
>>
>> Sorry for the delay. From just looking at the diff I would say it's a
>> great addition. I'll test tomorrow and push it if it works (which I
>> assume it does).
>>
>> Cheers,
>> Reinier
>>
>> On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud <eri...@gm...> wrote:
>>> Just a quick ping about this - did it get applied, or was there
>>> something wrong with it? (Or am I just too impatient?)
>>>
>>> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <eri...@gm...> wrote:
>>>> I noticed some odd behavior when trying to set ticks on 3d plots made
>>>> using mplot3d.Axes3D ... specifically, if you tries to access any of
>>>> the 3D axes and change the ticks, it would result in a plot all
>>>> squashed to one side (indicating some sort of projection problem).
>>>> After a bit of digging, I discovered the source of the problem:
>>>> axis.XAxis, the base of the 3D Axis class, calls set_view_interval,
>>>> which is not overridden in mplot3d.axis3d.Axis, causing the wrong
>>>> interval to get the range assigned when ticks were added.  So the
>>>> solution was to implement set_view_interval on the 3D Axis.  That fix
>>>> is attached as a diff against the current svn in mpl3d-ticks-fix.diff
>>>> .  Now setting ticks seems to work just fine, so I've included another
>>>> diff that additionally implements set_?ticks3d and get_?ticks3d
>>>> methods for Axes3D - that's attached as
>>>> mpl3d-ticks-fix-add-methods.diff .
>>>>
>>>> --
>>>> Erik Tollerud
>>>>
>>>
>>>
>>>
>>> --
>>> Erik Tollerud
>>>
>>> ------------------------------------------------------------------------------
>>> The Palm PDK Hot Apps Program offers developers who use the
>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>>> of $1 Million in cash or HP Products. Visit us here for more details:
>>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>>
>>
>> --
>> Reinier Heeres
>> Tel: +31 6 10852639
>>
>
>
>
> --
> Erik Tollerud
>



-- 
Erik Tollerud

Did this fix ever get applied?  I was looking at some other svn
changes and it still says none of this part of legend.py has been
altered...

On Thu, Jun 10, 2010 at 8:50 AM, Jae-Joon Lee <lee...@gm...> wrote:
> On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud <eri...@gm...> wrote:
>> Jae-Joon, your patch looks to be effectively the same except for
>> slightly different behavior when more than 3 points are present... but
>> that was what was originally intended - the numpoints-> scatterpoints
>> was a good catch!
>
> I'm not sure if I put those numbers in the first places (maybe not),
> yes, that was what was originally intended. And I'm inclined to leave
> it as is.
>
> I'll commit the change soon.
> Thanks again.
>
> -JJ
>



-- 
Erik Tollerud

I just realized the patch I sent before includes some other changes...
the attached version should only be the fix for this particular bug.

On Mon, Aug 23, 2010 at 7:23 PM, Erik Tollerud <eri...@gm...> wrote:
> This is definitely a bug, but I thought I'd clarify and add in a little more...
>
> The distinction between 'step' and 'stepfilled' is that 'step' is
> supposed to show only the outline of the histogram with no lines in
> between bins (standard practice in some fields), while 'stepfilled' is
> supposed to do the same, but have a different-colored fill between the
> steps and the x-axis.  This is different from 'bar' because the bars
> always have either an outline bounding each bar, or no outline at all.
>  An alternative approach, presumably, would be to eliminate
> 'stepfilled' and instead just pass in some keyword that tells whether
> or not to draw the filled color region or not, but that was judged
> confusing because it would have no meaning for the bar types.
>
> As for the log=True errors, I think what this was supposed to do was
> have the minimum number of bin *counts* be the replacement for 0s,
> rather the minimum *value*, so that's just a pure bug.  This is might
> have been my fault - the code has changed quite a bit from the
> original patch, so I'm not sure at this point.  The logic was that
> this makes more sense than arbitrarily choosing 1 - if you have a
> histogram where the bins are all within, say, 1000 and 10000, but one
> of them is 0, it perhaps looks better to set the bottom to the 1000
> rather than 1... It was really just an arbitrary choice that no one
> objected to at the time.
>
> As I think about it, it might make sense to change it so that the log
> keyword can be used to set the assumed minimum value for empty bins if
> it is greater than 0 (and stick with the default you suggested of 1 if
> log=True).  The attached patch includes this change, adopted from
> Ben's original patch, as well as clarifying all of this in teh
> docstring.
>
>
> On Wed, Aug 11, 2010 at 1:56 PM, Benjamin Root <ben...@ou...> wrote:
>> On Wed, Aug 11, 2010 at 3:11 PM, Benjamin Root <ben...@ou...> wrote:
>>>
>>> I am tracing down a bug in hist() and I am trying to figure out what is it
>>> about the 'stepfilled' mode that is different from the regular 'bar' mode.
>>> Currently, the hist() code has a separate if branch for dealing with 'step'
>>> and 'stepfilled', and that branch has a bunch of bugs.  The best that I can
>>> figure is that it prevents lines from being drawn in between the bins.  If
>>> that is the only difference, maybe we could somehow use the bar functions?
>>>
>>> At the very least, I think this needs to be documented better to make it
>>> clear why this oddball approach is happening.
>>>
>>> Thanks,
>>> Ben Root
>>
>> By the way, the bugs I was referring to both have to do with log=True and
>> the two stepped modes.
>>
>> First, the smallest of values to histogram (the minimum bin value) is, for
>> some reason, used to clip the lower bounds of the histogram count. In some
>> situations, this can result in most if not all the graph not being shown.
>>
>> Second, related to the first is a problem with the 'stepfilled' mode in log
>> space.  The stepfilled mode uses the minimum bin value to anchor the
>> patches.  However, this can cause the polygon to not close correctly and can
>> get some unsightly artifacts. I have attached an image demonstrating this
>> bug.  This has been reported before:
>>
>> http://old.nabble.com/hist%28%29-with-log-and-step-tp28888742p28888742.html
>> http://old.nabble.com/Bug-in-stepfilled-hist-with-log-y-tp28538074p28538074.html
>>
>> In one of the comments, the reporter concluded that it appeared fixed, but
>> either he was experiencing a slightly different problem, or he was mistaken.
>>
>> I have also included a possible patch for addressing these issues.  The
>> approach simply sets the minimum value to be zero when not doing log, and
>> use 1.0 when log=True.  This differs slightly from how the normal bar graphs
>> are done where a value of 1e-100 is used when log=True, but then the axes
>> limits are adjusted to use 1.0 as a lower limit.
>>
>> Cheers,
>> Ben Root
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
>
> --
> Erik Tollerud
>



-- 
Erik Tollerud

This is definitely a bug, but I thought I'd clarify and add in a little more...

The distinction between 'step' and 'stepfilled' is that 'step' is
supposed to show only the outline of the histogram with no lines in
between bins (standard practice in some fields), while 'stepfilled' is
supposed to do the same, but have a different-colored fill between the
steps and the x-axis.  This is different from 'bar' because the bars
always have either an outline bounding each bar, or no outline at all.
 An alternative approach, presumably, would be to eliminate
'stepfilled' and instead just pass in some keyword that tells whether
or not to draw the filled color region or not, but that was judged
confusing because it would have no meaning for the bar types.

As for the log=True errors, I think what this was supposed to do was
have the minimum number of bin *counts* be the replacement for 0s,
rather the minimum *value*, so that's just a pure bug.  This is might
have been my fault - the code has changed quite a bit from the
original patch, so I'm not sure at this point.  The logic was that
this makes more sense than arbitrarily choosing 1 - if you have a
histogram where the bins are all within, say, 1000 and 10000, but one
of them is 0, it perhaps looks better to set the bottom to the 1000
rather than 1... It was really just an arbitrary choice that no one
objected to at the time.

As I think about it, it might make sense to change it so that the log
keyword can be used to set the assumed minimum value for empty bins if
it is greater than 0 (and stick with the default you suggested of 1 if
log=True).  The attached patch includes this change, adopted from
Ben's original patch, as well as clarifying all of this in teh
docstring.


On Wed, Aug 11, 2010 at 1:56 PM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Aug 11, 2010 at 3:11 PM, Benjamin Root <ben...@ou...> wrote:
>>
>> I am tracing down a bug in hist() and I am trying to figure out what is it
>> about the 'stepfilled' mode that is different from the regular 'bar' mode.
>> Currently, the hist() code has a separate if branch for dealing with 'step'
>> and 'stepfilled', and that branch has a bunch of bugs.  The best that I can
>> figure is that it prevents lines from being drawn in between the bins.  If
>> that is the only difference, maybe we could somehow use the bar functions?
>>
>> At the very least, I think this needs to be documented better to make it
>> clear why this oddball approach is happening.
>>
>> Thanks,
>> Ben Root
>
> By the way, the bugs I was referring to both have to do with log=True and
> the two stepped modes.
>
> First, the smallest of values to histogram (the minimum bin value) is, for
> some reason, used to clip the lower bounds of the histogram count. In some
> situations, this can result in most if not all the graph not being shown.
>
> Second, related to the first is a problem with the 'stepfilled' mode in log
> space.  The stepfilled mode uses the minimum bin value to anchor the
> patches.  However, this can cause the polygon to not close correctly and can
> get some unsightly artifacts. I have attached an image demonstrating this
> bug.  This has been reported before:
>
> http://old.nabble.com/hist%28%29-with-log-and-step-tp28888742p28888742.html
> http://old.nabble.com/Bug-in-stepfilled-hist-with-log-y-tp28538074p28538074.html
>
> In one of the comments, the reporter concluded that it appeared fixed, but
> either he was experiencing a slightly different problem, or he was mistaken.
>
> I have also included a possible patch for addressing these issues.  The
> approach simply sets the minimum value to be zero when not doing log, and
> use 1.0 when log=True.  This differs slightly from how the normal bar graphs
> are done where a value of 1e-100 is used when log=True, but then the axes
> limits are adjusted to use 1.0 as a lower limit.
>
> Cheers,
> Ben Root
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>



-- 
Erik Tollerud