matplotlib: plotting with Python

This PR exists as an alternative to https://github.com/matplotlib/matplotlib/pull/2624

See https://github.com/OceanWolf/matplotlib/blob/backend-refactor/doc/devel/MEP/MEP27.rst for details.

Tl;dr: FigureManagerBase :arrow_right: FigureManager + WindowBase ShowBase :arrow_right: Gcf.show_all + MainLoopBase

The main refactor (+gtk3 as an example) goes here, and will have no effect on the individual backends, work for other backends will occur in separate branches as indicated.

• [ ] MacOSX
• [ ] GTK
  • [ ] GTKCairo
  • [ ] GTKAgg
• [ ] NbAgg
• [x] WebAgg https://github.com/OceanWolf/matplotlib/compare/backend-refactor...OceanWolf:backend-refactor-webagg (still W-I-P, but will deal with last items in its PR)
• [x] Wx https://github.com/OceanWolf/matplotlib/compare/backend-refactor...backend-refactor-wx
  • [x] WxAgg
• [x] Qt https://github.com/OceanWolf/matplotlib/compare/backend-refactor...OceanWolf:backend-refactor-qt
  • [x] Qt4Agg
  • [x] Qt5Agg
• [x] TkAgg https://github.com/OceanWolf/matplotlib/compare/backend-refactor...OceanWolf:backend-refactor-tkagg
  • [ ] Remove tools.SaveFigureBase
• [x] GTK3 in this branch
  • [x] GTK3Cairo
  • [x] GTK3Agg

To accomplish this, we shall do this in two passes:

1. The first pass we refactor out all generic backend code out of the gtk3 backend, replacing these with common methods, i.e. we refactor out Gcf to backend_bases.py.
2. The second pass we then refactor Gcf out from backend_bases.py.
3. Other backends in separate branches, see list above for progress and make changes to this PR for global changes (none since the 2nd backend).

Fix failing tests -- many of them were broken due to changes in the snapping algorithm that made the axes off by one pixel. Others were broken due to changes in text alignment. Also fixes a bug in the SVG backend's Gouraud shading.

This PR is the implementation of MEP22, https://github.com/matplotlib/matplotlib/wiki/Mep22#implementation

This it supersedes the https://github.com/matplotlib/matplotlib/pull/2759

Toolbar has been relegated as listener/emiter of events that get dispatched to the Tools by Navigation.

The toolbar is easily reconfigurable at running time. new tools can be created/added/removed without modificaion of the backend code.

Example examples/user_interfaces/navigation.py

Summary [Last edit 16/12/2016]:

This has now been split into different PRs: -Implementing _StringFuncParser (Merged) -Implementing FuncNorm

Summary [Last edit 25/10/2016]:

• There is a new class called FuncNorm that can take any function and use it for the normalization. LogNorm, or PowerNorm, could be reimplemented using this.
• There is a new class PiecewiseNorm inheriting from FuncNorm that allows specifying a list of non-divergent functions (lambda functions or special strings) to map different ranges of the data dynamic range, into different ranges of the colorbar range. It creates internally a np.piecewise function hiding all the complexity of making a piecewise function that maps non-linearly but continuously in different intervals to [0-1].
  • The user has to provide a list of functions, and a list of reference points for the data and the colorbar. For example:
    • Take all data up to -1, and map it linearly to the colorbar range 0-0.3
    • Take all data between -1 and 1, and map it quadratically to the colorbar range 0.3-0.5
    • Take all data after 1, and map it cubically to the colorbar range 0.5-1
    • Specified as: colors.PiecewiseNorm(flist=['linear', 'quadratic', 'cubic'], refpoints_cm=[0.3, 0.5], refpoints_data=[-1., 1.])
  • There are some predefined functions, so the user can specify 'linear', 'quadratic','sqrt',..., and this will be automatically parsed into actual functions. The advantage is that in that case the user does not have to provide the inverse functions because we know them.
  • If the user provides lambda functions instead of a predefined string, then the inverse function is necessary.
  • The only condition for the provided function is that it must be monotonic and not diverge in the [0-1] interval. The class will automatically normalise the provided function so f(0)=0 and f(1)=1.
  • Also, the ticks method is improved to guarantee that there is always one tick in the colorbar at all the interval changes, and that the rest of the ticks available are spread evenly through the colorbar according to the size of each interval, landing at "relatively round" numbers.
  • ```SymLogNorm` could be reimplemented using this.
• Due to the power of this class, then all subclasses can derive from this:
  • MirrorPiecewiseNorm: It is similar to PiecewiseNorm with two intervals, with the difference that both intervals are not treated equally from a translational point of view, but symetrically. In an scenario where the user would like to amplify features around 0, for both the positive and negative sides symmetrically, but strongly for the negative side, then he would have to do:
    • Set a positive range with f(x)=sqrt(x). Set a negative range with f(x)=-cubicroot(-x+1)+1, which is a bit awkward.
    • MirrorPiecewiseNorm automatically takes care the transformation of the function in the second range internally so the user only has to provide f(x)=sqrt(x) for the positive range, and f(x)=cubicroot(x) for the negative range
  • MirrorRootNorm inheriting from MirrorArbitraryNorm, it would let the user, achieve the same by just specifying colors.MirrorRootNorm(orderpos=2, orderneg=3) .
  • RootNorm inheriting from FuncNorm, to perform root normalization by simply specifying the order colors.RootNorm(order=3).

TO DO list:

• [x] Make everything inherit from FuncNorm
• [x] Implement it to use np.piecewise internally
• [x] Implement examples
• [x] Implement tests
• [x] Include fully documented docstrings with full description and examples

Some examples of usage and outputs:

This is an example of an array with a large dynamic range using a regular linear scale. It consist of several regions:

• (1<y<2) Linear transition between -1 and 0 in the left half, and between 0 and 2 in the right half.
• (0<y<1) Non linear wavy function: cos(x) * y**2
• (-0.5<y<0) Series of bumps sitting at zero, growing linearly between 0 and 2.
• (-1<y<0.5) Series of negative bumps (depressions) sitting at zero, growing deeper between 0 and -1.
• (-1.5<y<1) Series of small bumps of 0.05 amplitude sitting at -1, -0.8, -0.6, -0.4, -0.2 and 0 and of 0.1 amplitude sitting at 0.4, 0.8, 1.2, 1.6, 2.
• (-2<y<1.5) Series of negative small bumps of -0.05 amplitude sitting at -1, -0.8, -0.6, -0.4, -0.2 and 0 and of -0.1 amplitude sitting at 0.4, 0.8, 1.2, 1.6, 2. Example of log normalization using FuncNorm. I have set manually the minimum value to 0.01 to fix the dynamic range that will be plotted. Negative features are not shown.

norm = colors.FuncNorm(f=lambda x: np.log10(x),
                       finv=lambda x: 10.**(x), vmin=0.01)

or alternatively with:

norm = colors.FuncNorm(f='log',vmin=0.01)

Example of root normalization using FuncNorm. Of course with direct sqrt normalization, negative features cannot be shown.

norm = colors.FuncNorm(f='sqrt', vmin=0.0)

Performing a symmetric amplification of the features around 0

norm = colors.MirrorPiecewiseNorm(fpos='crt')

Amplifying positive and negative features standing on 0.6

norm = colors.MirrorPiecewiseNorm(fpos='crt', fneg='crt',
                                  center_cm=0.35,
                                  center_data=0.6)

Amplifying positive and negative features standing on both -0.4 and 1.2. The bumps in the bottom area (-2<y<-1) sitting at the values -0.4 (light blue) and 1.2 (orange) are amplified, both the positive and the negative bumps. We can observe that the ticks are not exactly equispaced, to have a tick at the interval changes, and at round numbers.

norm = colors.PiecewiseNorm(flist=['cubic', 'crt', 'cubic', 'crt'],
                            refpoints_cm=[0.25, 0.5, 0.75],
                            refpoints_data=[-0.4, 1, 1.2])

Amplifying only positive features standing on all -1, -0.2 and 1.2. The bumps in the bottom area (-2<y<-1) sitting at the values -1 (black), -0.6 (turquoise) and 1.2 (yellow) are amplified, but in this case only the positive bumps.

norm = colors.PiecewiseNorm(flist=['crt', 'crt', 'crt'],
                            refpoints_cm=[0.4, 0.7],
                            refpoints_data=[-0.2, 1.2])

Second attempt at what I am now calling property cycling in order to avoid confusion with style sheets.

It seems to work for line plots, but I know it isn't working for bar plots. I suspect the same is true for errorbar plots. I have some tests unpushed at this point. I want to figure out the failure with bar plots first.

PR Summary

Alternative approach to #15019 where a new where='between' kwarg option is implemented as a Line2D drawstyle, based on comments from @ImportanceOfBeingErnest. This in the end requires a bit of hackery as well, because it seems matplotlib was always expects len(x) == len(y) Notably I am not sure how to properly modify the recache() fcn.

If this is preferable, we can pursue this instead.

PR Checklist

• [x] Has Pytest style unit tests
• [x] Code is Flake 8 compliant
• [x] New features are documented, with examples if plot related
• [x] Documentation is sphinx and numpydoc compliant
• [x] Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
• [x] Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

Add easy switching between rcParams based on the implementation in mpltools.style. Basically, just call

from matplotlib import style
style.use('ggplot')

... to switch to a style sheet that sort of mimics ggplot's style.

Notes:

• In the current implementation, shipped style files are stored in matplotlib/style/stylelib and user files are stored in ~/.matplotlib/stylelib.
• ~~I chose *.mplrc as an extension for the style files, but I'm fine with changing that.~~ Style files in the style libraries have the extension ~~*.style~~ *.mplstyle.
• Ideally there would an rc parameter (or some other mechanism) to easily add search paths for style files
• ~~One thing I liked in the original implementation was the ability to chain style sheets, with each style sheet adding the parameters they set. The current implementation doesn't work like this because rc_params_from_file initializes the default rcParams and then updates the defaults from the file. Thus, updating using the result from rc_params_from_file will overwrite all values.~~

Bug summary

fig.tight_layout is broken in current matplotlib.

Code for reproduction

%pylab
plot([0,1])
tight_layout()

# happens same way in object mode
from matplotlib import pylab as plt
fig, ax = plt.subplots()
ax.plot([0,1])
fig.tight_layout()

Actual outcome

below another example from real code that may be instructive

Expected outcome

figure scaled to image size, background deleted.

Additional information

Happens always.

I do not recall this issue in version before 3.5

I have no clue why it is happening. The flaw seems to lay in mpl getting/setting wrong window size when using tight_layout. Maybe gtk unhappy with X11. When I use mpl.use('Qt5Cairo') then it just makes the window and fonts smaller. Obviously, tight_layout should not change physical window size on screen! Similar for Gtk4Cairo. Gtk4Agg has similar issues to Qt5Agg but does not retain noise in background, just shrinks figure. I could be related to DPI settings. It might get them from a different system call than when opening the window?

The only fix I can find is use other plot package, e.g., plotly.

Operating system

Linux 5.16.14-200.fc35.x86_64 #1 SMP PREEMPT Fri Mar 11 20:31:18 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Matplotlib Version

3.5.1

Matplotlib Backend

Qt5Agg

Python version

Python 3.10.2

Jupyter version

N/A

Installation

pip

PR Summary

This is my implementation of the geometry manager (See #1109).

This is heavily based on exploratory work by @Tillsten using the kiwi solver, and of course on tight_layout.

Latest what's new: https://5396-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/users/next_whats_new/constrained_layout.html

Latest tutorial: https://5398-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/tutorials/intermediate/constrainedlayout_guide.html#sphx-glr-tutorials-intermediate-constrainedlayout-guide-py

Intro

tight_layout() is great for what it does, but it doesn't handle some cases generally. i.e. if we have two GridSpecFromSubplotSpec instances, they need to be positioned manually using tight_layout(). Colorbars for individual axes work fine, but colorbars for more than one axis doesn't work. Etc.

This PR implements "constrained_layout" via plt.figure(constrained_layout=True) for automatic re-drawing. Currently, it works for subplots and colorbars, legends, and suptitles. Nested gridspecs are respected. Spacing is provided both as a pad around axes and as a space between subplots.

The following code gives this plot:

    fig = plt.figure(constrained_layout=True)
    gs = gridspec.GridSpec(1, 2, fig=fig)
    gsl = gridspec.GridSpecFromSubplotSpec(2, 2, gs[0])
    gsr = gridspec.GridSpecFromSubplotSpec(1, 2, gs[1])
    axsl = []
    for gs in gsl:
        ax = fig.add_subplot(gs)
        axsl += [ax]
        example_plot(ax, fontsize=12)
    ax.set_xlabel('x-label\nMultiLine')
    axsr = []
    for gs in gsr:
        ax = fig.add_subplot(gs)
        axsr += [ax]
        pcm = example_pcolor(ax, fontsize=12)

    fig.colorbar(pcm, ax = axsr, pad=0.01, 
             location='bottom', ticks=ticker.MaxNLocator(nbins=5))

A few things to note in the above:

• all the subplots in the left side set of plots (gsl) have the same margins. They are a bit big because the bottom-right plot has a two-line x-label.
• the x-ticklabels for the rhs plot overrun, because constrained_layout doesn't do any management at the axis level.

Installation:

In addition to the normal matplotlib installation, you will need to involve kiwisolver: pip install kiwisolver now works.

API dfferences (so far)

In order to get this to work, there are a couple of API changes:

1. gridspec.GridSpec now has a fig keyword. If this isn't supplied then constrained_layout won't work.
2. figure now has a constrained_layout keyword. Currently, I don't have it checking for tight_layout, so they could both run at the same time. These upper level user-facing decisions probaby require input.
3. Internal calling issue: We don't want axes that have user-called ax.set_position() to participate in constrained_layout, presumably because the user was purposefully putting the axis where they put it. So, that means internally, we set the layoutbox properties of this axis to None. However, ax.set_position gets called internally (i.e. by colorbar and aspect) and for those we presumably want to keep constrained_layout as a possibility. So I made a ax._set_position() for internal calls, which the public ax.set_position() uses. Internal calls to set_position should use _set_position if the axis is to continue to participate in constrained_layout.

I think most of these changes are backwards compatible, in that if you don't want to use constrained_layout you don't need to change any calls. Backwards compatibility introduces some awkwardness, but is probably worth it.

Implementation:

Implementation is via a new package layoutbox.py. Basically a nested array of layoutboxe objects are set up, attached to the figure, the gridspec(s), the subplotspecs. An axes has two layoutboxes: one that contains the tight bounding box of the axes, and the second that contains the "position" of the axes (i.e the rectangle that is passed to ax.set_position()).

A linear constraint solver is used to decide dimensions. The trick here is that we define margins between an axes bounding box and its position. These margins, and the outer dimesnion of the plot (0,0,1,1) are what constrains the problem externally. Internally, the problem is constrained by relationships between the layoutboxes.

Tests:

These are in lib/matplotlib/tests/test_constrainedlayout.py.

PR Checklist

• [x] Sort out padding in a non-figure unit
• [x] Add legend to constrained objects
• [x] Add kiwi to requirements: need a new release to make OK w/ 2.7. Current requirement works 3.6
• [x] Has Pytest style unit tests.
• [x] Code is PEP 8 compliant
• [x] New features are documented, with examples if plot related
• [x] Documentation is sphinx and numpydoc compliant
• [x] Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
• [x] Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way
• [x] Add suptitle to constrained objects
• [x] sharex and sharey?
• [x] Adjust spacing for colorbars; respect pad.
• [x] Implement respect for wspace and hspace variables. Actually pretty easy.
• [x] Check set_position axes
• [x] Spacing between gridspecs
• [x] gridspec width_ratios and height_ratios
• [x] twinx, twiny? #5474
• [x] Extend to putting labels outside tick labels and titles outside of all?

PR Summary

This is an attempt at implementing a nicer API for laying out complex axes schemes like patchwork for ggplot. This is following on from a conversation @anntzer and @story645 had a few weeks ago https://hackmd.io/4zWKhuLXQ16Y_oUfi9hnKA#Gridspec-Easy-API and was done on a red-eye flight home

The big win here is things like

x = [["A", "A", "B"], ["C", "D", "B"]]
fig = plt.figure()
axes = fig.build_grid(x)
axes['A'].plot(...)

do what you expect.

open questions:

• [x] Name (Hannah suggested something riffing to "collage" which I think is good if we can make it a verb)
• [x] does this go in Matplotib or does this go in a small library under the mpl org?
• [x] better tests of things going wrong
• [x] be sure that when re-assigning grid specs we clean up all the evidence of the old one (to be sure constrained layout works etc)
• [x] do we want the expansion logic to work ([['A'], ['B', 'C']] <-> [['A', 'A'][ ['B', 'C']])
• [x] keys in return dict when adjusting existing axes
• [ ] ~provide a way to have mixed subplot_kw to each of the created figures~ to do later

PR Checklist

• [x] Has Pytest style unit tests
• [x] Code is Flake 8 compliant
• [x] New features are documented, with examples if plot related
• [x] Documentation is sphinx and numpydoc compliant
• [x] Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
• [x] Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

This is an alternative implementation of a labeled data decorator (see https://github.com/matplotlib/matplotlib/pull/4787)

Todo

• [x] add a whatsnew entry in doc/users/whats_new
• [x] address comments from the code reviews
• [x] plot() document the problems with 'color spec or next x' ambiguity when the third argument in *args is in data.
• [x] regenerate pyplot so that the decorated methods gain a data kwarg (or better get all reduced to plt.func(*args, **args) as thats the signature of the decorator.
• [x] Get someone to review the decorated functions and the code
• [x] make unittests for all decorated functions
• [x] get the unittests to run (mule isn't found?)
• [x] Check all decorated functions if the implicit label_namer="y" is ok. In most cases it probably is not...
• [x] Check all decorated functions with *args, **kwargs if it would be better to supply argument names
• [x] check all decorated functions if a rename_names list is better (i.e. don't replace everything but only a few arguments)
• [x] special case plot(...)
• [x] update docs with some information about the changed behaviour if data=data is passed in?
• [x] change label_namer="y" to label_namer=None? None is probably much more used than 'y'...
• [x] how to handle variable length *args positional_parameter_names={(#args: ["names"]}?

If the user explicitly passes a levels array (the default is auto-determined), let's assume that they know what they are doing. Closes #23778.

(I could consider keeping the warning for now in the case where the user didn't pass levels but z is uniform throughout, as that's more likely to be a "data-exploration" case.)

PR Summary

PR Checklist

Documentation and Tests

• [ ] Has pytest style unit tests (and pytest passes)
• [ ] Documentation is sphinx and numpydoc compliant (the docs should build without error).
• [ ] New plotting related features are documented with examples.

Release Notes

• [ ] New features are marked with a .. versionadded:: directive in the docstring and documented in doc/users/next_whats_new/
• [ ] API changes are marked with a .. versionchanged:: directive in the docstring and documented in doc/api/next_api_changes/
• [ ] Release notes conform with instructions in next_whats_new/README.rst or next_api_changes/README.rst

Bug summary

In a fairly basic example using subfigures, a suptitle added to the parent figure is not visible:

Code for reproduction

f = plt.figure(figsize=(4, 3))
sf1, sf2 = f.subfigures(1, 2)
sf1.subplots()
sf2.subplots()
f.suptitle("It's a bird, it's a plane, it's a suptitle")

Actual outcome

Expected outcome

Visible suptitle.

Additional information

It looks like this is happening because the subfigures have a solid facecolor that obscure the suptitle:

f = plt.figure(figsize=(4, 3))
sf1, sf2 = f.subfigures(1, 2)
sf1.subplots()
sf2.subplots()
sf1.set_facecolor((.8, 0, 0, .3))
f.suptitle("It's a bird, it's a plane, it's a suptitle")

Setting the zorder of the suptitle to a large number has no apparent effect.

Matplotlib Version

3.6.2

Matplotlib Backend

module://matplotlib_inline.backend_inline

Problem

Is it possible to add one or more isoluminant colormap(s) to the colormaps already present in Matplotlib?

Of course, I could install colorcet and use its isoluminant colormaps, but Matplotlib has colormaps of many sorts, aimed at all the different types of usage, except isoluminant colormaps.

Thank you for everything you've done ፨ gb

Proposed solution

No response

Bug summary

When setting up a simple animation on a TkAgg canvas, everything works as expected, until the XKCD-style is applied.

Code for reproduction

import tkinter as tk                                                                
from datetime import date, datetime                                                 
from tkinter import ttk                                                             
                                                                                      
import matplotlib.animation as pltanim                                              
import matplotlib.pyplot as plt                                                     
from matplotlib.axes import Axes                                                    
from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg                     
                                                                                      
                                                                                      
class DayPlotFrame(ttk.Frame):                                                      
    """TK Frame with matplotlib animation for live display of day progress."""   
                                                                                      
    def __init__(self, master=None):                                                
        """Initialize a new DayPlot."""                                             
        super().__init__(master=master)                                             
                                                                                    
        plt.xkcd()  # <- comment out this line and everything starts working again                                                                
        fig = plt.Figure()                                                          
        self.axes: Axes = fig.add_subplot()                                         
                                                                                    
        canvas = FigureCanvasTkAgg(fig, master=self)                                
        canvas.get_tk_widget().pack(fill=tk.BOTH, expand=True)                      
        self.animation = pltanim.FuncAnimation(                                     
            fig,                                                                    
            func=self.__run_animation,                                              
            init_func=self.__init_animation,                                        
        )               
        self.pack()                                                    
                                                                                       
    def __init_animation(self):                                                     
        """Configure the plot."""                                                   
        today = date.today()                                                        
                                                                                    
        self.axes.clear()                                                           
        self.axes.set_xlim(                                                         
            datetime(today.year, today.month, today.day, 8, 45, 0),                 
            datetime(today.year, today.month, today.day, 15, 11, 00),               
        )                                                                           
                                                                                      
    def __run_animation(self, frame):                                               
        """Update the plot according to the time of day."""                         
        width = datetime.now().replace(hour=10, minute=frame % 60)                  
        self.axes.barh(y=[1], width=width, color="blue")

ROOT = tk.Tk()
APP = DayPlotFrame(master=ROOT)
APP.mainloop()

Actual outcome

coredump

Expected outcome

the animation, but in XKCD style

Additional information

the init_func works just fine, the crash happens at the barh statement

Operating system

Arch

Matplotlib Version

3.6.2

Matplotlib Backend

TkAgg

Python version

Python 3.9.2

Jupyter version

No response

Installation

pip

PR Summary

The doc build is painfully slow. This gives devs an easy way to populate exclude_patterns in conf.py with subdirectories they do not want while they are doing development, and to not do the gallery builds if those subdirectories are excluded.

Of course the resulting build is broken with dropped references etc, so the developer should put conf.py back to its pristine state, but this should be a handy tool.

Note to build just the user subdirectory using this takes 5s on my machine (if I exclude the prev_whats_new).

This could probably use documentation if this is what we want to do, but I can add that if folks think it's reasonable.

Closes https://github.com/matplotlib/matplotlib/issues/24906

However note that it's not quite as laser focused as what pandas does (which is build a single page). We could add that, however, this seems like a super simple start.

PR Checklist

Documentation and Tests

• [ ] Has pytest style unit tests (and pytest passes)
• [ ] Documentation is sphinx and numpydoc compliant (the docs should build without error).
• [ ] New plotting related features are documented with examples.

Release Notes

• [ ] New features are marked with a .. versionadded:: directive in the docstring and documented in doc/users/next_whats_new/
• [ ] API changes are marked with a .. versionchanged:: directive in the docstring and documented in doc/api/next_api_changes/
• [ ] Release notes conform with instructions in next_whats_new/README.rst or next_api_changes/README.rst

Looks like pandas’ approach is to loop through the docs and exclude everything except the one you ask for. This is in the conf.py and the make.py sets the relevant environment variable. So probably could be done with our existing make files - though a python make script might remove the need for separate Windows and Linux make files?

Originally posted by @rcomer in https://github.com/matplotlib/matplotlib/issues/24897#issuecomment-1374527515

Thanks @rcomer - something like that seems like it would be really helpful for us. I may play with it, but if anyone else w/ more sphinx experience wants to give it a shot, I think it'd be a pretty worthwhile project.