Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Ralf Juengling <juenglin@cs...> - 2008-01-30 17:53:25
|
Hi,
I found a difference in appearance of histogram
plots ("set style data histograms") depending on
whether the data is passed in ascii or binary
format: the xrange is different (it is what I
expect with ascii but there's not right margin
with binary).
Ralf
|
|
From: Ethan Merritt <merritt@u.washington.edu> - 2008-01-30 18:13:52
|
On Wednesday 30 January 2008 09:52, Ralf Juengling wrote:
>
> I found a difference in appearance of histogram
> plots ("set style data histograms") depending on
> whether the data is passed in ascii or binary
> format: the xrange is different (it is what I
> expect with ascii but there's not right margin
> with binary).
I have never tested the histogram code with binary data.
Could you Email me a simple test script and data file?
--
Ethan A Merritt
|
|
From: Ethan Merritt <merritt@u.washington.edu> - 2008-01-30 20:42:48
|
I help is needed from someone more familiar with the binary data modes. Anyone care to take over this bug report? On Wednesday 30 January 2008 12:15, Ralf Juengling wrote: > > Here you go. The binary data is in intel pentium endianess > (whatever that is). Thanks. So far as I can tell from a quick test, the problem is not specific to histograms. Any other plot type also gets incorrect x coordinates when using the binary read command on that data file. If I dump the contents after reading them in, I get this: gnuplot> set style data linespoints gnuplot> plot "histdata.bin" binary array=1:8 format="%int" using 1 gnuplot> set table gnuplot> replot # Curve 0 of 1, 7 points # Curve title: ""histdata.bin" binary array=1:8 format="%int" using 1" # x y type 0 102 i 0 42 i 1 38 i 2 28 i 3 26 i 4 108 i 5 156 i Can you confirm this on your setup? The thing is, I wrote the histogram code so I could probably fix it there if necessary. But I am largely unfamiliar with the binary input code, and don't use it much myself. So I don't know exactly what the issue might be. Surely if it returns the wrong x coordinate in general, someone would have noticed by now? But maybe not. Or maybe you have hit a special case of some sort, though I don't know what it might be. -- Ethan A Merritt |
|
From: Tatsuro MATSUOKA <tmacchant3@ya...> - 2008-02-03 20:49:57
|
Hi In the help of the wgnuplot, Plot-data-BINARY DATA FILES: General binary data can be entered at the command line via the special file name '-'. However, this is intended for use through a pipe where programs can exchange binary data, not for keyboards. However this could not be done for pgnuplot+wgnuplot. I sent the data from the octave via pipe to pgnuplot. The pgnuplot merely sends data a byte by a byte using win32 api to wgnuplot. So this phenomenon comes from wgnuplot. see the snapshot : wgplt080204.png at http://www.geocities.jp/tmgpltwin/Files/Files.htm After wgnuplot stopped, it cannot accept code nor keybord anymore. If this is the limitation of wgnuplot, please rewrite the help of the above for the wgnuplot. Environment wgnuplot 4.2.2 on winXP(personal) Regards Tatsuro -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ |
|
From: Tatsuro MATSUOKA <tmacchant3@ya...> - 2008-02-03 22:53:22
|
Hi This is just a error correction. Sorry for my carelessness. > see the snapshot : wgplt080204.png at > http://www.geocities.jp/tmgpltwin/Files/Files.htm > see the snapshot : wgplt080204.png at > http://www.geocities.jp/tmgpltwin/Files/Files.html --- Tatsuro MATSUOKA <tmacchant3@...> wrote: Hi In the help of the wgnuplot, Plot-data-BINARY DATA FILES: General binary data can be entered at the command line via the special file name '-'. However, this is intended for use through a pipe where programs can exchange binary data, not for keyboards. However this could not be done for pgnuplot+wgnuplot. I sent the data from the octave via pipe to pgnuplot. The pgnuplot merely sends data a byte by a byte using win32 api to wgnuplot. So this phenomenon comes from wgnuplot. see the snapshot : wgplt080204.png at http://www.geocities.jp/tmgpltwin/Files/Files.htm (http://www.geocities.jp/tmgpltwin/Files/Files.html) After wgnuplot stopped, it cannot accept code nor keybord anymore. If this is the limitation of wgnuplot, please rewrite the help of the above for the wgnuplot. Environment wgnuplot 4.2.2 on winXP(personal) Regards Tatsuro -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gnuplot-beta mailing list gnuplot-beta@... https://lists.sourceforge.net/lists/listinfo/gnuplot-beta -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ |
|
From: Tatsuro MATSUOKA <tmacchant3@ya...> - 2008-02-04 00:16:53
|
Hi
I somtimes use djgpp gnuplot 4.2.2 because it is light and
it accepts pipe completely unlike pgnuplot+wgnuplot.
I found one contradiction in the djgpp gnuplot 4.2.2 .
I executed 'set terminal' to see Available terminal types.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
gnuplot> set terminal
Available terminal types:
aifm Adobe Illustrator 3.0 Format
cgm Computer Graphics Metafile
corel EPS format for CorelDRAW
dumb ascii art for anything that prints text
dxf dxf-file for AutoCad (default size 120x80)
eepic EEPIC -- extended LaTeX picture environment
emf Enhanced Metafile format
emtex LaTeX picture environment with emTeX specials
epslatex LaTeX picture environment using graphicx package
epson_180dpi Epson LQ-style 180-dot per inch (24 pin) printers
epson_60dpi Epson-style 60-dot per inch printers
epson_lx800 Epson LX-800, Star NL-10, NX-1000, PROPRINTER ...
fig FIG graphics language for XFIG graphics editor
hp2623A HP2623A and maybe others
hp2648 HP2648 and HP2647
hp500c HP DeskJet 500c, [75 100 150 300] [rle tiff]
hpdj HP DeskJet 500, [75 100 150 300]
hpgl HP7475 and relatives [number of pens] [eject]
hpljii HP Laserjet series II, [75 100 150 300]
hppj HP PaintJet and HP3630 [FNT5X9 FNT9X17 FNT13X25]
imagen Imagen laser printer
Press return for more:
latex LaTeX picture environment
mf Metafont plotting standard
mif Frame maker MIF 3.00 format
mp MetaPost plotting standard
nec_cp6 NEC printer CP6, Epson LQ-800 [monocrome color draft]
okidata OKIDATA 320/321 Standard
pbm Portable bitmap [small medium large] [monochrome gray color]
pcl5 HP Designjet 750C, HP Laserjet III/IV, etc. (many options)
postscript PostScript graphics, including EPSF embedded files (*.eps)
pslatex LaTeX picture environment with PostScript \specials
pstex plain TeX with PostScript \specials
pstricks LaTeX picture environment with PSTricks macros
qms QMS/QUIC Laser printer (also Talaris 1200 and others)
starc Star Color Printer
svg W3C Scalable Vector Graphics driver
svga IBM PC/Clone with Super VGA graphics board ["fontname"]
tandy_60dpi Tandy DMP-130 series 60-dot per inch graphics
texdraw LaTeX texdraw environment
tgif TGIF X11 [mode] [x,y] [dashed] ["font" [fontsize]]
tkcanvas Tk/Tcl canvas widget [perltk] [interactive]
tpic TPIC -- LaTeX picture environment with tpic \specials
unknown Unknown terminal type - not a plotting device
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
There lists:
svg W3C Scalable Vector Graphics driver
However
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
gnuplot> set term svg
^
unknown or ambiguous terminal type; type just 'set terminal' for a list
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Is this a bug ?
++++++++++++++++++++++++++++++++++
Evironments
gnuplot 4.2.2 djgpp on Win XP(pro and Personal)
Regards
Tatsuro
--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/
|
|
From: Tatsuro MATSUOKA <tmacchant3@ya...> - 2008-02-04 00:57:28
|
Hi My previous mail is lack of care. Excure me for that. > I somtimes use djgpp gnuplot 4.2.2 because it is light and > it accepts pipe completely unlike pgnuplot+wgnuplot. I do not want to say pgnuplot is meaningless. It is a very important tool for realising pipe in the windows environments. However, its potail is limited. For examle, I cannot the output result from the pipe. Sometimes it is important to write the succesive plot from C program using pipe. I could not judge whether plot is done or not from pipe. I instead wrote a dummy file making code (like "set out 'dummy'; set out" ) after plot command in the gnuplot script and wait by while loop to confirm the file 'dummy' is produced. What I would like to say that it should be stated that the combination of the pgnuplot and the wgnuplot does not equal to the console mode gnuplot in the help or some documents in the gnuplot. Regards Tatsuro -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ |
|
From: Tatsuro MATSUOKA <tmacchant3@ya...> - 2008-02-04 01:58:31
|
Hi Sorry my careless writing mail again. Please ignore the previous one. ************** My previous mail is lack of care. Excure me for that. >I somtimes use djgpp gnuplot 4.2.2 because it is light and > it accepts pipe completely unlike pgnuplot+wgnuplot. I do not want to say pgnuplot is meaningless. It is a very important tool for realizing pipe in the windows environments. However, its potential is limited. For examle, I cannot the output result from the pipe. I wrote the successive plots C program using pipe. Because the pipe realized by pgnuplot is only forwarding the command and I could not get the any information of gnuplot message from the pipe. This prevented me to judge whether plot was done or not from pipe. I instead wrote a dummy file making code like "set out 'dummy'; set out" after plot command in the gnuplot script and waited for dummy file made by while loop in C code. If I colud get message of gnuplot from the pipe, the program should be more simple and comprehensive. What I would like to say is the followings: The combination of the pgnuplot and the wgnuplot does not equal to the console mode gnuplot from the view point of the pipe operation. That fact should be described in the help or some documents in the gnuplot. Because I did not know the fact, I was confused. After I read the code of pgnuplot, I realized the fact. After that I wrote the tricky code to overcome the problem. However the fact is written in the gnuplot documents. Perhaps I did not confused. I did write from the first the code using dummy file. My hope is only, it is documented, no further modifications of wgnuplot are desired. Regards Tatsuro -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ |
|
From: Hans-Bernhard Bröker <HBBroeker@t-...> - 2008-02-04 21:33:03
|
Tatsuro MATSUOKA wrote: > gnuplot> set term svg > ^ > unknown or ambiguous terminal type; type just 'set terminal' for a list > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Is this a bug ? Not quite. It's a completely accurate message: in this gnuplot binary, 'svg' is an ambiguous terminal name. It could match either 'svga' or 'svg'. And somebody decided that gnuplot should output an error message in this case. The code is supposed to be able to recognize an exact match and report it in spite of the ambiguity, but somehow this failed. |
|
From: Tatsuro MATSUOKA <tmacchant3@ya...> - 2008-02-04 23:16:16
|
Hello Hans --- Hans-Bernhard Br醇rker <HBBroeker@...> wrote: > Tatsuro MATSUOKA wrote: > > gnuplot> set term svg > > ^ > > unknown or ambiguous terminal type; type just 'set terminal' for a list > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > Is this a bug ? > > Not quite. It's a completely accurate message: in this gnuplot binary, > 'svg' is an ambiguous terminal name. It could match either 'svga' or > 'svg'. And somebody decided that gnuplot should output an error message > in this case. > > The code is supposed to be able to recognize an exact match and report > it in spite of the ambiguity, but somehow this failed. > OK I understand. But I think it is ambiguous and makes one panic like me. I am happy if you think a more comprehensive message for next release. Thanks!! Tatsuro -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ |
|
From: Ethan Merritt <merritt@u.washington.edu> - 2008-02-04 23:22:18
|
On Monday 04 February 2008 13:32, Hans-Bernhard Bröker wrote: > Tatsuro MATSUOKA wrote: > > gnuplot> set term svg > > ^ > > unknown or ambiguous terminal type; type just 'set terminal' for a list > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > Is this a bug ? > > Not quite. It's a completely accurate message: in this gnuplot binary, > 'svg' is an ambiguous terminal name. It could match either 'svga' or > 'svg'. And somebody decided that gnuplot should output an error message > in this case. > > The code is supposed to be able to recognize an exact match and report > it in spite of the ambiguity, but somehow this failed. It is a bug, yes. The code works correctly on the pairs pdf / pdfcairo png / pngcairo But fails on the svg/svga case because the longer name is encountered before the shorter name. I'll fix it. -- Ethan A Merritt |
|
From: Ethan A Merritt <merritt@u.washington.edu> - 2008-02-05 06:21:30
|
On Monday 04 February 2008 15:22, Ethan Merritt wrote: > On Monday 04 February 2008 13:32, Hans-Bernhard Bröker wrote: > > Tatsuro MATSUOKA wrote: > > > gnuplot> set term svg > > > ^ > > > unknown or ambiguous terminal type; type just 'set terminal' for a list > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > The code works correctly on the pairs > pdf / pdfcairo > png / pngcairo > > But fails on the svg/svga case because the longer name is encountered > before the shorter name. Now fixed in both 4.2 and 4.3 source trees. This problem seems to have been there since the day the svg driver was first added. I guess no one ever tried to use it together with the djsvga or fg terminal types. Or else they re-arranged the #include statements such that the order in the source code is svg ... svga ... svgalib -- Ethan A Merritt |
|
From: Hans-Bernhard Bröker <HBBroeker@t-...> - 2008-02-04 20:56:14
|
Tatsuro MATSUOKA wrote: > In the help of the wgnuplot, Plot-data-BINARY DATA FILES: It has to be pointed out that this document is not specific to wgnuplot. "help plot data binary" is the same for all versions of gnuplot on all platforms. > see the snapshot : wgplt080204.png at > http://www.geocities.jp/tmgpltwin/Files/Files.html > After wgnuplot stopped, it cannot accept code nor keybord anymore. The snapshot doesn't actually show that. What you're looking at is wgnuplot trying to read all bytes you promised it. But some apparently got eaten. The problem boils down to this: wgnuplot doesn't really have a non-interactive mode the same way other platforms do, and binary data cannot really be in-lined, because they lack a recognizable EOF. |
|
From: Tatsuro MATSUOKA <tmacchant3@ya...> - 2008-02-04 23:10:25
|
Hello Hans Thank you for your explanation. > It has to be pointed out that this document is not specific to wgnuplot. > "help plot data binary" is the same for all versions of gnuplot on all > platforms I have known it. However, since the wgnuplot does not accept the binary data from the pipe, it should be stated somewhere. Can you add a sentense like the following? In case of wgnuplot, the binary data from the pipe cannot be accepted due to the limitation of its interative console. > The snapshot doesn't actually show that. What you're looking at is > wgnuplot trying to read all bytes you promised it. But some apparently > got eaten. > > The problem boils down to this: wgnuplot doesn't really have a > non-interactive mode the same way other platforms do, and binary data > cannot really be in-lined, because they lack a recognizable EOF. I understand completely. I will think another way to send data to the wguplot. Perhaps I have to use a file. Thanks a lot!! Regards Tatsuro -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ |
|
From: Tatsuro MATSUOKA <tmacchant3@ya...> - 2008-02-23 06:29:27
Attachments:
temp.dat
|
Hi
I previuosly wrote the mail.
At that time, I think that pgnuplot did not have relation to the matters.
However the pgnuplot have relation to the matter.
This is because the stdin of windows is the windows specific text mode.
I made a code the following the diff results.
The log results attached as 'temp.dat'
Addition of
_setmode(fileno(stdin), _O_BINARY);
is the most essential change. Other changes are only for taking the log.
If you have any suggestion to me, please make a reply.
Regards
Tatsuro
**************************************************************
*** pgnuplot.org.c Sat Apr 8 23:22:48 2006
--- pgnuplota.c Sat Feb 23 14:58:00 2008
***************
*** 223,235 ****
LPTSTR psCmdLine;
BOOL bSuccess;
BOOL bPersist = FALSE;
! int i;
!
#if !defined(_O_BINARY) && defined(O_BINARY)
# define _O_BINARY O_BINARY
# define _setmode setmode /* this is for BC4.5 ... */
#endif
! _setmode(fileno(stdout), _O_BINARY);
for (i = 1; i < argc; i++) {
if (!argv[i])
--- 223,235 ----
LPTSTR psCmdLine;
BOOL bSuccess;
BOOL bPersist = FALSE;
! int i; FILE *fp;
!
#if !defined(_O_BINARY) && defined(O_BINARY)
# define _O_BINARY O_BINARY
# define _setmode setmode /* this is for BC4.5 ... */
#endif
! _setmode(fileno(stdout), _O_BINARY); _setmode(fileno(stdin), _O_BINARY);
for (i = 1; i < argc; i++) {
if (!argv[i])
***************
*** 340,348 ****
/* wait for commands on stdin, and pass them on to the wgnuplot text
* window */
! while (fgets(psBuffer, BUFFER_SIZE, stdin) != NULL) {
PostString(hwndText, psBuffer);
}
/* exit gracefully, unless -persist is requested */
if (!bPersist) {
--- 340,352 ----
/* wait for commands on stdin, and pass them on to the wgnuplot text
* window */
! while (fgets(psBuffer, BUFFER_SIZE, stdin) != NULL) {
! fp=fopen("temp.txt", "ab");
PostString(hwndText, psBuffer);
+ fputs(psBuffer, fp);
+ fclose(fp);
}
+
/* exit gracefully, unless -persist is requested */
if (!bPersist) {
--- Tatsuro MATSUOKA <tmacchant3@...> wrote:
> Hi
>
> In the help of the wgnuplot, Plot-data-BINARY DATA FILES:
>
> General binary data can be entered at the command line via the special file name '-'. However,
> this
> is intended for use through a pipe where programs can exchange binary data, not for keyboards.
>
> However this could not be done for pgnuplot+wgnuplot.
> I sent the data from the octave via pipe to pgnuplot.
> The pgnuplot merely sends data a byte by a byte using win32 api to wgnuplot.
> So this phenomenon comes from wgnuplot.
>
> see the snapshot : wgplt080204.png at
> http://www.geocities.jp/tmgpltwin/Files/Files.htm
>
> After wgnuplot stopped, it cannot accept code nor keybord anymore.
>
> If this is the limitation of wgnuplot, please rewrite the help of the above for the wgnuplot.
>
> Environment
> wgnuplot 4.2.2 on winXP(personal)
>
> Regards
>
> Tatsuro
>
>
>
> --------------------------------------
> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
> http://pr.mail.yahoo.co.jp/toolbar/
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/ |
|
From: Ralf Juengling <juenglin@cs...> - 2008-01-30 21:07:43
|
On Wed, 30 Jan 2008, Ethan Merritt wrote: > If I dump the contents after reading them in, I get this: > > gnuplot> set style data linespoints > gnuplot> plot "histdata.bin" binary array=1:8 format="%int" using 1 > gnuplot> set table > gnuplot> replot > > # Curve 0 of 1, 7 points > # Curve title: ""histdata.bin" binary array=1:8 format="%int" using 1" > # x y type > 0 102 i > 0 42 i > 1 38 i > 2 28 i > 3 26 i > 4 108 i > 5 156 i > > Can you confirm this on your setup? Yes. But I don't understand why "array=1:8". If I leave that out I get # Curve 0 of 1, 7 points # Curve title: ""histdata.bin" binary format="%int" using 1" # x y type -1 102 i 0 42 i 1 38 i 2 28 i 3 26 i 4 108 i 5 156 i Thanks, Ralf |
|
From: Ethan Merritt <merritt@u.washington.edu> - 2008-01-30 21:16:24
|
On Wednesday 30 January 2008 13:06, you wrote: > > On Wed, 30 Jan 2008, Ethan Merritt wrote: > > > If I dump the contents after reading them in, I get this: > > > > gnuplot> set style data linespoints > > gnuplot> plot "histdata.bin" binary array=1:8 format="%int" using 1 > > gnuplot> set table > > gnuplot> replot > > > > # Curve 0 of 1, 7 points > > # Curve title: ""histdata.bin" binary array=1:8 format="%int" using 1" > > # x y type > > 0 102 i > > 0 42 i > > 1 38 i > > 2 28 i > > 3 26 i > > 4 108 i > > 5 156 i > > > > Can you confirm this on your setup? > > Yes. But I don't understand why "array=1:8". If I leave that out I don't think it matters. I was just trying variations of the command to see if "array" or "record" behaved differently. All the variations I tried failed to correctly increment the implicit x coordinate from 0 to N-1. > I get > > # Curve 0 of 1, 7 points > # Curve title: ""histdata.bin" binary format="%int" using 1" > # x y type > -1 102 i > 0 42 i > 1 38 i > 2 28 i > 3 26 i > 4 108 i > 5 156 i I have seen that also. Both are obviously incorrect. -- Ethan A Merritt Courier Deliveries: 1959 NE Pacific Dept of Biochemistry Health Sciences Building University of Washington - Seattle WA 98195-7742 |
|
From: Ethan Merritt <merritt@u.washington.edu> - 2008-01-31 07:16:02
|
On Wednesday 30 January 2008 12:42, Ethan Merritt wrote:
> I help is needed from someone more familiar with the binary data modes.
> Anyone care to take over this bug report?
The following one-liner makes your test case work.
However, I am *not* applying this to CVS because I just don't understand
the code well enough. The binary read code at this point is not parallel
to the ascii input code, which simply does ++df_datum as it goes.
Why is this different? Is it correct? Will it break other things?
I don't know.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot/src/datafile.c 2008-01-25 12:59:41.000000000 -0800
+++ gnuplot-cvs/src/datafile.c 2008-01-30 23:01:30.000000000 -0800
@@ -4937,7 +4937,7 @@
}
}
} else { /* Not matrix file, general binray. */
- df_datum = point_count;
+ df_datum = point_count+1; /* EAM DEBUG */
if (i != df_no_bin_cols) {
if (feof(data_fp)) {
if (i != 0)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> On Wednesday 30 January 2008 12:15, Ralf Juengling wrote:
> >
> > Here you go. The binary data is in intel pentium endianess
> > (whatever that is).
>
> Thanks. So far as I can tell from a quick test, the problem is
> not specific to histograms. Any other plot type also gets incorrect
> x coordinates when using the binary read command on that data file.
> If I dump the contents after reading them in, I get this:
>
> gnuplot> set style data linespoints
> gnuplot> plot "histdata.bin" binary array=1:8 format="%int" using 1
> gnuplot> set table
> gnuplot> replot
>
> # Curve 0 of 1, 7 points
> # Curve title: ""histdata.bin" binary array=1:8 format="%int" using 1"
> # x y type
> 0 102 i
> 0 42 i
> 1 38 i
> 2 28 i
> 3 26 i
> 4 108 i
> 5 156 i
>
> Can you confirm this on your setup?
> The thing is, I wrote the histogram code so I could probably fix it
> there if necessary. But I am largely unfamiliar with the binary input
> code, and don't use it much myself. So I don't know exactly what the
> issue might be. Surely if it returns the wrong x coordinate in general,
> someone would have noticed by now? But maybe not. Or maybe you have
> hit a special case of some sort, though I don't know what it might be.
>
>
--
Ethan A Merritt Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742
|
|
From: Daniel J Sebald <daniel.sebald@ie...> - 2008-01-31 08:11:29
|
Ethan Merritt wrote:
> On Wednesday 30 January 2008 12:42, Ethan Merritt wrote:
>
>>I help is needed from someone more familiar with the binary data modes.
>>Anyone care to take over this bug report?
>
>
>
> The following one-liner makes your test case work.
>
> However, I am *not* applying this to CVS because I just don't understand
> the code well enough. The binary read code at this point is not parallel
> to the ascii input code, which simply does ++df_datum as it goes.
> Why is this different? Is it correct? Will it break other things?
> I don't know.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- gnuplot/src/datafile.c 2008-01-25 12:59:41.000000000 -0800
> +++ gnuplot-cvs/src/datafile.c 2008-01-30 23:01:30.000000000 -0800
> @@ -4937,7 +4937,7 @@
> }
> }
> } else { /* Not matrix file, general binray. */
> - df_datum = point_count;
> + df_datum = point_count+1; /* EAM DEBUG */
> if (i != df_no_bin_cols) {
> if (feof(data_fp)) {
> if (i != 0)
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>
>
>>On Wednesday 30 January 2008 12:15, Ralf Juengling wrote:
>>
>>>Here you go. The binary data is in intel pentium endianess
>>>(whatever that is).
>>
>>Thanks. So far as I can tell from a quick test, the problem is
>>not specific to histograms. Any other plot type also gets incorrect
>>x coordinates when using the binary read command on that data file.
>>If I dump the contents after reading them in, I get this:
>>
>>gnuplot> set style data linespoints
>>gnuplot> plot "histdata.bin" binary array=1:8 format="%int" using 1
>>gnuplot> set table
>>gnuplot> replot
The array=1:8 specification indicates that there are two single dimensional arrays of data, one 1 element long, another 8 elements long. However, that doesn't seem to match what the user is intending if there are only 7 data points. (There should be nine.) Perhaps the user just wants array=7.
>>
>># Curve 0 of 1, 7 points
>># Curve title: ""histdata.bin" binary array=1:8 format="%int" using 1"
>># x y type
>> 0 102 i
The above would be the first "line" of data.
>> 0 42 i
>> 1 38 i
>> 2 28 i
>> 3 26 i
>> 4 108 i
>> 5 156 i
The rest constitutes the second "line" of data, even though there isn't enough to fill out eight elements.
Both of the above start at zero. If you want the inherent x value assigned to begin at 1 with the above patch, that's fine. (Is that what the ASCII data default is? Then matching the two would be good.)
The thing that is a bit of a problem is what the table displays. Curve 0 of 1 should maybe be curve 1 of 1, but more importantly, one might expect it to be Curve 1 of 2 and Curve 2 of 2 if the user specifies array=L1:L2, where L means "length".
However, this trait isn't unique to binary data. Try the following:
Terminal type set to 'x11'
gnuplot> set table
gnuplot> plot '-' with lines
input data ('e' ends) > 1
input data ('e' ends) > 2
input data ('e' ends) > 3
input data ('e' ends) > 4
input data ('e' ends) >
input data ('e' ends) >
input data ('e' ends) > 5
input data ('e' ends) > 6
input data ('e' ends) > 7
input data ('e' ends) > 8
input data ('e' ends) > e
# Curve 0 of 1, 9 points
# Curve title: "'-'"
# x y type
0 1 i
1 2 i
2 3 i
3 4 i
0 0 u
0 5 i
1 6 i
2 7 i
3 8 i
gnuplot>
The x-values assigned begin at 0. There is an extra "undefined" in the middle, which doesn't happen for binary data. Note that the comment says curve 0 of 1 (perhaps that is correct, i.e., multiple scan lines but still a single curve). But 9 points instead of 8?
Dan
|
|
From: Ethan Merritt <merritt@u.washington.edu> - 2008-01-31 18:16:55
|
Dan:
The binary data file supposedly contains 1 set of 7 points
(yes the original poster counted wrong but it shouldn't matter since
the error is on the *first* point, not the last one).
> The array=1:8 specification indicates that there are two single dimensional arrays of data, one 1 element long, another 8 elements long. However, that doesn't seem to match what the user is intending if there are only 7 data points.
> (There should be nine.) Perhaps the user just wants array=7.
Sorry for introducing that "array=1:8" artifact. The original failing command
was
plot "histdata.bin" binary record=8 format="%int" u 1
In trying to debug it, I tried substituting "array" for "record" but
apparently got it wrong. Sorry for the confusion on that point but
the original error remains the same.
Binary data case:
-----------------
# Curve 0 of 1, 7 points
# Curve title: ""histdata.bin" binary record=11 format="%int" u 1"
Tabular output of plot style 392 not fully implemented
# x y type
-1 102 i
0 42 i
1 38 i
2 28 i
3 26 i
4 108 i
5 156 i
Ascii data case:
----------------
# Curve 0 of 1, 7 points
# Curve title: "'dump' u 2"
Tabular output of plot style 392 not fully implemented
# x y type
0 102 i
1 42 i
2 38 i
3 28 i
4 26 i
5 108 i
6 156 i
The ascii file 'dump' was created by dumping the data
as read in from the binary file.
In the ascii input case it correctly starts the 'datum'
(column 0) at 0.
In reading the binary data file, it incorrectly starts
the 'datum' at -1.
The comments in the source code say:
df_datum = -1; /* it will be preincremented before use */
and that is indeed true in the df_readascii() case.
But the code is differnt in df_readbinary(). I changed the obvious line,
but my concern is that even though it appears to fix the 1D case it may
not be correct for "array" or "matrix" cases. Can you comment on that?
Ethan
On Thursday 31 January 2008 00:11, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> > On Wednesday 30 January 2008 12:42, Ethan Merritt wrote:
> >
> >>I help is needed from someone more familiar with the binary data modes.
> >>Anyone care to take over this bug report?
> >
> >
> >
> > The following one-liner makes your test case work.
> >
> > However, I am *not* applying this to CVS because I just don't understand
> > the code well enough. The binary read code at this point is not parallel
> > to the ascii input code, which simply does ++df_datum as it goes.
> > Why is this different? Is it correct? Will it break other things?
> > I don't know.
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > --- gnuplot/src/datafile.c 2008-01-25 12:59:41.000000000 -0800
> > +++ gnuplot-cvs/src/datafile.c 2008-01-30 23:01:30.000000000 -0800
> > @@ -4937,7 +4937,7 @@
> > }
> > }
> > } else { /* Not matrix file, general binray. */
> > - df_datum = point_count;
> > + df_datum = point_count+1; /* EAM DEBUG */
> > if (i != df_no_bin_cols) {
> > if (feof(data_fp)) {
> > if (i != 0)
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >
> >
> >
> >>On Wednesday 30 January 2008 12:15, Ralf Juengling wrote:
> >>
> >>>Here you go. The binary data is in intel pentium endianess
> >>>(whatever that is).
> >>
> >>Thanks. So far as I can tell from a quick test, the problem is
> >>not specific to histograms. Any other plot type also gets incorrect
> >>x coordinates when using the binary read command on that data file.
> >>If I dump the contents after reading them in, I get this:
> >>
> >>gnuplot> set style data linespoints
> >>gnuplot> plot "histdata.bin" binary array=1:8 format="%int" using 1
> >>gnuplot> set table
> >>gnuplot> replot
>
> The array=1:8 specification indicates that there are two single dimensional arrays of data, one 1 element long, another 8 elements long. However, that doesn't seem to match what the user is intending if there are only 7 data points. (There should be nine.) Perhaps the user just wants array=7.
>
> >>
> >># Curve 0 of 1, 7 points
> >># Curve title: ""histdata.bin" binary array=1:8 format="%int" using 1"
> >># x y type
> >> 0 102 i
>
> The above would be the first "line" of data.
>
> >> 0 42 i
> >> 1 38 i
> >> 2 28 i
> >> 3 26 i
> >> 4 108 i
> >> 5 156 i
>
> The rest constitutes the second "line" of data, even though there isn't enough to fill out eight elements.
>
> Both of the above start at zero. If you want the inherent x value assigned to begin at 1 with the above patch, that's fine. (Is that what the ASCII data default is? Then matching the two would be good.)
>
> The thing that is a bit of a problem is what the table displays. Curve 0 of 1 should maybe be curve 1 of 1, but more importantly, one might expect it to be Curve 1 of 2 and Curve 2 of 2 if the user specifies array=L1:L2, where L means "length".
>
> However, this trait isn't unique to binary data. Try the following:
>
> Terminal type set to 'x11'
> gnuplot> set table
> gnuplot> plot '-' with lines
> input data ('e' ends) > 1
> input data ('e' ends) > 2
> input data ('e' ends) > 3
> input data ('e' ends) > 4
> input data ('e' ends) >
> input data ('e' ends) >
> input data ('e' ends) > 5
> input data ('e' ends) > 6
> input data ('e' ends) > 7
> input data ('e' ends) > 8
> input data ('e' ends) > e
>
> # Curve 0 of 1, 9 points
> # Curve title: "'-'"
> # x y type
> 0 1 i
> 1 2 i
> 2 3 i
> 3 4 i
> 0 0 u
> 0 5 i
> 1 6 i
> 2 7 i
> 3 8 i
>
> gnuplot>
>
> The x-values assigned begin at 0. There is an extra "undefined" in the middle, which doesn't happen for binary data. Note that the comment says curve 0 of 1 (perhaps that is correct, i.e., multiple scan lines but still a single curve). But 9 points instead of 8?
>
> Dan
>
--
Ethan A Merritt Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742
|
|
From: Daniel J Sebald <daniel.sebald@ie...> - 2008-02-01 08:29:44
|
Ethan Merritt wrote:
> Dan:
>
> The binary data file supposedly contains 1 set of 7 points
> (yes the original poster counted wrong but it shouldn't matter since
> the error is on the *first* point, not the last one).
[snip]
OK, I follow now...
>>>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>--- gnuplot/src/datafile.c 2008-01-25 12:59:41.000000000 -0800
>>>+++ gnuplot-cvs/src/datafile.c 2008-01-30 23:01:30.000000000 -0800
>>>@@ -4937,7 +4937,7 @@
>>> }
>>> }
>>> } else { /* Not matrix file, general binray. */
>>>- df_datum = point_count;
>>>+ df_datum = point_count+1; /* EAM DEBUG */
>>> if (i != df_no_bin_cols) {
>>> if (feof(data_fp)) {
>>> if (i != 0)
>>>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
I believe your fix is correct. Feel free to check it in...
The reason for not incrementing df_datum directly, as is done with ASCII case, is that datum could also come from the gnuplot binary matrix as well. Hence the tie in to point_count. However, I might have moved a hunk of code around at some point and the incrementing of point_count comes later:
/* update point_count. ignore point if
point_count%everypoint != 0 */
if (++point_count < firstpoint
|| point_count > lastpoint
|| (point_count - firstpoint) % everypoint != 0)
continue;
/*}}} */
so point_count is still at -1 (first time) when df_datum was first set. In the case of "array =" a different variable
v[output] = m_value*delta[0];
is used instead of df_datum. Your change will mean both cases now start at 0.
Dan
|
|
From: Ethan Merritt <merritt@u.washington.edu> - 2008-02-01 19:57:51
|
On Friday 01 February 2008 00:29, Daniel J Sebald wrote: > > I believe your fix is correct. Feel free to check it in... OK. Will do. Thanks -- Ethan A Merritt |