Eric Firing wrote:
> Xavier Gnata 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 scien
Xavier Gnata 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
>> 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://mat
John Hunter wrote:
> On Sat, May 30, 2009 at 6:46 PM, Eric Firing wrote:
>
>
>> 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 backend
On Sat, May 30, 2009 at 6:46 PM, Eric Firing wrote:
> 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 a
John Hunter wrote:
> On Sat, May 30, 2009 at 11:52 AM, Eric Firing 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 --
John Hunter wrote:
> On Sat, May 30, 2009 at 11:52 AM, Eric Firing 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
On Sat, May 30, 2009 at 11:52 AM, Eric Firing 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
John Hunter wrote:
> On Sat, May 30, 2009 at 2:49 AM, Xavier Gnata 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
On Sat, May 30, 2009 at 2:49 AM, Xavier Gnata 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 th
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 l
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
>
>
>>
>> However, everyone would be happy if the default format would be
>> consistent :
>>
>> As it is, *by default*, when <1000 it displays an int and after 1000
>> it displays 1.42e3.
>> Why? What do you think this scientific format is a good for?
>>
>> I understand some users would like to se
Xavier Gnata wrote:
>
> However, everyone would be happy if the default format would be consistent :
>
> As it is, *by default*, when <1000 it displays an int and after 1000 it
> displays 1.42e3.
> Why? What do you think this scientific format is a good for?
>
> I understand some users would l
John Hunter wrote:
> On Fri, May 29, 2009 at 10:50 AM, Xavier Gnata wrote:
>
>
>>> I had the same problem and fixed it by changing just two lines of code in
>>> the axes.py (line 1812 and 1814). Just change the formatter in
>>> 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you w
On Fri, May 29, 2009 at 10:50 AM, Xavier Gnata wrote:
>> I had the same problem and fixed it by changing just two lines of code in
>> the axes.py (line 1812 and 1814). Just change the formatter in
>> 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the
>> same for y).
You
Indeed, but it should really be fixed in the svn.
Xavier
> Hi Xavier,
>
> I had the same problem and fixed it by changing just two lines of code in the
> axes.py (line 1812 and 1814). Just change the formatter in
> 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the
> sam
17 matches
Mail list logo
