matplotlib-users Mailing List for matplotlib

John Hunter wrote:
> On Sat, May 30, 2009 at 11:52 AM, Eric Firing <ef...@ha...> wrote:
> 
>> No, that applies to the axis ticks but not to the readout, and I think it is
>> the latter that Xavier is concerned with--at least that is what I have been
>> talking about, and want to improve.
> 
> Just to clarify -- by "readout" do you mean the toolbar strings?
> 
> At first I was assuming that since the toolbar formatting picks up the
> tick Formatter to format the strings, and ScalarFormatter uses
> rcParams['axes.formatter.limits'] to determine when to fall over to
> scientific notation, that this setting would be picked up by the
> toolbar. The reason it does not is because ScalarFormatter overrides
> Formatter.format_data_short, which is what the toolbar uses via
> Axes.format_xdata/format_ydata, and ScalarFormatter.format_data_short
> does not use the formatter.limits setting. Are we at least on the
> same page now? If so, is it advisable/possible to make
> format_data_short respect the formatter.limits setting so Xavier can
> customize it to his heart's content.
Possible, but I think there is a much better solution along the lines I 
suggested earlier. I have it partly implemented. To really do it right 
will require a little bit of work on all the interactive backends; it 
might be very little and very easy. It prompted my question starting 
another thread as to whether we can drop support for GTK < 2.4 so as to 
simplify that backend.
Eric
> 
> JDH
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

John Hunter wrote:
> On Sat, May 30, 2009 at 11:52 AM, Eric Firing <ef...@ha...> wrote:
>
> 
>> No, that applies to the axis ticks but not to the readout, and I think it is
>> the latter that Xavier is concerned with--at least that is what I have been
>> talking about, and want to improve.
>> 
>
> Just to clarify -- by "readout" do you mean the toolbar strings?
>
> At first I was assuming that since the toolbar formatting picks up the
> tick Formatter to format the strings, and ScalarFormatter uses
> rcParams['axes.formatter.limits'] to determine when to fall over to
> scientific notation, that this setting would be picked up by the
> toolbar. The reason it does not is because ScalarFormatter overrides
> Formatter.format_data_short, which is what the toolbar uses via
> Axes.format_xdata/format_ydata, and ScalarFormatter.format_data_short
> does not use the formatter.limits setting. Are we at least on the
> same page now? If so, is it advisable/possible to make
> format_data_short respect the formatter.limits setting so Xavier can
> customize it to his heart's content.
>
> JDH
> 
...and this way my brain and my heart would be fully satisfied :)
Please perform this change ;)
Xavier

Hi,
Given that the values of ordinates are changing monotonically, I found that
in some cases, stineman interpolation is monotonic even when the slopes are
not monotonic. And in other cases, it overshoots. Like in the following one:
x = (0, 10, 70, 100)
y = (0, 535, 595, 1000)
xx = arange(0,100,1)
yy = stineman_interp(xx,x,y,yp=None)
plot(x,y,'x')
plot(xx,yy)
Are there some factors that can make the interpolation monotonic, when the
slopes are not monotonic? or does it depend on case by case basis?

On Sat, May 30, 2009 at 11:52 AM, Eric Firing <ef...@ha...> wrote:
> No, that applies to the axis ticks but not to the readout, and I think it is
> the latter that Xavier is concerned with--at least that is what I have been
> talking about, and want to improve.
Just to clarify -- by "readout" do you mean the toolbar strings?
At first I was assuming that since the toolbar formatting picks up the
tick Formatter to format the strings, and ScalarFormatter uses
rcParams['axes.formatter.limits'] to determine when to fall over to
scientific notation, that this setting would be picked up by the
toolbar. The reason it does not is because ScalarFormatter overrides
Formatter.format_data_short, which is what the toolbar uses via
Axes.format_xdata/format_ydata, and ScalarFormatter.format_data_short
does not use the formatter.limits setting. Are we at least on the
same page now? If so, is it advisable/possible to make
format_data_short respect the formatter.limits setting so Xavier can
customize it to his heart's content.
JDH

John Hunter wrote:
> On Sat, May 30, 2009 at 2:49 AM, Xavier Gnata <xav...@gm...> wrote:
> 
>> ok. My bad! Sorry.
>> I have changed the default to %1.4g so that is matches my usecases *but* I
>> agree that correct way to improve it in not that trivial...
> 
> 
> You can control the point at which mpl falls over to scientific
> notation. From the matplotlibrc file (see
> http://matplotlib.sourceforge.net/users/customizing.html)
> 
> axes.formatter.limits : -7, 7 # use scientific notation if log10
> # of the axis range is smaller than the
> # first or larger than the second
> 
> I'm actually surprised you are seeing problems with images of
> 1000x1000 -- it makes me suspect you have an older matplotlib version
> or an older matplotlibrc laying around because at -7,7, which is the
> current default, you should not see exponential formatting until you
> get to much larger sizes.
> 
> JDH
John,
No, that applies to the axis ticks but not to the readout, and I think 
it is the latter that Xavier is concerned with--at least that is what I 
have been talking about, and want to improve.
Eric

On Sat, May 30, 2009 at 3:50 AM, Paul Anton Letnes
<pau...@gm...> wrote:
> Hello again,
>
>
> I can set the figure size and font size, that all works fine. However,
> the legend is prohibitively large: for a plot 3 inches wide (why
> doesn't matplotlib use centimeters or similar?), the legend takes up
> about one third of the plot. This does not look too good...
Please post a complete example. As for inches vs cm, that is my fault
-- I can't remember if it was for matlab compatibility, or due to my
provincial ways this side of the pond.
JDH

On Sat, May 30, 2009 at 2:49 AM, Xavier Gnata <xav...@gm...> wrote:
> ok. My bad! Sorry.
> I have changed the default to %1.4g so that is matches my usecases *but* I
> agree that correct way to improve it in not that trivial...
You can control the point at which mpl falls over to scientific
notation. From the matplotlibrc file (see
http://matplotlib.sourceforge.net/users/customizing.html)
axes.formatter.limits : -7, 7 # use scientific notation if log10
 # of the axis range is smaller than the
 # first or larger than the second
I'm actually surprised you are seeing problems with images of
1000x1000 -- it makes me suspect you have an older matplotlib version
or an older matplotlibrc laying around because at -7,7, which is the
current default, you should not see exponential formatting until you
get to much larger sizes.
JDH

Hello again,
I can set the figure size and font size, that all works fine. However, 
the legend is prohibitively large: for a plot 3 inches wide (why 
doesn't matplotlib use centimeters or similar?), the legend takes up 
about one third of the plot. This does not look too good...
cheers,
Paul
On 29. mai. 2009, at 17.38, Damon McDougall wrote:
> Hi Paul,
>
> You could set the figure size and font size in inches of your plot 
> in matplotlib to be the same as that of the physical size it will 
> appear on paper. That way, all your axes labels and plot text will 
> be the same size as the text in your latex document.
>
> Is this what you want?
> Regards,
> --Damon
>
> On 29 May 2009, at 16:25, Paul Anton Letnes wrote:
>
>> Howdy y'all!
>>
>> I'm trying to make a publication quality plot for a two-column latex
>> article. I'm using latex for text processing, so the plot quality
>> itself is impeccable. However, as I scale the plot size down, the
>> legend becomes extremely large compared to the plot itself. Has
>> anyone solved this problem in a good manner? I'm not willing to make
>> do without the legend.
>>
>> cheers,
>> Paul.
>>
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity 
>> professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, 
>> Processing, &
>> iPhoneDevCamp as they present alongside digital heavyweights like 
>> Barbarian
>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Eric Firing wrote:
> Xavier Gnata wrote:
>>
>>>
>>>>
>
>>> Right now, the default is very simple:
>>>
>>> def format_data_short(self,value):
>>> 'return a short formatted string representation of a number'
>>> return '%1.3g'%value
>>>
>>> It looks like changing it to something like "%-12g" would facilitate 
>>> considerable improvement in reducing the jumping around of the 
>>> numbers, as well as in providing much more precision. I think that 
>>> 12 is the max number of characters in g conversion. Or maybe it is 
>>> 13; I might not have tested negative numbers.
>>>
>>> The problem is that then it crowds out the other part of the 
>>> message, the pan/zoom status notification etc.
>>>
>>> Breaking the message into two lines almost works (so far only 
>>> checking with gtkagg), but the plot gets resized depending on 
>>> whether there is a status or not.
>>>
>>> I think that with some more fiddling around with that part of the 
>>> toolbar--probably including breaking the message up into separate 
>>> messages for status and readout, and maybe making the readout use 
>>> two lines and always be present--we could make the readout and 
>>> status display much nicer. I have never liked the way it jumps around.
>>>
>> I also agree.
>> However, I would like to be sure I understand one point correctly:
>> As long as x<1000, the default format *is* an integer (at least when 
>> imshow(M) is used).
>
> No. Try
>
> imshow(rand(4,4))
>
> There is nothing special about imshow that makes the cursor readout an 
> integer, nor should there be.
>
> Again, the present default is "%1.3g". I think we can and will do 
> better, but it is not necessarily trivial.
>
> Eric
>
ok. My bad! Sorry.
I have changed the default to %1.4g so that is matches my usecases *but* 
I agree that correct way to improve it in not that trivial...
Xavier

Xavier Gnata wrote:
> 
>>
>>>
>> Right now, the default is very simple:
>>
>> def format_data_short(self,value):
>> 'return a short formatted string representation of a number'
>> return '%1.3g'%value
>>
>> It looks like changing it to something like "%-12g" would facilitate 
>> considerable improvement in reducing the jumping around of the 
>> numbers, as well as in providing much more precision. I think that 12 
>> is the max number of characters in g conversion. Or maybe it is 13; I 
>> might not have tested negative numbers.
>>
>> The problem is that then it crowds out the other part of the message, 
>> the pan/zoom status notification etc.
>>
>> Breaking the message into two lines almost works (so far only checking 
>> with gtkagg), but the plot gets resized depending on whether there is 
>> a status or not.
>>
>> I think that with some more fiddling around with that part of the 
>> toolbar--probably including breaking the message up into separate 
>> messages for status and readout, and maybe making the readout use two 
>> lines and always be present--we could make the readout and status 
>> display much nicer. I have never liked the way it jumps around.
>>
> I also agree.
> However, I would like to be sure I understand one point correctly:
> As long as x<1000, the default format *is* an integer (at least when 
> imshow(M) is used).
No. Try
imshow(rand(4,4))
There is nothing special about imshow that makes the cursor readout an 
integer, nor should there be.
Again, the present default is "%1.3g". I think we can and will do 
better, but it is not necessarily trivial.
Eric