We are starting to use matplotlib to do some analysis of our data, but we are hampered by the unfortunate choice of significant digits in the GUI. I hacked the backends for 0.87.7 to display (many) more significant digits and I was wondering if anyone had any better suggestions (ie that I could implement directly into my code so others wouldn't need to continually hack their backends). Perhaps the GUI should follow the formatting of the axes? (Though this would again require a change to the backend....)
Thanks!
Matt
Could you be more specific? In what ways are you currently limited, and how
would you like matplotlib to behave?
Darren
···
On Tuesday 20 February 2007 7:40:18 pm Matthew Auger wrote:
We are starting to use matplotlib to do some analysis of our data, but we
are hampered by the unfortunate choice of significant digits in the GUI.
I hacked the backends for 0.87.7 to display (many) more significant
digits and I was wondering if anyone had any better suggestions (ie that I
could implement directly into my code so others wouldn't need to
continually hack their backends). Perhaps the GUI should follow the
formatting of the axes? (Though this would again require a change to the
backend....)
The GUI plots the x/y position of the cursor in data coordinates using
scientific notation including only three significant digits (ie x=7.24e+03, y=20.2). The scientific notation is annoying but the lack of significant digits (ie 7.2457e+03) makes it impossible to fully use the GUI for interactive analyses. It would be nice if the cursor position denoted by the gui used the same coordinate formatting that the current axes use. Thus, if my axes are set to use something like 7.2f formatting for values less than 1e5, the cursor coordinate would be displayed in the same way (and instead of x=7.24e+03,y=20.1 the gui would read x=7245.70,y=20.1 when the cursor is at that coordinate position).
I hope this clears things up!
Matt
···
On Tue, 20 Feb 2007, Darren Dale wrote:
On Tuesday 20 February 2007 7:40:18 pm Matthew Auger wrote:
We are starting to use matplotlib to do some analysis of our data, but we
are hampered by the unfortunate choice of significant digits in the GUI.
I hacked the backends for 0.87.7 to display (many) more significant
digits and I was wondering if anyone had any better suggestions (ie that I
could implement directly into my code so others wouldn't need to
continually hack their backends). Perhaps the GUI should follow the
formatting of the axes? (Though this would again require a change to the
backend....)
Could you be more specific? In what ways are you currently limited, and how
would you like matplotlib to behave?
Darren
Matthew Auger wrote:
The GUI plots the x/y position of the cursor in data coordinates using
scientific notation including only three significant digits (ie x=7.24e+03, y=20.2). The scientific notation is annoying but the lack of significant digits (ie 7.2457e+03) makes it impossible to fully use the GUI for interactive analyses. It would be nice if the cursor position denoted by the gui used the same coordinate formatting that the current axes use. Thus, if my axes are set to use something like 7.2f formatting for values less than 1e5, the cursor coordinate would be displayed in the same way (and instead of x=7.24e+03,y=20.1 the gui would read x=7245.70,y=20.1 when the cursor is at that coordinate position).
I hope this clears things up!
Matt
Yes, it does. It looks to me like everything should be controllable without any hacking. Here is the Axes method that is getting called for the x-coordinate, for example: (pardon the mailer-mangling of lines)
def format_xdata(self, x):
"""
Return x string formatted. This function will use the attribute
self.fmt_xdata if it is callable, else will fall back on the xaxis
major formatter
"""
try: return self.fmt_xdata(x)
except TypeError:
func = self.xaxis.get_major_formatter().format_data_short
val = func(x)
return val
The reason that the axis formatting is not being followed is because
func = ...format_data_short
instead of format_data (or just the formatter instance itself).
We could change this, but I suspect there is a good reason for choosing "short" as the default--this is at least open to discussion and experimentation. In the meantime, if your axes object is ax, you should be able to do:
ax.fmt_xdata = ax.xaxis.get_major_formatter()
and similarly for the fmt_ydata to make the formatting the same as the axis formatting. Alternatively you could instantiate whatever Formatter class you like and set ax.fmt_xdata to that instance.
I haven't tested any of this...
Eric
···
On Tue, 20 Feb 2007, Darren Dale wrote:
On Tuesday 20 February 2007 7:40:18 pm Matthew Auger wrote:
We are starting to use matplotlib to do some analysis of our data, but we
are hampered by the unfortunate choice of significant digits in the GUI.
I hacked the backends for 0.87.7 to display (many) more significant
digits and I was wondering if anyone had any better suggestions (ie that I
could implement directly into my code so others wouldn't need to
continually hack their backends). Perhaps the GUI should follow the
formatting of the axes? (Though this would again require a change to the
backend....)
Could you be more specific? In what ways are you currently limited, and how
would you like matplotlib to behave?
Darren
Ah...right. That works well enough (I believe that I originally had editted backend_bases to circumvent the format_coord call--clearly not the best solution)! I don't know of a good reason to *not* use the axis formatting, but perhaps an rcparam could control this?
Thanks for the help Eric!
Matthew Auger wrote:
Ah...right. That works well enough (I believe that I originally had editted backend_bases to circumvent the format_coord call--clearly not the best solution)! I don't know of a good reason to *not* use the axis formatting, but perhaps an rcparam could control this?
I don't know what the historical reason for the present default is, but one candidate is speed: the coordinate numbers get reformatted and printed at a great rate as the cursor moves across a plot, so one might not want to have the formatting done by a big chunk of python code. format_data_short will typically be faster than format_data.
An rcParam certainly could be added, given sufficient demand.
Now, I'm wondering why the number of digits is actually important to you--are you writing those numbers down? If so, would you rather capture the numbers to a file upon clicking? examples/zoom_window.py shows how to grab the coordinates at which a button was clicked. There may be better examples, but this is the first one I found.
Eric
Here is the reason format_data_short was added: the x,y coordinates of the
cursor used to be printed to 10 digits, something I added when I was working
out the offset ticklabels for the x and y axis. These coordinates, when
rendered into the toolbar, were causing the figure window to resize to make
room for the numbers in the toolbar. format_data is also used to format the
ticklabels, so John suggested the new method. At the time, we needed a quick
work around. Maybe it's time to give it another look, and see if there is a
better long-term solution.
Darren
···
On Wednesday 21 February 2007 2:45:25 am Eric Firing wrote:
Matthew Auger wrote:
> Ah...right. That works well enough (I believe that I originally had
> editted backend_bases to circumvent the format_coord call--clearly not
> the best solution)! I don't know of a good reason to *not* use the axis
> formatting, but perhaps an rcparam could control this?
I don't know what the historical reason for the present default is, but
one candidate is speed: the coordinate numbers get reformatted and
printed at a great rate as the cursor moves across a plot, so one might
not want to have the formatting done by a big chunk of python code.
format_data_short will typically be faster than format_data.
Hi,
I would like to add another annoying aspect of the "digits in the GUI":
When a log axis is used the displayed numbers looks like 10^-8.23
which is definitely not human readable.
Do somebody know a quick fix to obtain something like 5.89e-9 or 5.89x10^-9 ?
Thanks,
David