Skip to content

Commit

Permalink
Fix various typos (mwaskom#2617)
Browse files Browse the repository at this point in the history
Found via `codespell -q 3 -L ans,hist,whis`
  • Loading branch information
luzpaz committed Jul 15, 2021
1 parent 445a54a commit ad0240a
Show file tree
Hide file tree
Showing 24 changed files with 49 additions and 49 deletions.
2 changes: 1 addition & 1 deletion doc/Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .

help:
@echo "Please use \`make <target>' where <target> is one of"
@echo " clean to remove genrated output"
@echo " clean to remove generated output"
@echo " html to make standalone HTML files"
@echo " notebooks to make the Jupyter notebook-based tutorials"
@echo " dirhtml to make HTML files named index.html in directories"
Expand Down
2 changes: 1 addition & 1 deletion doc/docstrings/histplot.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -179,7 +179,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
"To compare the distribution of subsets that differ substantially in size, use indepdendent density normalization:"
"To compare the distribution of subsets that differ substantially in size, use independent density normalization:"
]
},
{
Expand Down
2 changes: 1 addition & 1 deletion doc/docstrings/swarmplot.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -147,7 +147,7 @@
"cell_type": "raw",
"metadata": {},
"source": [
"The \"orientation\" of the plot (defined as the direction along which quantitative relationships are preserved) is usualy inferred automatically. But in ambiguous cases, such as when both axis variables are numeric, it can be specified:"
"The \"orientation\" of the plot (defined as the direction along which quantitative relationships are preserved) is usually inferred automatically. But in ambiguous cases, such as when both axis variables are numeric, it can be specified:"
]
},
{
Expand Down
2 changes: 1 addition & 1 deletion doc/introduction.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -431,7 +431,7 @@
"Relationship to matplotlib\n",
"--------------------------\n",
"\n",
"Seaborn's integration with matplotlib allows you to use it across the many environments that matplotlib supports, inlcuding exploratory analysis in notebooks, real-time interaction in GUI applications, and archival output in a number of raster and vector formats.\n",
"Seaborn's integration with matplotlib allows you to use it across the many environments that matplotlib supports, including exploratory analysis in notebooks, real-time interaction in GUI applications, and archival output in a number of raster and vector formats.\n",
"\n",
"While you can be productive using only seaborn functions, full customization of your graphics will require some knowledge of matplotlib's concepts and API. One aspect of the learning curve for new users of seaborn will be knowing when dropping down to the matplotlib layer is necessary to achieve a particular customization. On the other hand, users coming from matplotlib will find that much of their knowledge transfers.\n",
"\n",
Expand Down
2 changes: 1 addition & 1 deletion doc/releases/v0.5.0.txt
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ Plotting functions

- :func:`lmplot` and :func:`pairplot` get a new keyword argument, ``markers``. This can be a single kind of marker or a list of different markers for each level of the ``hue`` variable. Using different markers for different hues should let plots be more comprehensible when reproduced to black-and-white (i.e. when printed). See the `github pull request (#323) <https://github.com/mwaskom/seaborn/pull/323>`_ for examples.

- More generally, there is a new keyword argument in :class:`FacetGrid` and :class:`PairGrid`, ``hue_kws``. This similarly lets plot aesthetics vary across the levels of the hue variable, but more flexibily. ``hue_kws`` should be a dictionary that maps the name of keyword arguments to lists of values that are as long as the number of levels of the hue variable.
- More generally, there is a new keyword argument in :class:`FacetGrid` and :class:`PairGrid`, ``hue_kws``. This similarly lets plot aesthetics vary across the levels of the hue variable, but more flexibly. ``hue_kws`` should be a dictionary that maps the name of keyword arguments to lists of values that are as long as the number of levels of the hue variable.

- The argument ``subplot_kws`` has been added to ``FacetGrid``. This allows for faceted plots with custom projections, including `maps with Cartopy <https://nbviewer.ipython.org/gist/shoyer/16db9cd187886a3effd8>`_.

Expand Down
2 changes: 1 addition & 1 deletion doc/releases/v0.6.0.txt
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ In version 0.6, the "categorical" plots have been unified with a common API. Thi

The categorical functions now each accept the same formats of input data and can be invoked in the same way. They can plot using long- or wide-form data, and can be drawn vertically or horizontally. When long-form data is used, the orientation of the plots is inferred from the types of the input data. Additionally, all functions natively take a ``hue`` variable to add a second layer of categorization.

With the (in some cases new) API, these functions can all be drawn correctly by :class:`FacetGrid`. However, ``factorplot`` can also now create faceted verisons of any of these kinds of plots, so in most cases it will be unnecessary to use :class:`FacetGrid` directly. By default, ``factorplot`` draws a point plot, but this is controlled by the ``kind`` parameter.
With the (in some cases new) API, these functions can all be drawn correctly by :class:`FacetGrid`. However, ``factorplot`` can also now create faceted versions of any of these kinds of plots, so in most cases it will be unnecessary to use :class:`FacetGrid` directly. By default, ``factorplot`` draws a point plot, but this is controlled by the ``kind`` parameter.

Here are details on what has changed in the process of unifying these APIs:

Expand Down
2 changes: 1 addition & 1 deletion doc/releases/v0.8.0.txt
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ v0.8.0 (July 2017)

- Added ``"auto"`` as a (default) option for tick labels in :func:`heatmap` and :func:`clustermap`. This will try to estimate how many ticks can be labeled without the text objects overlapping, which should improve performance for larger matrices.

- Added the ``dodge`` parameter to :func:`boxplot`, :func:`violinplot`, and :func:`barplot` to allow use of ``hue`` without changing the position or width of the plot elements, as when the ``hue`` varible is not nested within the main categorical variable.
- Added the ``dodge`` parameter to :func:`boxplot`, :func:`violinplot`, and :func:`barplot` to allow use of ``hue`` without changing the position or width of the plot elements, as when the ``hue`` variable is not nested within the main categorical variable.

- Correspondingly, the ``split`` parameter for :func:`stripplot` and :func:`swarmplot` has been renamed to ``dodge`` for consistency with the other categorical functions (and for differentiation from the meaning of ``split`` in :func:`violinplot`).

Expand Down
2 changes: 1 addition & 1 deletion doc/sphinxext/gallery_generator.py
Original file line number Diff line number Diff line change
Expand Up @@ -109,7 +109,7 @@ def execfile(filename, globals=None, locals=None):
}}
.caption {{
position: absolue;
position: absolute;
width: 180px;
top: 170px;
text-align: center !important;
Expand Down
6 changes: 3 additions & 3 deletions doc/tutorial/color_palettes.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -298,9 +298,9 @@
"cell_type": "raw",
"metadata": {},
"source": [
"With the hue-based palette, it's quite difficult to ascertain the shape of the bivariate distribution. In contrast, the luminance palette makes it much more clear that there are two prominant peaks.\n",
"With the hue-based palette, it's quite difficult to ascertain the shape of the bivariate distribution. In contrast, the luminance palette makes it much more clear that there are two prominent peaks.\n",
"\n",
"Varying luminance helps you see structure in data, and changes in luminance are more intuitively processed as changes in importance. But the plot on the right does not use a grayscale colormap. Its colorfulness makes it more interesting, and the subtle hue variation increases the perceptual distance between two values. As a result, small differencess slightly easier to resolve.\n",
"Varying luminance helps you see structure in data, and changes in luminance are more intuitively processed as changes in importance. But the plot on the right does not use a grayscale colormap. Its colorfulness makes it more interesting, and the subtle hue variation increases the perceptual distance between two values. As a result, small differences slightly easier to resolve.\n",
"\n",
"These examples show that color palette choices are about more than aesthetics: the colors you choose can reveal patterns in your data if used effectively or hide them if used poorly. There is not one optimal palette, but there are palettes that are better or worse for particular datasets and visualization approaches.\n",
"\n",
Expand Down Expand Up @@ -626,7 +626,7 @@
"cell_type": "raw",
"metadata": {},
"source": [
"Interally, seaborn uses the discrete version for categorical data and the continuous version when in numeric mapping mode. Discrete sequential colormaps can be well-suited for visualizing categorical data with an intrinsic ordering, especially if there is some hue variation."
"Internally, seaborn uses the discrete version for categorical data and the continuous version when in numeric mapping mode. Discrete sequential colormaps can be well-suited for visualizing categorical data with an intrinsic ordering, especially if there is some hue variation."
]
},
{
Expand Down
6 changes: 3 additions & 3 deletions doc/tutorial/data_structure.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -97,7 +97,7 @@
"cell_type": "raw",
"metadata": {},
"source": [
"The advantage of long-form data is that it lends itself well to this explicit specification of the plot. It can accomodate datasets of arbitrary complexity, so long as the variables and observations can be clearly defined. But this format takes some getting used to, because it is often not the model of the data that one has in their head.\n",
"The advantage of long-form data is that it lends itself well to this explicit specification of the plot. It can accommodate datasets of arbitrary complexity, so long as the variables and observations can be clearly defined. But this format takes some getting used to, because it is often not the model of the data that one has in their head.\n",
"\n",
"Wide-form data\n",
"~~~~~~~~~~~~~~\n",
Expand Down Expand Up @@ -145,7 +145,7 @@
"cell_type": "raw",
"metadata": {},
"source": [
"This plot looks very similar to the one before. Seaborn has assigned the index of the dataframe to ``x``, the values of the dataframe to ``y``, and it has drawn a separate line for each month. There is a notable difference between the two plots, however. When the dataset went through the \"pivot\" operation that converted it from long-form to wide-form, the information about what the values mean was lost. As a result, there is no y axis label. (The lines also have dashes here, becuase :func:`relplot` has mapped the column variable to both the ``hue`` and ``style`` semantic so that the plot is more accessible. We didn't do that in the long-form case, but we could have by setting ``style=\"month\"``).\n",
"This plot looks very similar to the one before. Seaborn has assigned the index of the dataframe to ``x``, the values of the dataframe to ``y``, and it has drawn a separate line for each month. There is a notable difference between the two plots, however. When the dataset went through the \"pivot\" operation that converted it from long-form to wide-form, the information about what the values mean was lost. As a result, there is no y axis label. (The lines also have dashes here, because :func:`relplot` has mapped the column variable to both the ``hue`` and ``style`` semantic so that the plot is more accessible. We didn't do that in the long-form case, but we could have by setting ``style=\"month\"``).\n",
"\n",
"Thus far, we did much less typing while using wide-form data and made nearly the same plot. This seems easier! But a big advantage of long-form data is that, once you have the data in the correct format, you no longer need to think about its *structure*. You can design your plots by thinking only about the variables contained within it. For example, to draw lines that represent the monthly time series for each year, simply reassign the variables:"
]
Expand Down Expand Up @@ -181,7 +181,7 @@
"source": [
"(This example also illustrates another wrinkle, which is that seaborn currently considers the column variable in a wide-form dataset to be categorical regardless of its datatype, whereas, because the long-form variable is numeric, it is assigned a quantitative color palette and legend. This may change in the future).\n",
"\n",
"The absence of explicit variable assignments also means that each plot type needs to define a fixed mapping between the dimensions of the wide-form data and the roles in the plot. Because ths natural mapping may vary across plot types, the results are less predictable when using wide-form data. For example, the :ref:`categorical <categorical_api>` plots assign the *column* dimension of the table to ``x`` and then aggregate across the rows (ignoring the index):"
"The absence of explicit variable assignments also means that each plot type needs to define a fixed mapping between the dimensions of the wide-form data and the roles in the plot. Because this natural mapping may vary across plot types, the results are less predictable when using wide-form data. For example, the :ref:`categorical <categorical_api>` plots assign the *column* dimension of the table to ``x`` and then aggregate across the rows (ignoring the index):"
]
},
{
Expand Down
8 changes: 4 additions & 4 deletions doc/tutorial/distributions.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@
"\n",
"The :ref:`distributions module <distribution_api>` contains several functions designed to answer questions such as these. The axes-level functions are :func:`histplot`, :func:`kdeplot`, :func:`ecdfplot`, and :func:`rugplot`. They are grouped together within the figure-level :func:`displot`, :func:`jointplot`, and :func:`pairplot` functions.\n",
"\n",
"There are several different approaches to visualizing a distribution, and each has its relative advantages and drawbacks. It is important to understand theses factors so that you can choose the best approach for your particular aim."
"There are several different approaches to visualizing a distribution, and each has its relative advantages and drawbacks. It is important to understand these factors so that you can choose the best approach for your particular aim."
]
},
{
Expand Down Expand Up @@ -415,7 +415,7 @@
"Kernel density estimation pitfalls\n",
"^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n",
"\n",
"KDE plots have many advantages. Important features of the data are easy to discern (central tendency, bimodality, skew), and they afford easy comparisons between subsets. But there are also situations where KDE poorly represents the underlying data. This is because the logic of KDE assumes that the underlying distribution is smooth and unbounded. One way this assumption can fail is when a varible reflects a quantity that is naturally bounded. If there are observations lying close to the bound (for example, small values of a variable that cannot be negative), the KDE curve may extend to unrealistic values:"
"KDE plots have many advantages. Important features of the data are easy to discern (central tendency, bimodality, skew), and they afford easy comparisons between subsets. But there are also situations where KDE poorly represents the underlying data. This is because the logic of KDE assumes that the underlying distribution is smooth and unbounded. One way this assumption can fail is when a variable reflects a quantity that is naturally bounded. If there are observations lying close to the bound (for example, small values of a variable that cannot be negative), the KDE curve may extend to unrealistic values:"
]
},
{
Expand All @@ -431,7 +431,7 @@
"cell_type": "raw",
"metadata": {},
"source": [
"This can be partially avoided with the ``cut`` parameter, which specifies how far the curve should extend beyond the extreme datapoints. But this influences only where the curve is drawn; the density estimate will still smooth over the range where no data can exist, causing it to be artifically low at the extremes of the distribution:"
"This can be partially avoided with the ``cut`` parameter, which specifies how far the curve should extend beyond the extreme datapoints. But this influences only where the curve is drawn; the density estimate will still smooth over the range where no data can exist, causing it to be artificially low at the extremes of the distribution:"
]
},
{
Expand Down Expand Up @@ -559,7 +559,7 @@
"cell_type": "raw",
"metadata": {},
"source": [
"A bivariate histogram bins the data within rectangles that tile the plot and then shows the count of observations within each rectangle with the fill color (analagous to a :func:`heatmap`). Similarly, a bivariate KDE plot smoothes the (x, y) observations with a 2D Gaussian. The default representation then shows the *contours* of the 2D density:"
"A bivariate histogram bins the data within rectangles that tile the plot and then shows the count of observations within each rectangle with the fill color (analogous to a :func:`heatmap`). Similarly, a bivariate KDE plot smoothes the (x, y) observations with a 2D Gaussian. The default representation then shows the *contours* of the 2D density:"
]
},
{
Expand Down
6 changes: 3 additions & 3 deletions doc/tutorial/function_overview.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -198,7 +198,7 @@
"cell_type": "raw",
"metadata": {},
"source": [
"You'll notice that the figure-level plots look mostly like their axes-level counterparts, but there are a few differences. Notably, the legend is placed ouside the plot. They also have a slightly different shape (more on that shortly).\n",
"You'll notice that the figure-level plots look mostly like their axes-level counterparts, but there are a few differences. Notably, the legend is placed outside the plot. They also have a slightly different shape (more on that shortly).\n",
"\n",
"The most useful feature offered by the figure-level functions is that they can easily create figures with multiple subplots. For example, instead of stacking the three distributions for each species of penguins in the same axes, we can \"facet\" them by plotting each distribution across the columns of the figure:"
]
Expand Down Expand Up @@ -437,7 +437,7 @@
"cell_type": "raw",
"metadata": {},
"source": [
"On balance, the figure-level functions add some additional complexity that can make things more confusing for beginners, but their distinct features give them additional power. The tutorial documentaion mostly uses the figure-level functions, because they produce slightly cleaner plots, and we generally recommend their use for most applications. The one situation where they are not a good choice is when you need to make a complex, standalone figure that composes multiple different plot kinds. At this point, it's recommended to set up the figure using matplotlib directly and to fill in the individual components using axes-level functions."
"On balance, the figure-level functions add some additional complexity that can make things more confusing for beginners, but their distinct features give them additional power. The tutorial documentation mostly uses the figure-level functions, because they produce slightly cleaner plots, and we generally recommend their use for most applications. The one situation where they are not a good choice is when you need to make a complex, standalone figure that composes multiple different plot kinds. At this point, it's recommended to set up the figure using matplotlib directly and to fill in the individual components using axes-level functions."
]
},
{
Expand All @@ -447,7 +447,7 @@
"Combining multiple views on the data\n",
"------------------------------------\n",
"\n",
"Two important plotting functions in seaborn don't fit cleanly into the classification scheme discussed above. These functions, :func:`jointplot` and :func:`pairplot`, employ multiple kinds of plots from different modules to represent mulitple aspects of a dataset in a single figure. Both plots are figure-level functions and create figures with multiple subplots by default. But they use different objects to manage the figure: :class:`JointGrid` and :class:`PairGrid`, respectively.\n",
"Two important plotting functions in seaborn don't fit cleanly into the classification scheme discussed above. These functions, :func:`jointplot` and :func:`pairplot`, employ multiple kinds of plots from different modules to represent multiple aspects of a dataset in a single figure. Both plots are figure-level functions and create figures with multiple subplots by default. But they use different objects to manage the figure: :class:`JointGrid` and :class:`PairGrid`, respectively.\n",
"\n",
":func:`jointplot` plots the relationship or joint distribution of two variables while adding marginal axes that show the univariate distribution of each one separately:"
]
Expand Down
Loading

0 comments on commit ad0240a

Please sign in to comment.