You stated two questions and I will address them briefly:
1 Can pgfplots read binary representations of floating point numbers?
In short: no.
2 How are coordinates mapped into a PDF?
This is a quite complex operation: first all coordinates are collected in order to compute axis limits. This is the "survey phase". Afterwards, all coordinates are mapped into the 32 bit fixed point number range of TeX/PDF/PS. These numbers are written in plain text into the output file (after applying any transformations like scaling or stretching).
Aside from these answers to your questions, I see that you are actually searching for something else for which these answers are merely some "sub-product". You appear to be wondering how to optimize something; apparently loading huge bulks of data files of animations or perhaps processing by means of pgfplots.
I would agree that animations might involve adequate data file formats. But if a binary "CSV" is the right one appears to be questionable. And pgfplots
as tool to read "huge animation data files" appears to be as questionable. Do you want to import AVIs?
If you want to reduce the time that pgfplots ponders on data in general, you should pose a feature request or bug report. Note that it is entirely unclear of whether number parsing is a bottle neck at all (a pity that there are no powerful profilers). In fact, I would expect bottlenecks somewhere else.
If you want to improve the quality by reducing numeric operations, you may want to write some low-level driver file which writes stuff directly to a PDF. There are some operations in PDF which actually expect binary data, but they expect mapped integers rather than floating point numbers. I would expect that such an approach produces exactly the same quality as that produced of pgfplots (and would hope for a bug report if not).
I hope these thoughts help to improve the search for an answer and to clarify the use-case(s) that you have in mind.
I don't really get the question so I hope this is what you wanted. If you include a full document (such that we copy paste and see the problem on our systems) things are much more easier.
Here, you can change the default setting within a scope but your block
style had a node distance
which was resetting every time it is issued. I've made it 2mm such that we can see the difference easier.
\documentclass[tikz]{standalone}
\usetikzlibrary{arrows,shapes.geometric,positioning}
\begin{document}
\begin{tikzpicture}[decision/.style={diamond, draw, text width=4.5em, text badly centered, node distance=3.5cm, inner sep=0pt},
block/.style ={rectangle, draw, text width=6em, text centered, rounded corners, minimum height=4em, minimum height=2em},
cloud/.style ={draw, ellipse, minimum height=2em},
line/.style ={draw,-latex'},
node distance = 1cm,
auto]
\node [block] (1st) {1st};
\node [block, right= of 1st] (2nd1) {2nd1};
\begin{scope}[node distance=2mm and 10mm]%Here we change it for everything inside this scope
\node [block, above= of 2nd1] (2nd2) {2nd2};
\node [block, below= of 2nd1] (2nd3) {2nd3};
\node [block, right= of 2nd1] (3rd1) {3rd1};
\node [block, above= of 3rd1] (3rd2) {3rd2};
\node [block, above= of 3rd2] (3rd3) {3rd3};
\end{scope}
\node [block, below= of 3rd1] (3rd4) {3rd4};
\node [block, below= of 3rd4] (3rd5) {3rd5};
\path [line] (1st) -- (2nd1);
\path [line] (2nd1) -- (2nd2);
\path [line] (2nd1) -- (2nd3);
\path [line] (2nd2) -- (3rd3);
\path [line] (2nd1) -- (3rd1);
\path [line] (1st) -- (2nd1);
\end{tikzpicture}
\end{document}
Best Answer
Those differences are too small for PGFPlots to handle. You can work around this by subtracting a fixed amount from all numbers using
gnuplot
and "faking" the labels:But honestly you should probably find some other way to display the effect of the buffer size on the loss probability (are you sure that this effect is even real, or significant?)