>
>>
>> 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 see floats by default.
>> Some other users would like to see integers by default.
>
> It is not just a matter of integer versus float; the formatting
> algorithm must accomodate both.
>
I agree.
>>
>> I'm fine with integers or floats by default (I don't cadre) but I
>> don't get the logic of the scientific format.
>> I only would like to see all the digits of the integer parts.
>> I would be fine if I would get 1.422e3 instead of 1.42e3 (we could
>> for instance assume that images larger than (100 000, 100 000) are
>> really a corner case ;)).
>>
>> Why should be the *default* logic so strange?
>> Ok, it is easy to change but the default should at least make sense.
>> As it is, I don't think it does...but there could be a good rational
>> I'm missing.
>
>
> 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).
Fine for me. Why do we need to move to another *default* format for
numbers larger than 1000?
Anyhow, I think that we should at least always display all the digits of
the integer part of the coordinates.
BTW, ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d')) is
fine but it prevents you to do a simple imshow(M) to look at your data.
You have to create ax. Easy...yes...but not as simple/nice as the
one-liner imhow(M)
Xavier
> Eric
>
>>
>> pylab is so easy and fun to use because the default settings are
>> always the best one.
>> IMHO, there is one exception :(
>>
>> Xavier
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> 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
>> Matplotlib-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
------------------------------------------------------------------------------
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
