gnuplot 5.0 patchlevel 1
windows 7 professional SP1
64 bit
precompiled binary: gp501-win64-mingw.exe
When plotting inline data with a large number of columns, it appears that each line of input is split into two lines partway through. I have 112 or so columns. The data seems to break around column 105-110. I can't find anything in the documentation about a maximum line length or number of columns for inline data.
Example: given the large input file (attached) I would expect:
gnuplot> load 'data.dat'
gnuplot> set table
gnuplot> plot $foo using 1:2 with table
0 0.154449
0.5 0.13626
1 0.152087
1.5 0.133543
2 0.147717
2.5 0.125787
3 0.142677
3.5 0.103858
4 0.113661
...
Instead I get:
gnuplot> load 'data.dat'
gnuplot> set table
gnuplot> plot $foo using 1:2 with table
0 0.154449
2205 0.145039
0.5 0.13626
0.131535 0.150433
1 0.152087
0.126457 0.139961
1.5 0.133543
0.138622 0.140984
2 0.147717
14331 0.115669
2.5 0.125787
17362 0.128504
3 0.142677
58 0.117717
3.5 0.103858
4 0.12378
4 0.113661
6535 0.085
...
The "extra" line of data in between my data lines can always be found near the end of one of the input lines. Plotting directly from a file works fine, but I would rather use inline data for portability.
Tim Parsons
tparsons@ara.com
The maximum input line length is 1024 characters.
Under some circumstances this is expanded dynamically as needed, but filling a datablock line is not one of those circumstances.
Loading a datablock with very long lines is probably doable, but such a fix might reveal a similar restriction on some later stage of processing.
Last edit: Ethan Merritt 2016-03-17
I've switched the input routine used by the datablock definition command so that it is not limited to 1024 characters. If that doesn't shake out any further problems, it can go into the next release (5.0.4).
Now this bug is fixed in the development version.
If you want try fixed version, please visit the following:
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
Tim Parsons reported that the current development version fixed the issue.
Could this fix have somehow caused bug #1758?