pgfplots-features — Announcements of new releases

Re: [Pgfplots-features] Version 1.13 has been released!

[Nick P. <nic...@gm...>]

Great job Christian, your efforts are priceless!

Do you have a citation for pgfplots such that your efforts, at least, get
some broader recognition?

2016-01-07 18:25 GMT+01:00 Christian Feuersaenger <
cfe...@go...>:

> Hi all,
>
> I am proud to pronounce the release of pgfplots 1.13!
>
> It is now available via CTAN http://www.ctan.org/pkg/pgfplots and
> http://pgfplots.sourceforge.net/ and will become part of the associated
> TeX package managers (MikTeX, TexLive) within the next days.
>
> A list of changes is attached to this email.
>
> Kind regards
>
> Christian
>
> Changes:
>
> 1.13:
> - fixed bug: incompatiblity between fillbetween and babel
> - fixed bug: 'compat=1.9' (or newer) failed to work with log bar plots
> - fixed bug: javascript incompatibility between Acrobat reader DC and
> clickable lib
> - fixed bug in polar axes: repaired default axis label positions
> - fixed bug in polar axes: repaired support for sloped descriptions
> - fixed bug: 'axis line style={draw=none}' had no effect unless one had
> 2d boxed axes
> - fixed bug: point meta expressions with '=' inside of them which caused
> compilation errors
> - fixed bug: compat=1.12 combined with interrupted plots (by empty line)
> failed to work
> - fixed bug: compat=1.12 combined with lualatex evaluated relational
> operations (<, ==) with the wrong operator precedence
> - fixed bug: fixed floor and ceil functions
> - fixed bug: 'set layers' broke alignment features with different
> manifestations
>         ('set layers' together with fill between in group plots,
> together with at={} key, together with anchor)
> - fixed bug: fill between and group plots: fill-between graphics was
> missing (list of layers was lost)
> - fixed bug: \addplot graphics {\newFile{P.pdf}}; failed to properly
> expand the file name
> - fixed bug: fill between + error bars resulted in compilation error
> - fixed bug: stacked plots occasionally used a wrong coordinate mapping
> - fixed bug: provided suitable default legends for xbar and xbar stacked
> - fixed bug: 'dateplot' now computes missing 'date ZERO' automatically.
> 'date ZERO' is managed automatically.
> - new feature: Added support for search paths to find data files
> (table/search path)
> - new feature: 'xtick distance' allows to define tick positions by distance
> - new feature: "axis line shift=10pt" shifts axis lines together with
> all their descriptions
> - new feature: 'matrix plot' (alias 'imagesc') which allows cell-based
> matrix plots
> - new feature: unbounded point meta in mesh plots will be treated like
> an invisible patch
> - new feature: added high quality colormap 'viridis' (use 'colormap
> name=viridis' to activate it)
> - new feature: ensured that 'shader=flat' returns the same result for
> every choice of 'z buffer' (starting with compat=1.13)
> - new feature: utility function \pgfplotsforeachungrouped: added support
> for \breakforeach
> - new feature: compat=1.13: activates sampling routine with less
> rounding errors
> - new feature: cycle multiindex list (uses the 'ith' element for every
> provided sub-list)
> - new feature: 'color of colormap=<value>' or 'color of colormap=<value>
> of <colormap name>'
> - new feature: 'index of colormap=<value>' or 'index of colormap=<value>
> of <colormap name>'
> - new feature: cycle list={[of colormap]}
> - new feature: cycle list={[colors of colormap={0,100,500,100} of viridis]}
> - new feature: cycle list={[indices of colormap={0,1,2,3} of hot]}
> - new feature: added support for 'stack negative=on previous|separate'
> which allows separate plots for '+' and '-' (useful for bar plots)
> - new feature: added support for 'colormap access=direct' combined with
> 'shader=flat mean' and 'shader=interp':
>      it previously used to interpolate indices instead of colors
> - new feature: \closedcycle now produces useful results for 3d line plots
> - new feature: added \usetikzlibrary{colorbrewer} and
> \usepgfplotslibrary{colorbrewer}
> - new feature: added 'colormap access=piecewise constant'
> - new feature: added rudimentary support for "Filled Contours" (based on
> 'colormap access=piecewise constant')
> - new feature: added methods to build colormaps based on other colormaps
> using
>     "color of colormap", "index of colormap", "colors of colormap",
> "samples of colormap", and "indices of colormap"
>
> 1.12.1: minor bugfix release
> - fixed bug: incompatibility of 1.12 with unicode-math
> - fixed bug: lua backend failed to work with table input and dependency
> on \coordindex
> - fixed bug: lua backend failed with 'forget plot'
>
> 1.12: scalability + performance
> - scalability: reduced TeX memory consumption for huge inline tables
> - scalability: lualatex allows bigger 3d graphics
> - scalability: lualatex now reduces compilation time for huge 3d graphics
>     (requires \pgfplotsset{compat=newest} at the time of this writing)
>         surf shader=faceted: time reduced to 61% of pdflatex
>          (\addplot3[surf,samples=70] {exp(-x^2-y^2 +x*y)})
>
>      surf shader=interp: time reduced to 25% of pdflatex
>           (\addplot3[surf,shader=interp,samples=70] {exp(-x^2-y^2 +x*y)})
>
>      surf shader=interp, parametric: time reduced to 36% of pdflatex
>          (\addplot3[surf,shader=interp,z buffer=sort,
> samples=50,domain=-1:0,y domain=0:2*pi] ({sqrt(1-x^2) * cos(deg(y))},
> {sqrt( 1-x^2 ) * sin(deg(y))}, x);)
>
>      surf shader=faceted, parametric: time reduced to 40% of pdflatex
>          (\addplot3[surf,z buffer=sort, samples=50,domain=-1:0,y
> domain=0:2*pi] ({sqrt(1-x^2) * cos(deg(y))}, {sqrt( 1-x^2 ) *
> sin(deg(y))}, x);)
>
> - scalability: lualated now reduces compilation time for boxplots.
>      10000 input points from table: time reduced to 23% of pdflatex
> - fixed bug: 3d axes where all axes used log scale produced compile failure
> - fixed bug: axis equal did not respect "disabledatascaling"
> - fixed bug: mesh legend was confused by color input=explicit
> - fixed bug: colorbar style did not reset zmin/zmax
> - fixed bug: memory allocation in FPU consumed too much memory
> - fixed bug: boxplots: removed compilation error due to spurious spaces
> in options list
> - fixed bug: boxplots: now uses standard quantile estimators: has all 9
> estimators of R and uses the same as in Excel as default (as of
> compat=1.12)
> - fixed bug: boxplots: sometimes failed to compute boxplot statistics
> for special inputs
> - fixed bug: boxplots: now, it sets 'mark=*' for outliers if there is no
> mark (compat=1.12)
> - fixed regression: compat=1.11 broke arcs inside of axis
> - new feature: ensured that arcs inside of axis make use of 'axis cs'
> and 'axis direction cs' automatically
> - new feature: ensured that (0:1) is evaluated with axis cs
> - fixed bug: precision of transformation cartesian to polar was too low
> (added atan2 to fpu)
> - fixed bug: z buffer caused 'mesh legend' to produce a compile error
> - new feature: added 'y filter/.expression={y==3 ? nan : y}' to simplify
> coordinate filters
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Pgfplots-features mailing list
> Pgf...@li...
> https://lists.sourceforge.net/lists/listinfo/pgfplots-features
>



-- 
Kind regards Nick

[Pgfplots-features] Version 1.13 has been released!

[Christian F. <cfe...@go...>]

Hi all,

I am proud to pronounce the release of pgfplots 1.13!

It is now available via CTAN http://www.ctan.org/pkg/pgfplots and 
http://pgfplots.sourceforge.net/ and will become part of the associated 
TeX package managers (MikTeX, TexLive) within the next days.

A list of changes is attached to this email.

Kind regards

Christian

Changes:

1.13:
- fixed bug: incompatiblity between fillbetween and babel
- fixed bug: 'compat=1.9' (or newer) failed to work with log bar plots
- fixed bug: javascript incompatibility between Acrobat reader DC and 
clickable lib
- fixed bug in polar axes: repaired default axis label positions
- fixed bug in polar axes: repaired support for sloped descriptions
- fixed bug: 'axis line style={draw=none}' had no effect unless one had 
2d boxed axes
- fixed bug: point meta expressions with '=' inside of them which caused 
compilation errors
- fixed bug: compat=1.12 combined with interrupted plots (by empty line) 
failed to work
- fixed bug: compat=1.12 combined with lualatex evaluated relational 
operations (<, ==) with the wrong operator precedence
- fixed bug: fixed floor and ceil functions
- fixed bug: 'set layers' broke alignment features with different 
manifestations
        ('set layers' together with fill between in group plots, 
together with at={} key, together with anchor)
- fixed bug: fill between and group plots: fill-between graphics was 
missing (list of layers was lost)
- fixed bug: \addplot graphics {\newFile{P.pdf}}; failed to properly 
expand the file name
- fixed bug: fill between + error bars resulted in compilation error
- fixed bug: stacked plots occasionally used a wrong coordinate mapping
- fixed bug: provided suitable default legends for xbar and xbar stacked
- fixed bug: 'dateplot' now computes missing 'date ZERO' automatically. 
'date ZERO' is managed automatically.
- new feature: Added support for search paths to find data files 
(table/search path)
- new feature: 'xtick distance' allows to define tick positions by distance
- new feature: "axis line shift=10pt" shifts axis lines together with 
all their descriptions
- new feature: 'matrix plot' (alias 'imagesc') which allows cell-based 
matrix plots
- new feature: unbounded point meta in mesh plots will be treated like 
an invisible patch
- new feature: added high quality colormap 'viridis' (use 'colormap 
name=viridis' to activate it)
- new feature: ensured that 'shader=flat' returns the same result for 
every choice of 'z buffer' (starting with compat=1.13)
- new feature: utility function \pgfplotsforeachungrouped: added support 
for \breakforeach
- new feature: compat=1.13: activates sampling routine with less 
rounding errors
- new feature: cycle multiindex list (uses the 'ith' element for every 
provided sub-list)
- new feature: 'color of colormap=<value>' or 'color of colormap=<value> 
of <colormap name>'
- new feature: 'index of colormap=<value>' or 'index of colormap=<value> 
of <colormap name>'
- new feature: cycle list={[of colormap]}
- new feature: cycle list={[colors of colormap={0,100,500,100} of viridis]}
- new feature: cycle list={[indices of colormap={0,1,2,3} of hot]}
- new feature: added support for 'stack negative=on previous|separate' 
which allows separate plots for '+' and '-' (useful for bar plots)
- new feature: added support for 'colormap access=direct' combined with 
'shader=flat mean' and 'shader=interp':
     it previously used to interpolate indices instead of colors
- new feature: \closedcycle now produces useful results for 3d line plots
- new feature: added \usetikzlibrary{colorbrewer} and 
\usepgfplotslibrary{colorbrewer}
- new feature: added 'colormap access=piecewise constant'
- new feature: added rudimentary support for "Filled Contours" (based on 
'colormap access=piecewise constant')
- new feature: added methods to build colormaps based on other colormaps 
using
    "color of colormap", "index of colormap", "colors of colormap", 
"samples of colormap", and "indices of colormap"

1.12.1: minor bugfix release
- fixed bug: incompatibility of 1.12 with unicode-math
- fixed bug: lua backend failed to work with table input and dependency 
on \coordindex
- fixed bug: lua backend failed with 'forget plot'

1.12: scalability + performance
- scalability: reduced TeX memory consumption for huge inline tables
- scalability: lualatex allows bigger 3d graphics
- scalability: lualatex now reduces compilation time for huge 3d graphics
    (requires \pgfplotsset{compat=newest} at the time of this writing)
        surf shader=faceted: time reduced to 61% of pdflatex
         (\addplot3[surf,samples=70] {exp(-x^2-y^2 +x*y)})

     surf shader=interp: time reduced to 25% of pdflatex
          (\addplot3[surf,shader=interp,samples=70] {exp(-x^2-y^2 +x*y)})

     surf shader=interp, parametric: time reduced to 36% of pdflatex
         (\addplot3[surf,shader=interp,z buffer=sort, 
samples=50,domain=-1:0,y domain=0:2*pi] ({sqrt(1-x^2) * cos(deg(y))}, 
{sqrt( 1-x^2 ) * sin(deg(y))}, x);)

     surf shader=faceted, parametric: time reduced to 40% of pdflatex
         (\addplot3[surf,z buffer=sort, samples=50,domain=-1:0,y 
domain=0:2*pi] ({sqrt(1-x^2) * cos(deg(y))}, {sqrt( 1-x^2 ) * 
sin(deg(y))}, x);)

- scalability: lualated now reduces compilation time for boxplots.
     10000 input points from table: time reduced to 23% of pdflatex
- fixed bug: 3d axes where all axes used log scale produced compile failure
- fixed bug: axis equal did not respect "disabledatascaling"
- fixed bug: mesh legend was confused by color input=explicit
- fixed bug: colorbar style did not reset zmin/zmax
- fixed bug: memory allocation in FPU consumed too much memory
- fixed bug: boxplots: removed compilation error due to spurious spaces 
in options list
- fixed bug: boxplots: now uses standard quantile estimators: has all 9 
estimators of R and uses the same as in Excel as default (as of compat=1.12)
- fixed bug: boxplots: sometimes failed to compute boxplot statistics 
for special inputs
- fixed bug: boxplots: now, it sets 'mark=*' for outliers if there is no 
mark (compat=1.12)
- fixed regression: compat=1.11 broke arcs inside of axis
- new feature: ensured that arcs inside of axis make use of 'axis cs' 
and 'axis direction cs' automatically
- new feature: ensured that (0:1) is evaluated with axis cs
- fixed bug: precision of transformation cartesian to polar was too low 
(added atan2 to fpu)
- fixed bug: z buffer caused 'mesh legend' to produce a compile error
- new feature: added 'y filter/.expression={y==3 ? nan : y}' to simplify 
coordinate filters

[Pgfplots-features] Bug with ConTeXt and pgfplot library fillbetween

[Aditya M. <ad...@um...>]

Hi,

The following example fails:

\usemodule[pgfplots]
\usepgfplotslibrary[fillbetween]

\starttext
\startformula
   \left. a \right|
\stopformula

\stoptext

with

tex error       > tex error on line 7 in file /private/tmp/test.tex: ! 
Missing \endgroup inserted

<inserted text>
\endgroup
<to be read again>
\Ucheckedstopdisplaymath
\stopdisplaymath ...math \Ucheckedstopdisplaymath
                                                   \par \ifvmode \ifcase 
\c_s...
\strc_formulas_stop_formula ...native \v!formula }
                                                   \dostoptagged 
\dostoptagge...
l.7 \stopformula

This is a weird bug. Only \left. \right| fails; \left| \right| works 
correctly. If I remove the fillbetween library, the error goes away.

Any hints as to what is happening will be appreciated.

Thanks,
Aditya

[Pgfplots-features] Axis ticks crammed on the right for negative values

[Markus H. <mar...@rw...>]

Hi,

When working on a diagram with several big negative values, the axis 
started to behave weird:
The ticks are all in one portion of the axis, and the rest of the axis 
has no ticks.
Consider the following code for values that exhibit this behaviour:

\documentclass{article}

\usepackage{tikz}
\usepackage{pgfplots}
\pgfplotsset{compat=1.10}

\begin{document}

\begin{tikzpicture}
\begin{axis}
\addplot coordinates { (-323573.5, -327215.79) (-323572.1, -327210.13) 
(-323572.1, -327206.85) };
\end{axis}
\end{tikzpicture}

\end{document}

I have written on tex/stackexchange about it (see for an image, too):
http://tex.stackexchange.com/questions/266637/weird-axis-labelling-for-large-negative-values

Best, Markus

Re: [Pgfplots-features] Excess whitespace with "set layers" and logarithmic y limits <1

[C. H. <hah...@al...>]

Hello Christian,

thank you for the workaround, works like a charm. 

Best regards,
Christoph

On Tue, 08 Sep 2015 19:43:07 +0200, Christian Feuersaenger 
<cfe...@go...> wrote:
Hi,
>
> thanks for the report. 
>
> You are right, this is a bug, and it is known to me (even though I 
> failed to find the root cause so far). 
>
> The problem is related to so-called "cell pictures". A workaround is 
> to write "cell picture=true" right after "set layers" -- but that 
> disables some of the effects of the layered graphics (namely layering 
> between different axes within the same tikzpicture). 
>
> I will look into it with new motivation given your email. 
>
> Kind regards
>
> Christian
>
>
> Am 07.09.2015 07:55, schrieb Christoph Hahn:
> > Hey guys,
> >
> > I recently ran into some pgfplots behavior I'd consider a bug. In the MWE
> >
> > \documentclass{article}
> >
> > \usepackage{pgfplots}
> > \pgfplotsset{compat=1.12}
> >
> > \begin{document}
> > \begin{tikzpicture}
> > \pgfplotsset{set layers}
> > \begin{axis}[name=n,
> > ymode=log,
> > ymin=1.5E-5,ymax=1.5E-3,
> > ]
> > \addplot coordinates {(1,2E-4) (2,2E-4)};
> > \end{axis}
> >
> > \node at (n.outer south west) {\emph{Picture edge is here}};
> > \end{tikzpicture}
> > \end{document}
> >
> > the vertical cropping seems to be off, with the excess space 
> depending on the y limits set. If I use values >1, or disable "set 
> layers", everything seems to be fine. (I need "set layers" for the 
> second y axis, as per section 4.9.10 of the manual.) Also, the 
> behavior is as expected (i.e., tight cropping) with compat=default 
> through 1.7. 
> >
> > Can anyone else confirm this?
> >
> > Best regards,
> > Christoph
> >
> > 
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Pgfplots-features mailing list
> > Pgf...@li...
> > https://lists.sourceforge.net/lists/listinfo/pgfplots-features
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Pgfplots-features mailing list
> Pgf...@li...
> https://lists.sourceforge.net/lists/listinfo/pgfplots-features
>
>

Re: [Pgfplots-features] Excess whitespace with "set layers" and logarithmic y limits <1

[Christian F. <cfe...@go...>]

Hi,

thanks for the report.

You are right, this is a bug, and it is known to me (even though I 
failed to find the root cause so far).

The problem is related to so-called "cell pictures". A workaround is to 
write "cell picture=true" right after "set layers" -- but that disables 
some of the effects of the layered graphics (namely layering between 
different axes within the same tikzpicture).

I will look into it with new motivation given your email.

Kind regards

Christian


Am 07.09.2015 07:55, schrieb Christoph Hahn:
> Hey guys,
>
> I recently ran into some pgfplots behavior I'd consider a bug. In the MWE
>
> \documentclass{article}
>
> \usepackage{pgfplots}
> \pgfplotsset{compat=1.12}
>
> \begin{document}
> \begin{tikzpicture}
> \pgfplotsset{set layers}
> \begin{axis}[name=n,
> ymode=log,
> ymin=1.5E-5,ymax=1.5E-3,
> ]
> \addplot coordinates {(1,2E-4) (2,2E-4)};
> \end{axis}
>
> \node at (n.outer south west) {\emph{Picture edge is here}};
> \end{tikzpicture}
> \end{document}
>
> the vertical cropping seems to be off, with the excess space depending on the y limits set. If I use values >1, or disable "set layers", everything seems to be fine. (I need "set layers" for the second y axis, as per section 4.9.10 of the manual.) Also, the behavior is as expected (i.e., tight cropping) with compat=default through 1.7.
>
> Can anyone else confirm this?
>
> Best regards,
> Christoph
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Pgfplots-features mailing list
> Pgf...@li...
> https://lists.sourceforge.net/lists/listinfo/pgfplots-features

[Pgfplots-features] Excess whitespace with "set layers" and logarithmic y limits <1

[C. H. <hah...@al...>]

Hey guys,

I recently ran into some pgfplots behavior I'd consider a bug. In the MWE

\documentclass{article}

\usepackage{pgfplots}
\pgfplotsset{compat=1.12}

\begin{document}
\begin{tikzpicture}
\pgfplotsset{set layers}
\begin{axis}[name=n,
ymode=log,
ymin=1.5E-5,ymax=1.5E-3,
]
\addplot coordinates {(1,2E-4) (2,2E-4)};
\end{axis}

\node at (n.outer south west) {\emph{Picture edge is here}};
\end{tikzpicture}
\end{document}

the vertical cropping seems to be off, with the excess space depending on the y limits set. If I use values >1, or disable "set layers", everything seems to be fine. (I need "set layers" for the second y axis, as per section 4.9.10 of the manual.) Also, the behavior is as expected (i.e., tight cropping) with compat=default through 1.7. 

Can anyone else confirm this?

Best regards,
Christoph

Re: [Pgfplots-features] Problem with Non-Linear Colormap

[Christian F. <cfe...@go...>]

Hi,

the example works if you follow the text in the error message which 
states that the input offsets of the colormap must be a multiple of your 
meshwidth, configured as [5pt] in your example.

The colorbar compiles fine with the following slightly adopted offsets

\pgfplotsset{
colormap={myNewColor}{[5pt]
rgb255(0pt)=(255,0,0);
rgb255(510pt)=(0,255,10);
rgb255(550pt)=(0,255,0);
rgb255(790pt)=(100,255,0);
rgb255(1000pt)=(0,0,255)}
}

You could add data points at 505pt or 785pt if you want discontinuous 
color transitions. Is that what you mean by "non-linear colormap"?

Kind regards

Christian

Am 10.08.2015 23:26, schrieb Joan Hensen:
> Hey guys.
>
> I'm interested in pgfplots in order to generate a non-linear colormap. 
> Is there a way to get the following example to work without doing lots 
> of "hacks"?
>
> Kind regards,
>
> Joan
>
>
> \documentclass{article}
>
>
> \usepackage{pgfplots}
>
>
> \begin{document}
>
>
> \begin{figure*}[!t]
> \centering
> \begin{minipage}[c]{\textwidth}
> \begin{tikzpicture}
> \pgfplotsset{
> colormap={myNewColor}{[5pt]
> rgb255(0pt)=(255,0,0);
> rgb255(511pt)=(0,255,10);
> rgb255(550pt)=(0,255,0);
> rgb255(789pt)=(100,255,0);
> rgb255(1000pt)=(0,0,255)}
> }
> \footnotesize
> \begin{axis}[
> hide axis,
> scale only axis,
> height=0pt,
> width=0pt,
> colorbar horizontal,
> point meta min=-1,
> point meta max=1,
> colorbar style={
> height=0.5cm,
> width=6cm,
> xtick={-1,0,1}
> }]
> \addplot [draw=none] coordinates {(0,0)};
> \end{axis}
> \end{tikzpicture}
> \end{minipage}
> \caption{aaa}
> \end{figure*}
>
>
> \end{document}
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Pgfplots-features mailing list
> Pgf...@li...
> https://lists.sourceforge.net/lists/listinfo/pgfplots-features

[Pgfplots-features] Problem with Non-Linear Colormap

[Joan H. <joa...@ou...>]

Hey guys.
I'm interested in pgfplots in order to generate a non-linear colormap. Is there a way to get the following example to work without doing lots of "hacks"?

Kind regards,
Joan

\documentclass{article}




\usepackage{pgfplots}




\begin{document}




\begin{figure*}[!t]

\centering

\begin{minipage}[c]{\textwidth}

\begin{tikzpicture}

\pgfplotsset{

    colormap={myNewColor}{[5pt]

        rgb255(0pt)=(255,0,0);

        rgb255(511pt)=(0,255,10);

        rgb255(550pt)=(0,255,0);

        rgb255(789pt)=(100,255,0);

        rgb255(1000pt)=(0,0,255)}

}

\footnotesize

\begin{axis}[

	hide axis,

	scale only axis,

	height=0pt,

	width=0pt,

       colorbar horizontal,

	point meta min=-1,

	point meta max=1,

	colorbar style={

	    height=0.5cm,

	    width=6cm,

	    xtick={-1,0,1}

	}]

	\addplot [draw=none] coordinates {(0,0)};

\end{axis}

\end{tikzpicture}

\end{minipage}

\caption{aaa}

\end{figure*}




\end{document}
 		 	   		  

Re: [Pgfplots-features] Double y axes chart

[Nick P. A. <nic...@gm...>]

Take a look at this answer:
http://tex.stackexchange.com/questions/62291/can-i-draw-figure-3-y-axis-using-pgfplot

2015-05-19 3:59 GMT+02:00 Li Yajun <lyj...@16...>:

> I want to plot a chart with two series date. As one serie date is too
> biger than another, so I want to draw double y axes, one is on the left of
> chart and the other on the right. One serie date plots based on the left y
> axes, and the other based on the right y axes. Is there any way to slove it?
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Pgfplots-features mailing list
> Pgf...@li...
> https://lists.sourceforge.net/lists/listinfo/pgfplots-features
>
>


-- 
Kind regards Nick

[Pgfplots-features] Double y axes chart

[Li Y. <lyj...@16...>]

I want to plot a chart with two series date. As one serie date is too biger than another, so I want to draw double y axes, one is on the left of chart and the other on the right. One serie date plots based on the left y axes, and the other based on the right y axes. Is there any way to slove it?

Re: [Pgfplots-features] Smith chart coordinate systems

[Christian F. <cfe...@go...>]

Hi Chris,

thanks for the detailed bug report.

This is a side-effect of a feature activated by 'compat=1.11': it 
switches the default coordinate system to "axis cs". Unfortunately, the 
regression regarding smith charts was not detected earlier.

A workaround is to use 'compat=1.10' in the preamble.

I will take care of the issue.

Kind regards

Christian

Am 11.02.2015 11:34, schrieb Christian Mandel:
> Hello,
>
> recent changes in the smith chart code, especially in coordinate system
> handling, broke my existing figures, and it took a while to find out how
> to deal with CS in recent versions of pgfplots. Since this is not
> covered by the manual, it would be nice if it could be explained there
> for other people working with that (it is only explained for \addplot):
> In the example
>
> \documentclass{standalone}
>
> \usepackage{pgfplots}
> \usepgfplotslibrary{smithchart}
>
> \pgfplotsset{compat=newest}
>
> \begin{document}
>     \begin{tikzpicture}
>       \begin{smithchart}
> %     \pgfplotsset{is smithchart cs}
> %     \begin{scope}[/pgfplots/is smithchart cs]
>         \draw [black!40,dashed] (0,0) arc (0:360:.5);
> %     \end{scope}
>       \end{smithchart}
>     \end{tikzpicture}
> \end{document}
>
> recent versions do the CS transformation not only for \addplot commands
> but for \draw commands etc. as well. One can skip the transformation for
> them as well by setting /pgfplots/is smithchart cs, e.g. within a scope
> environment. It would be handy if the key could be mapped to the tikz
> namespace to be able to skip the /pgfplots/. What does not work is
> setting \pgfplotsset{is smithchart cs}, it will result in a dimension
> too large error at \end{smithchart} (a bug, maybe?).
>
> Best regards
>
> Chris
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Pgfplots-features mailing list
> Pgf...@li...
> https://lists.sourceforge.net/lists/listinfo/pgfplots-features

[Pgfplots-features] Smith chart coordinate systems

[Christian M. <c.m...@gm...>]

Hello,

recent changes in the smith chart code, especially in coordinate system 
handling, broke my existing figures, and it took a while to find out how 
to deal with CS in recent versions of pgfplots. Since this is not 
covered by the manual, it would be nice if it could be explained there 
for other people working with that (it is only explained for \addplot): 
In the example

\documentclass{standalone}

\usepackage{pgfplots}
\usepgfplotslibrary{smithchart}

\pgfplotsset{compat=newest}

\begin{document}
   \begin{tikzpicture}
     \begin{smithchart}
%     \pgfplotsset{is smithchart cs}
%     \begin{scope}[/pgfplots/is smithchart cs]
       \draw [black!40,dashed] (0,0) arc (0:360:.5);
%     \end{scope}
     \end{smithchart}
   \end{tikzpicture}
\end{document}

recent versions do the CS transformation not only for \addplot commands 
but for \draw commands etc. as well. One can skip the transformation for 
them as well by setting /pgfplots/is smithchart cs, e.g. within a scope 
environment. It would be handy if the key could be mapped to the tikz 
namespace to be able to skip the /pgfplots/. What does not work is 
setting \pgfplotsset{is smithchart cs}, it will result in a dimension 
too large error at \end{smithchart} (a bug, maybe?).

Best regards

Chris

[Pgfplots-features] Pgfplots 1.12 releases

[Christian F. <cfe...@go...>]

Hello,

I am pleased to announce the release of pgfplots 1.12 . It is available 
on CTAN http://www.ctan.org/pkg/pgfplots and on 
http://pgfplots.sourceforge.net/

Kind regards

Christian

1.12: scalability + performance
- scalability: reduced TeX memory consumption for huge inline tables
- scalability: lualatex allows bigger 3d graphics
- scalability: lualatex now reduces compilation time for huge 3d graphics
    (requires \pgfplotsset{compat=newest} at the time of this writing)
        surf shader=faceted: time reduced to 61% of pdflatex
         (\addplot3[surf,samples=70] {exp(-x^2-y^2 +x*y)})

     surf shader=interp: time reduced to 25% of pdflatex
          (\addplot3[surf,shader=interp,samples=70] {exp(-x^2-y^2 +x*y)})

     surf shader=interp, parametric: time reduced to 36% of pdflatex
         (\addplot3[surf,shader=interp,z buffer=sort, 
samples=50,domain=-1:0,y domain=0:2*pi] ({sqrt(1-x^2) * cos(deg(y))}, 
{sqrt( 1-x^2 ) * sin(deg(y))}, x);)

     surf shader=faceted, parametric: time reduced to 40% of pdflatex
         (\addplot3[surf,z buffer=sort, samples=50,domain=-1:0,y 
domain=0:2*pi] ({sqrt(1-x^2) * cos(deg(y))}, {sqrt( 1-x^2 ) * 
sin(deg(y))}, x);)

- scalability: lualated now reduces compilation time for boxplots.
     10000 input points from table: time reduced to 23% of pdflatex
- fixed bug: 3d axes where all axes used log scale produced compile failure
- fixed bug: axis equal did not respect "disabledatascaling"
- fixed bug: mesh legend was confused by color input=explicit
- fixed bug: colorbar style did not reset zmin/zmax
- fixed bug: memory allocation in FPU consumed too much memory
- fixed bug: boxplots: removed compilation error due to spurious spaces 
in options list
- fixed bug: boxplots: now uses standard quantile estimators: has all 9 
estimators of R and uses the same as in Excel as default (as of compat=1.12)
- fixed bug: boxplots: sometimes failed to compute boxplot statistics 
for special inputs
- fixed bug: boxplots: now, it sets 'mark=*' for outliers if there is no 
mark (compat=1.12)
- fixed regression: compat=1.11 broke arcs inside of axis
- new feature: ensured that arcs inside of axis make use of 'axis cs' 
and 'axis direction cs' automatically
- new feature: ensured that (0:1) is evaluated with axis cs
- fixed bug: precision of transformation cartesian to polar was too low 
(added atan2 to fpu)
- fixed bug: z buffer caused 'mesh legend' to produce a compile error
- new feature: added 'y filter/.expression={y==3 ? nan : y}' to simplify 
coordinate filters

1.11: usability + bug fixes.
- new feature: "hide obscured x ticks=false" to disable the feature 
which hides ticks
- simplified UI for symbolic coords: now, it accepts unexpandable
   dictionary entries including umlauts, undefined macros, math mode, ...
- simplified UI for symbolic coords: added magic prefix
     [normalized]<number> to allow something like xmin={[normalized]0.7}
- simplified UI for custom annotations: one does not need to say "axis 
cs" any longer;
   coordinates like (1,2) are now automatically interpreted as (axis cs:1,2)
- new feature: 'type ticklabels with struts' improves baseline alignment 
of tick labels
- new feature: 'trig format plots=rad' allows to use radians in 
trigonometric evaluations
- simplified 'external lib': added driver auto-detection for pdflatex, 
lualatex, xelatex, dvips
     (\usepgfplotslibrary{external}, or, with the next PGF release, 
\usetikzlibrary{external})
- simplified UI for \addplot coordinates: now, it expands macros as it goes.
- new feature: 'intersection segments' now accepts negative indices to 
count from the last backwards
- simplified UI: 'intersection segments' now accepts new syntax with 
1-based indices (old 0-based are still supported)
- fixed bug: fillbetween has had a problem with pins on input paths
- fixed bug: now, 'stacked ignores zero' is no longer applied to error bars.
- fixed bug: tick lines were drawn incorrectly for centered axis lines in 3d
- fixed bug: variable=u failed to work in some contexts
- fixed bug: fill between implicitly activated layers, but did not 
install the
    correct layers for grid lines etc.
- fixed bug: z grid style was applied to y grid style
- fixed bug: using 'x=1cm' failed to work in axis descriptions (legends)
- fixed bug: mesh legend failed to work with 'shader=interp'
- fixed bug: bounding box of shader=interp was wrong if there were 
transformations.
- fixed bug: added support for \addplot graphics in ConTeXt
- fixed bug: external lib failed to work with dvips (since PGF 3.0.0 I 
suppose); now it produces correct bounding boxes
- fixed bug: \pgfplotstablenew can now overwrite existing tables.
- fixed bug: extra ticks near intersections of axis lines were hidden
- fixed bug: 'intersection segments' did not work with '--cycle'
- fixed bug: 'intersection segments' did not update the last tikz point
- fixed bug: tick lines/grid lines have been clipped when they were near 
the boundary
- fixed bug: soft clip decoration failed to apply the transformation matrix
- fixed bug: polar axes and units library resulted in broken bounding box
- fixed bug: \addplot[stack plots=false] used to work up to 1.8, but 
failed until now. Fixed.
- fixed bug: hist/density was broken since some time


1.10:
- new feature: fill between plots (library fillbetween)
- new feature: concatenate intersection segments (library fillbetween)
- fixed bug: xelatex failed to run contour external
- fixed incompatibility with \label and \usepackage{mcaption}
- fixed bug: histograms produced wrong point meta
- fixed bug: histograms reported the wrong 'plot name' and confused 
shifts of bar plots

Re: [Pgfplots-features] bounding box and multiple axes

[Christian F. <cfe...@go...>]

Hi Jerzy,

that sounds like a bug, perhaps related to one that I have on my "radar".

I will look into it. I would appreciate it if you would send me your 
minimal working example!

Happy New Year!

Kind regards

Christian

PS
I'm glad that pgfplots proves to be useful. Thanks for the praise!

Am 31.12.2014 09:44, schrieb Jerzy Wrobel:
> Hi to All,
> I have noticed the following problem (feature?) with bounding box,
> which occurs for multiple axes/layered graphics combination.
> When data range of one of the axes is much smaller then the actual
> data limits, the bounding box becomes larger, and resulting pdf
> file acquire large top and right white margins. For example, when
> x data limits are -3 and 3 with xmin=-2 and xmax=2 nothing happens,
> however, when xmin=-1 and xmax=1 are set, the above mentioned margins
> show up. Is it normal? It does not happen when a singe axis/not layered
> graphics is used. For the external pdf file generation I use
> standalone package and pgfplot 1.11.
> Best regards and Happy New Year,
> Jerzy
> P.S. Thank you Christian for the excellent package!
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Pgfplots-features mailing list
> Pgf...@li...
> https://lists.sourceforge.net/lists/listinfo/pgfplots-features

[Pgfplots-features] bounding box and multiple axes

[Jerzy W. <wr...@if...>]

Hi to All,
I have noticed the following problem (feature?) with bounding box,
which occurs for multiple axes/layered graphics combination.
When data range of one of the axes is much smaller then the actual
data limits, the bounding box becomes larger, and resulting pdf
file acquire large top and right white margins. For example, when
x data limits are -3 and 3 with xmin=-2 and xmax=2 nothing happens,
however, when xmin=-1 and xmax=1 are set, the above mentioned margins
show up. Is it normal? It does not happen when a singe axis/not layered
graphics is used. For the external pdf file generation I use
standalone package and pgfplot 1.11.
Best regards and Happy New Year,
Jerzy
P.S. Thank you Christian for the excellent package!

Re: [Pgfplots-features] xticklabels around circle, polar plot

[Christian F. <cfe...@go...>]

Hi Bill,

thanks for your request! Since the question might be of general
interest, I posted a copy of your question with a minimal example and a
double-solution on
http://tex.stackexchange.com/questions/219469/pgfplots-polar-axis-can-i-draw-angle-labels-rotated-as-for-smith-charts/219470#219470  
.  I hope this addresses your issue.

Kind regards

Christian



Am 16.12.2014 20:39, schrieb William:
> In Smith Plots, there is an option , "yticklabel around circle".  I 
> would like to achieve something similar on a polar axis.
> Is there a way to do this?
> It would be useful to provide tick labels in either tangential or 
> radial alignment.
>
> Thanks,
>
> Bill
>
>
>
> Details:
>
> I am using this online compiler:
> http://latex.informatik.uni-halle.de/latex-online/latex.php
>
> with the code below.
>
> I would like the tick labels on the inner scale to be either 
> tangential or radial.
>
>
> \documentclass{standalone}
> \renewcommand{\familydefault}{\sfdefault}
> \usepackage{pgfplots}
> \usepgfplotslibrary{smithchart}
> \usepgfplotslibrary{polar} % LATEX and plain TEX
> \begin{document}
> \begin{tikzpicture}[scale=1]
> \begin{polaraxis}[
> anchor = center,
> xtick={0,9,...,360},
> xticklabels = {1.50, {},1.40, {},1.30, {},1.20,{},1.10,{}, 1.00,{}, 
> 2.90, {},2.80,{}, 2.70,{}, 2.60,{}, 2.50, {},2.40, {},2.30,{}, 2.20, 
> {},2.10, {},2.00, {},1.90, {},1.80,{}, 1.70,{}, 1.60,{}},
> minor x tick num = 5,
> minor tick length = -0.3cm,
> major tick length = -0.5cm,
> tick style ={black},
> title style = {font=\Huge},
> ytick ={0,.95,1},
> yticklabels = {},
> ymin=0.9,
> ymax=1,
> font=\Large,
> width=20cm]
> \addplot  coordinates  {(2,2)};
> \end{polaraxis}
>
> \begin{polaraxis}[
> xmin = 0,
> xmax = 90,
> xtick={90,85.7480315,81.29032258,76.61157025,71.69491525,66.52173913,61.07142857,55.32110092,49.24528302,42.81553398,36},
> xticklabels = 
> {{0\%},{10\%},{20\%},{30\%},{40\%},{50\%},{60\%},{70\%},{80\%},{90\%},{100\%}},
> minor x tick num = 5,
> minor tick length = -0.3cm,
> major tick length = -0.5cm,
> tick style ={black},
> title style = {font=\small},
> ytick ={0,.95,1},
> yticklabels = {},
> yticklabel around circle,
> ymin=0.7,
> ymax=1,
> font=\Large,
> width=16cm]
> \addplot  coordinates  {(2,2)};
> \end{polaraxis}
>
>
>
>
> \end{tikzpicture}
> \end{document}
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Pgfplots-features mailing list
> Pgf...@li...
> https://lists.sourceforge.net/lists/listinfo/pgfplots-features

[Pgfplots-features] xticklabels around circle, polar plot

[William <wst...@ho...>]

In Smith Plots, there is an option , "yticklabel around circle".  I would like to achieve something similar on a polar axis.Is there a way to do this?It would be useful to provide tick labels in either tangential or radial alignment.
Thanks,
Bill


Details:
I am using this online compiler:http://latex.informatik.uni-halle.de/latex-online/latex.php
with the code below.
I would like the tick labels on the inner scale to be either tangential or radial. 

\documentclass{standalone}\renewcommand{\familydefault}{\sfdefault}\usepackage{pgfplots}\usepgfplotslibrary{smithchart}\usepgfplotslibrary{polar} % LATEX and plain TEX\begin{document}\begin{tikzpicture}[scale=1]\begin{polaraxis}[anchor = center,xtick={0,9,...,360},xticklabels = {1.50, {},1.40, {},1.30, {},1.20,{},1.10,{}, 1.00,{}, 2.90, {},2.80,{}, 2.70,{}, 2.60,{}, 2.50, {},2.40, {},2.30,{}, 2.20, {},2.10, {},2.00, {},1.90, {},1.80,{}, 1.70,{}, 1.60,{}},minor x tick num = 5,minor tick length = -0.3cm,major tick length = -0.5cm,tick style ={black},title style = {font=\Huge},ytick ={0,.95,1},yticklabels = {},ymin=0.9,ymax=1,font=\Large,width=20cm]\addplot  coordinates  {(2,2)};\end{polaraxis}
\begin{polaraxis}[xmin = 0,xmax = 90,xtick={90,85.7480315,81.29032258,76.61157025,71.69491525,66.52173913,61.07142857,55.32110092,49.24528302,42.81553398,36},xticklabels = {{0\%},{10\%},{20\%},{30\%},{40\%},{50\%},{60\%},{70\%},{80\%},{90\%},{100\%}},minor x tick num = 5,minor tick length = -0.3cm,major tick length = -0.5cm,tick style ={black},title style = {font=\small},ytick ={0,.95,1},yticklabels = {},yticklabel around circle,ymin=0.7,ymax=1,font=\Large,width=16cm]\addplot  coordinates  {(2,2)};\end{polaraxis}



\end{tikzpicture}\end{document}
 		 	   		  

Re: [Pgfplots-features] problem encountered with pgfplots

[Christian F. <cfe...@go...>]

Dear Anthony,

what you see is the effect of the "cycle list". The cycle list allows 
you to omit style options and let pgfplots choose style options for you: 
each \addplot will advance the cycle list pointer.

In your case, you use \addplot+[<options>]. The '+' tells pgfplots to 
"append" <options> to whatever has been found in the cycle list. The 
default cycle list, in turn, uses dashed line patterns after the first 
couple of plots.

The solution is simple: omit the '+'. This tells pgfplots to _not_ use 
the cycle list. It will only use <options>.

Kind regards

Christian

Am 14.11.2014 18:34, schrieb Anthony Lasenby:
> Dear Dr. Feuersaenger,
>
> First of all, many thanks indeed for pgfplots - it's a wonderful 
> package, and I am very pleased to have found something enabling the 
> creation of such high quality plots within Latex.
>
> I have just hit a problem with a particular plot I am trying to 
> create. This reads in data from several files, and plots out a line 
> for each, 8 in total. All the lines should be solid, but if the first 
> group of 4 lines is present, then 3 out of the 4 in the second group 
> of lines come out dashed, as shown in the attached plot. If the first 
> group of lines is not present, the second group all correctly come out 
> as solid. I've included the code below - it won't compile without the 
> data files of course, but I wondered if there was something 
> immediately evident about what I was doing which would lead you to 
> suggest where the problem is. Note each file consists of 200 rows of 4 
> floating point numbers, and I'd be happy to send these as well if you 
> had the time to look at the problem in detail.
>
> Thanks very much,
>
> Anthony Lasenby
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> \begin{figure}
> \begin{center}
> \begin{tikzpicture}
> \begin{axis}[thick,
> title={Overall title},
> xlabel={$r$},
> ylabel={$h$},width=3.5in,height=2.5in,
> xmin=0,xmax=10,ymin=0,ymax=5
> ]
> \addplot+[mark=none, smooth, red] table[x index=0,y index=1] 
> {high_h_r_EE_1_L_0p8.dat};
> \addplot+[mark=none, smooth, blue] table[x index=2,y index=3] 
> {high_h_r_EE_1_L_0p8.dat};
> \addplot+[mark=none, smooth, red] table[x index=0,y index=1] 
> {low_h_r_EE_1_L_0p8.dat};
> \addplot+[mark=none, smooth, blue] table[x index=2,y index=3] 
> {low_h_r_EE_1_L_0p8.dat};
> \addplot+[mark=none, smooth, red] table[x index=0,y index=1] 
> {high_h_r_EE_1_L_0p998.dat};
> \addplot+[mark=none, smooth, blue] table[x index=2,y index=3] 
> {high_h_r_EE_1_L_0p998.dat};
> \addplot+[mark=none, smooth, red] table[x index=0,y index=1] 
> {low_h_r_EE_1_L_0p998.dat};
> \addplot+[mark=none, smooth, blue] table[x index=2,y index=3] 
> {low_h_r_EE_1_L_0p998.dat};
> \end{axis}
> \end{tikzpicture}
> \caption{A caption}
> \label{fig:h-e-EE-1}
> \end{center}
> \end{figure}
>
>

Re: [Pgfplots-features] Is it not possible to open new issues in pgfplots' sourceforge place?

[Christian F. <cfe...@go...>]

UPDATE:

apparently, my assumption is invalid: sometime in the past, sourceforge 
must have change the permissions (probably as part of some sourceforge 
version update). As a consequence, only admins had the right to create 
tickets.

I have found the permissions after some google research and have 
reconfigured them to what appears to be better.

Thanks for pointing this out.

Kind regards

Christian

Am 14.11.2014 16:39, schrieb Christian Feuersaenger:
> Hi Ignasi,
>
> thanks for the bug report! I will take a note on my todo list.
>
> Regarding the sourceforge trackers: they are fully functional. Often 
> people send reports by mail or I encounter them on my own; in this 
> case I just write them in my todo list rather than sourceforge (it 
> simply takes too long), that's why the sourceforge list appears outdated.
>
> Kind regards
>
> Christian
>
> Am 14.11.2014 09:21, schrieb Ignasi:
>> Hi all,
>>
>> today I wanted to open a new issue about this bug(?)
>>
>> http://tex.stackexchange.com/questions/207450/fillbetween-from-pgfplots-does-not-work-inside-groupplots 
>>
>>
>> in http://pgfplots.sourceforge.net/ but I couldn't. In fact the still
>> open issues are from 2013 so I suspect it's not possible.
>> Is it? Is there any other place to do it? I'd prefer not to use
>> Christian's email address.
>>
>> Ignasi
>>
>> ------------------------------------------------------------------------------ 
>>
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push 
>> notifications.
>> Take corrective actions from your mobile device.
>> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk 
>>
>> _______________________________________________
>> Pgfplots-features mailing list
>> Pgf...@li...
>> https://lists.sourceforge.net/lists/listinfo/pgfplots-features
>

Re: [Pgfplots-features] Is it not possible to open new issues in pgfplots' sourceforge place?

[Christian F. <cfe...@go...>]

Hi Ignasi,

thanks for the bug report! I will take a note on my todo list.

Regarding the sourceforge trackers: they are fully functional. Often 
people send reports by mail or I encounter them on my own; in this case 
I just write them in my todo list rather than sourceforge (it simply 
takes too long), that's why the sourceforge list appears outdated.

Kind regards

Christian

Am 14.11.2014 09:21, schrieb Ignasi:
> Hi all,
>
> today I wanted to open a new issue about this bug(?)
>
> http://tex.stackexchange.com/questions/207450/fillbetween-from-pgfplots-does-not-work-inside-groupplots
>
> in http://pgfplots.sourceforge.net/ but I couldn't. In fact the still
> open issues are from 2013 so I suspect it's not possible.
> Is it? Is there any other place to do it? I'd prefer not to use
> Christian's email address.
>
> Ignasi
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> Pgfplots-features mailing list
> Pgf...@li...
> https://lists.sourceforge.net/lists/listinfo/pgfplots-features

[Pgfplots-features] Is it not possible to open new issues in pgfplots' sourceforge place?

[Ignasi <ni...@gm...>]

Hi all,

today I wanted to open a new issue about this bug(?)

http://tex.stackexchange.com/questions/207450/fillbetween-from-pgfplots-does-not-work-inside-groupplots

in http://pgfplots.sourceforge.net/ but I couldn't. In fact the still 
open issues are from 2013 so I suspect it's not possible.
Is it? Is there any other place to do it? I'd prefer not to use 
Christian's email address.

Ignasi

Re: [Pgfplots-features] Data time (without date) format: trouble with leading zeros

[Denis B. <dbi...@wa...>]

Le 26/10/14 à 21h13, Christian Feuersaenger <cfe...@go...> a écrit :

> Hi Denis,

Hi Christian,

> thanks for your request and for the inquiry.

You're welcome!

> I accept that as feature request and I have added it to the todo list.

Nice :)

> The ETA

I'm not sure sure what you mean:

  ┌────
  │ http://www.acronymfinder.com/ETA.html
  └────

:)

> is some time in the future though: the next two releases are
> planned for other bigger topics.

Too bad... ;)

> Regarding your questions:
>
> 1. Do you think this is a safe way of doing?
>
> --> Looks good to me.

OK.

> I believe you tested it until you were satisfied?

Indeed.

> 2. Is there a better way?
>
> --> This is the best approach currently.

OK.

> 3. Could `pgfplots` be able to directly handle data time (without date)
>    format?
>
> --> "be made able": yes. I accept that as feature request.
>
>
> I suggest to stick with the answer(s). Chances are good that I will integrate
> them into pgfplots eventually. Perhaps the current developments of a lua backend
> might help here as well.

OK, thanks!

Kind regards.
-- 
Denis

Re: [Pgfplots-features] Data time (without date) format: trouble with leading zeros

[Christian F. <cfe...@go...>]

Hi Denis,

thanks for your request and for the inquiry.

I accept that as feature request and I have added it to the todo list. 
The ETA is some time in the future though: the next two releases are 
planned for other bigger topics.

Regarding your questions:

1. Do you think this is a safe way of doing?

--> Looks good to me. I believe you tested it until you were satisfied?

2. Is there a better way?

--> This is the best approach currently.


3. Could `pgfplots` be able to directly handle data time (without date)
    format?

--> "be made able": yes. I accept that as feature request.


I suggest to stick with the answer(s). Chances are good that I will 
integrate them into pgfplots eventually. Perhaps the current 
developments of a lua backend might help here as well.

Kind regards

Christian


Am 20.10.2014 08:54, schrieb Denis Bitouzé:
> Hi,
>
> on http://tex.stackexchange.com/q/79252/18401, a solution was given to
> let the user have input data of the form `HH:MM:SS` (without
> date). Unfortunately, as pointed out in comments, this solution fails if
> `HH` is `08` or `09` with the error:
>
>    ┌────
>    │ ! Package PGF Math Error: Digit '8' invalid for base 8 (in '08*3600-08*3600+54*60+14.75')
>    └────
>
> A workaround was pointed out on the present list:
>
>    ┌────
>    │ http://pgfplots-features.706524.n3.nabble.com/Pgfplots-features-Octal-numbers-td3124234.html
>    └────
>
> just by removing the leading zeros but it is not always desirable to
> manually change the data. Moreover, the usecase of this post, and hence
> the answer given by Christian, are not relevant for data of the form
> `HH:MM:SS`.
>
> Thanks to http://tex.stackexchange.com/a/52233/18401, a possible
> workaround is, in (see http://tex.stackexchange.com/q/79252/18401), to
> replace the "brut" hours, minutes and second (#1, #2 and #3):
>
> --8<---------------cut here---------------start------------->8---
>      \pgfmathparse{#1*3600-\pgfkeysvalueof{/pgfplots/timeplot zero}*3600+#2*60+#3}
> --8<---------------cut here---------------end--------------->8---
>
> from:
>
> --8<---------------cut here---------------start------------->8---
> \def\transformtime#1:#2:#3!{
>      \pgfkeys{/pgf/fpu=true,/pgf/fpu/output format=fixed}
>      \pgfmathparse{#1*3600-\pgfkeysvalueof{/pgfplots/timeplot zero}*3600+#2*60+#3}
>      \pgfkeys{/pgf/fpu=false}
> }
> --8<---------------cut here---------------end--------------->8---
>   
> by their digital counterparts (`\the\numexpr...\relax`):
>
> --8<---------------cut here---------------start------------->8---
>      \pgfmathparse{%
>        \the\numexpr#1\relax*3600%
>        -\pgfkeysvalueof{/pgfplots/timeplot zero}*3600%
>        +\the\numexpr#2\relax*60%
>        +\the\numexpr#3\relax%
>      }
> --8<---------------cut here---------------end--------------->8---
>
> Now, some questions :)
>
> 1. Do you think this is a safe way of doing?
> 2. Is there a better way?
> 3. Could `pgfplots` be able to directly handle data time (without date)
>     format?
>
> Thanks by anticipation.

[Pgfplots-features] Data time (without date) format: trouble with leading zeros

[Denis B. <dbi...@wa...>]

Hi,

on http://tex.stackexchange.com/q/79252/18401, a solution was given to
let the user have input data of the form `HH:MM:SS` (without
date). Unfortunately, as pointed out in comments, this solution fails if
`HH` is `08` or `09` with the error:

  ┌────
  │ ! Package PGF Math Error: Digit '8' invalid for base 8 (in '08*3600-08*3600+54*60+14.75')
  └────

A workaround was pointed out on the present list:

  ┌────
  │ http://pgfplots-features.706524.n3.nabble.com/Pgfplots-features-Octal-numbers-td3124234.html
  └────

just by removing the leading zeros but it is not always desirable to
manually change the data. Moreover, the usecase of this post, and hence
the answer given by Christian, are not relevant for data of the form
`HH:MM:SS`.

Thanks to http://tex.stackexchange.com/a/52233/18401, a possible
workaround is, in (see http://tex.stackexchange.com/q/79252/18401), to
replace the "brut" hours, minutes and second (#1, #2 and #3):

--8<---------------cut here---------------start------------->8---
    \pgfmathparse{#1*3600-\pgfkeysvalueof{/pgfplots/timeplot zero}*3600+#2*60+#3}
--8<---------------cut here---------------end--------------->8---

from:

--8<---------------cut here---------------start------------->8---
\def\transformtime#1:#2:#3!{
    \pgfkeys{/pgf/fpu=true,/pgf/fpu/output format=fixed}
    \pgfmathparse{#1*3600-\pgfkeysvalueof{/pgfplots/timeplot zero}*3600+#2*60+#3}
    \pgfkeys{/pgf/fpu=false}
}
--8<---------------cut here---------------end--------------->8---
 
by their digital counterparts (`\the\numexpr...\relax`):

--8<---------------cut here---------------start------------->8---
    \pgfmathparse{%
      \the\numexpr#1\relax*3600%
      -\pgfkeysvalueof{/pgfplots/timeplot zero}*3600%
      +\the\numexpr#2\relax*60%
      +\the\numexpr#3\relax%
    }
--8<---------------cut here---------------end--------------->8---

Now, some questions :)

1. Do you think this is a safe way of doing?
2. Is there a better way?
3. Could `pgfplots` be able to directly handle data time (without date)
   format?

Thanks by anticipation.
-- 
Denis